How is “bloat” measured here? Or is this simply a list of open source alternatives to commercial products?
[flagged]
A website for debloated open source alternatives
111–116 of 116 posts
Re: A website for debloated open source alternatives
#112In the TV and Media section ( https://debloat.dev/c/tv-media ) there are 11 recommendations and 4 of them are XBMC. There used to be so many options for media centres. What happened?
I think it's just a pretty consolidated space? Kind of like ebook management, which was dominated by Calibre for so many years (this changed recently). But unlike ebooks, media centre management is a fair bit more complex since it involves supporting many different media formats and many forms of acceleration or transcoding. So the big projects - Kodi for local media and Jellyfin for streaming - have a lot of inertia…
[flagged]
Re: A website for debloated open source alternatives
#113Re: A website for debloated open source alternatives
#114Earlier quoted context omitted.
Actually think the suckless people would hate this. Google login and nothing there looks light weight in the suckless spirit.
I mean, if the suckless crowd were actually serious they'd offer their website only in gopher or something like that instead of bloated HTML (/s)
Heh, HTTP itself is pretty nice and flexible protocol. Its not their fault its get bloated by all shit added to it. Gopher is such inferior protocol compared to HTTP.
http://borg.uu3.net/~borg/ <- impossbile to replicate using gopher. Is it bloated? Hell no...
Re: A website for debloated open source alternatives
#115Earlier quoted context omitted.
It’s not that difficult to be honest. VLC / ffmpeg can do most of the heavy lifting. And there’s no shortage of libraries for rendering in a UI. There used to be dozens of options to choose from. Multiple different XBMC forks. Multiples different Subsonic forks. Multiple different DNLA servers. Multitudes of web-based servers. CLI MP3 servers. Independent media centres for a variety of different consoles. Maybe that’…
> Multiple different XBMC forks. Multiples different Subsonic forks. Multiple different DNLA servers. Multitudes of web-based servers. CLI MP3 servers. Big difference between _audio_ streaming and _video_ streaming servers. Video streaming is much more complex and pretty consolidated, as I mentioned. Audio streaming is much more manageable: no issues with transcoding, acceleration or subtitling, and a radically simpl…
There’s literally no difference in difficulty between audio and video.
They all suffer from the same problems of indexing content. They all have multiple different encoding formats available. And they all need a frontend widget in your client for playback.
I’ve worked with both the audio and video streaming platforms and what you’re describing is grossly inaccurate. The fact that your container format isn’t including video frames doesn’t magically solve any of these issues.
Plus ID3 can be a source of new problems by itself given the way it was implemented…twice.