I wonder if the site needs a bit more bloat to handle the load, or a bit less.
All the /p/ URLs are in the sitemap, all the site's pages can be retrieved over a single TCP connection
https://debloat.dev/sitemap.xml
This, i.e., retrieving all 200 /p/ URLs over a single TCP connection (using HTTP/1.1 pipelining), results in a 1.9MB HTML file comprising all the /p/ pages, including response headers. NB. This isn't "crawling". All URLs are known before the connection is made
No cookies, no Javascript
Other than CSS, no bloat
Do you mean crawling the entire sitemap and concatenating the results is 1.9MB?
Wrapping modules to expose additional functionality for a niche in a problem domain is tricky. You will end up with some code duplication and some predictability issues with your timelines, but the end result will be better for it.
Long ago someone convinced me that 'Strangling a Service' could also be applied to APIs. The base module should be as simple as possible but no simpler, and more esoteric features should be shunted off to another module. And then in the case when features are antagonistic to each other, they can live in parallel in separate wrappers.
The tricky part there is writing unit tests in the base to defend the negative space that these features fit into. This feature depends on an invariant in the base API that will break everything if merged.
There used to be so many options for media centres. What happened?
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 because they tend to support whatever you throw at them.
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’s still available and just not indexed on that site. But I noticed the choices had shrank significantly last year when I was looking for Plex alternatives compared with when I last built a media centre approximately 15 years ago.
Maybe smart TVs have reduced people’s desire here?
Sounds easy if all you have to do is write a short comment about it. People who actually did it, like the recently retired lead of the Jellyfin project, didn't make it sound like it's "not that difficult" [1].
If you want ot vibe code a project for yourself it's probably reasonable amount of effort. But if you want to build a product, something with polish, something not held together by spit and scotch tape, something reliable, it won't be easy.
I can’t recall if Chromium supports that, I have a feeling Google only include that DRM in Chrome. But if it is available in Chromium then you might be able to build an Electron app.
Understanding ffmpeg borders on a specialization in itself. No big surprise that so many of the alternatives have fallen away over the years as people realize the absolute scope of that piece of software.
But if you don’t want to use ffmpeg directly then use one of the many ffmpeg wrappers. Or a different lib entirely like gstreamer or VLC.
Around 15 years ago I built a media centre for my car and the media playback part turned out to be the easiest part of the project.
People that run these services don't want "dynamic stream quality selection".
In the case of media management, ffmpeg is easily usable with just about every programming language in existence and its usage is extremely well-trodden at this point, which makes the vacuum of newer alternatives to the XBMC lineage all the more puzzling.
This is the inherent problem with tech start-ups. Once they solve the problem they were founded to solve, then what? It's feature complete, but investors insist that the line must go up. Can you imagine if `sed` or `vim` was brought to market by a venture-backed company?
IMHO, capitalism and FOSS are fundamentally incompatible.
Perhaps it would have been better to split the product into a simple consumer thing and then a separate enterprise product suite.
A bold statement to make given the world we live in today contains plenty of both, working together, in harmony.
Really lightweight and nice!
Toyota bZ/bZ Woodland, the entire Hyundai/Kia lineup, Honda Prologue, Jaguar i-pace, original Audi e-tron
I haven’t seen the newer Nissan infotainment system, not sure about that one.
Are these without tech? No, not at all, but they do have fast and simple interfaces that are designed to dump you into CarPlay/Android Auto with ease, and a good amount of them retain separated climate controls that live outside the screen.
Obviously if you want something like a 2008 Accord that’s not really going to be a thing, but almost everyone who isn’t Tesla or Rivian is surprisingly conventional. If you haven’t done much EV shopping and your impression of EVs is “they’re all like Tesla where everything is in the screen” that isn’t true at all. For example, Kia/Hyundai EV models have absolutely zero difference between the gas models and EVs in terms of control design. Toyota’s latest infotainment system is as basic and straightforward as it gets.
I find stuff like this hilarious. No software project has ever failed, or even slow down one iota, because of the comment style. This is just someone's personal "ick" masquerading as "coding standards."
EDIT: I think it has actually been becoming a dad of two boys that has absolutely killed my patience for this kind of thing. A lot of it is so similar to how my children argue with each other over absolutely trivial things. Add in the way they say "I don't like that" as "that's not fair" (my children) or "that's not consistent" (the bike shedding nerds) and it just makes me want to scream, "stop whining!"
As a father of two boys myself, I know exactly where you're coming from. Like some adults, they'll argue over pointless details and miss the entire thrust of the discussion.
> No, to repeat what I said, I think "consistency" to a programmer is like "fairness" to a child
I tend to pride myself on my ability to read and comprehend things, and I feel like I never saw you say this. I see now it was an edit to an earlier comment that I didn't catch the meaning of. It seems to say that you think consistency is childish, maybe because it's a naive ideal of some kind? I value it highly, so your perspective is interesting (in the vein of "Symmetry is a complexity-reducing concept. Seek it everywhere.")
That aside, you're advocating for projects that have wildly different coding styles from file to file and function to function?
I guess I've never really worked on a project like that. I can imagine it would feel very messy and would make manual refactors difficult but might not be such a problem for AI?
I'm advocating for giving up in style as a thing you delude yourself into thinking matters. The opposite of "enforcing consistent style" is not "bedlam and mayhem." I'm saying just let people work on their things and focus on real metrics like testing and algorithmic analysis.
This idea that code should be "consistent" is a gigantic question begging practice. Consistent with what? As according to whom? For what purpose? I will go out on a very short, very thick limb and say that nobody has ever demonstrated a good definition of "consistency," say nothing of the value of adhering to that definition.
It is the way of no way. It does not imply doing things in a stupid way. It implies the narrow minded focus demonstrated by others is an impediment to excellence.
I'm getting rate limited do to an ancient slow-ban I picked up years ago and probably redemonstrate the need for on a regular basis, but I think tacking this text intended as a reply to another person into the end of this comment makes sense.
I suspect if Bruce Lee had ever tried to work as a martial arts instructor in a school as his primary form of living, he'd have found that he couldn't communicate with the other instructors in his school, that they would be insistent that the rigid forms were the only way to achieve true mastery. The value in Bruce Lee being an actor was that he never had to really have that argument with a cadre of fellow instructors. He was able to build his own cult of personality and start his own school. Which, of course now, the art of Jeet Kun Do was ossified into a series of predefined patterns for how to operate, completely missing the point.
I guess I've never really worked on a project like that. I can imagine it would feel very messy and would make manual refactors difficult but might not be such a problem for AI?
The fact that we are disagreeing on this point is great evidence that there isn’t an easy to define, proverbial line in the sand.
There is an easy to define line: there is no line. It's not a boundary where "over here is good code" and "over there, not" we just don't have a good idea of where the line is. No. There is absolutely no line.
To be honest, I completely agree with you.
The point I make is that not everyone would. And that disagreement alone results in a blurry line as to what some would consider important and what others would not.
But personally, I honestly do wish more people had the same opinion as you.
That would be a good feature here.
There's also an implicit judgment in your question. Is well-designed, well-tested AI-generated code worse than poorly written, but hand-typed code?
You're asking an extremely reasonable question, IMHO, especially given these are projects with limited resources going up against generally larger, better-resourced projects. AI is an obvious point of leverage in such a situation, and so there is a lot of potential to reverse engineer using AI and get good results.
What all of these requests fundamentally come down to is "How are you filtering for quality?", which is an extremely difficult question given the state of, for example, the app stores.
Heh. I was essentially run out of lobsters for repeatedly asking that question. Not even kidding. At some point I became the second most flagged user in the entire forum. The site itself invited me to delete my account.
After a while I simply asked Claude to define "slop" and posted the answer. To this day it's still the only coherent definition of "slop" in the entire site.