> He mentions in the thread that he had to delete posts offensive to the developers. Maybe that's why?
Maybe. As those posts have (allegedly) been deleted, it is now impossible to say. It seems probable though. I do find it interesting that he didn't delete the post, spewing actual verbal abuse at the people who dared to propose possible solutions in good faith.
> It is interesting that nobody in the thread went to check in the code of mpv, smplayer, etc. to see how it's done there. Surely this would be the best response to his request for technical suggestions
He has flatly ignored and refused to address, that these other players can do this at all. He makes only mention of "video editors". Well, and YouTube -- cherry picking the easiest case to attack (on grounds of single file format).
At the end of the day, what he needs is an algorithm, which can then be applied against the VLC codebase. For example:
* track timestamp of latest keyframe
* track nframes since latest keyframe
* optionally, keep some sort of unique id to positively identify this keyframe
- now, scrub back to last keyframe (if time accounting is sloppy for this format, overscrub by some amount, the run forward to the keyframe. If overscrubbing is significant, this is where you could compare the keyframe against the reference, to ensure you aren't way far back and needing to run forward further)
- okay, you've found your keyframe; advance (nframes - 1)
- profit
If he comes back and says "that's not fully general", that's true --- but the people asking for this don't care if it's fully general; it's suitable for common use cases and that's what they want. Let it work where it will work. Give up where it won't.
If he comes back and says "sure, that could work, but I don't have time, send a patch", well, okay, that's understandable.
What's actually happening is he's coming back and saying that won't work at all, that it won't support the majority of cases, will take too much compute, etc. and that's just flat out not true. You can do it selectively for the common cases. He might not want to, but that's different from can't.
Like, consider a scenario where you're playing back realtime video over a network connection. You won't necessarily be able to seek forward in that scenario -- you might not have enough video buffered, or hell, the connection could be plain interrupted. Imagine if they just didn't implement forward seek because the solution could not be fully generalized...
And who is going to spend time coding such a thing up, knowing that it is likely to be rejected as "not fully general"?
> It's of course work to do, and I'm not super motivated to send them that patch, and there's the question of it it would be merged
That's my issue; he calls for people to send patches, but anyone capable of writing such a patch is also probably going to see that he's not positive on the matter, and that his "patches welcome" is really pretty passive aggressive in this instance. At least, that's how it comes off to me. I would expect that, should I submit such a patch, it would simply be rejected on the basis that "it is not a general solution".
My first programming forays were with the assembler feature of DEBUG.EXE, on an 8088. Extraordinarily cumbersome in retrospect, but it was existing at the time. Definitely a gateway experience.
> real consequences that I'm aware of (as in legal, regulatory, etc)
So if I understand correctly, the argument is that social pressure isn't real pressure and can be dismissed as inconsequential? If that's the case, then yeah, I think this is played out and we can call it here.
(Not because I strongly agree or disagree with such a notion, I just kind of think it would be getting off into the weeds a bit much to continue at that point.)
I would guess that having it drilled in from childhood probably has something to do with it. By taking issue with it, you're going against the flow and people in general seem to be uncomfortable with that sort of thing. It also seems to me, that people tend to associate it with something other than the actual words that are being spoken.
So in other words, you disagree with the post I'm replying to?
> I don't believe there is any pressure whatsoever.
You've clearly not been to some of the events that I have. Also, there's the whole matter of various public school systems. Regardless, if there hasn't been any pressure for you, then this is sort of a non-sequitur, as my comment is talking about situations where there is pressure to begin with. Non-pressure situations are out of scope.
In fact, I generally don't. On the other hand, that is not because I am bothered (or not) by such practices.
I'm really not sure what this has to do with the opinions being expressed by myself, parent, and GP here. I can avoid a behaviour and simultaneously have an opinion on the behaviour, which I am expressing here in response to others' opinions on said behaviour.
> It's like people forgot that non-web-interface rss readers existed.
I'd wager that a lot of people never even knew these existed. To a lot of people, the browser became (or simply always was) the only real interface to everything internet related (or for some people, just about everything period).
Probably, they are like me, meaning we seem not to be on the same page as you regarding the term 'podcast'. To me, a podcast is just an audio talk session, mastered and distributed as a digital audio file. That's it. Distribution can take many forms, but the podcast is the file. 10 or so minutes of google-based research seems to offer support to this notion.
> universe of media distribution that happens via an open protocol that is not controlled by any one company
What is this protocol that you speak of? Searching "podcast protocol" leads to absolutely no useful links on the subject. Podcasts in my experience are distributed in one of three ways:
* Download links on a web page
* Embedded streaming links on a web page
* An RSS feed
That last (RSS) could be considered a "protocol" of sorts, I suppose. At the very least it's what I would expect a podcast app to support. But you then go on to refer to RSS as a separate entity from your "podcast protocol", so I'm back to being confused as to what you might be talking about. What is this open protocol that is intrinsic to your definition of 'podcast'?
That may be true, and it may be of personal value to pursue this for yourself. That's different from socially badgering others into it at group events.
This is the exact reason* I bought a 4090 for my recent rebuild instead of the rDNA card I actually wanted. I really wanted to go with AMD for the driver integration with the Linux graphics stack —- I’m so, so tired of shenanigans when it comes to decades old features of X not working or working poorly due to some nvidia bug/non-integration.
But being able to leverage my graphics card for GPGPU was a top priority for me, and like you, I was appalled with the
ROCm situation. Not necessarily the tech itself (though I did not enjoy the docker approach), but more the developer situation surrounding it.
The letter or the intent though? Because if it’s the letter, we’d better throw in wheel chairs, surfboards etc. as well. The law does not specify motor vehicles, even though I would believe that to be the intent.
Improvements to property often bring little to no return at time of sale —- especially if those improvements have worn in a few years. More than a few years? Forget it. Improvements are generally made to improve immediate rental value (similarly maintenance repairs are made to retain existing value). Gains realized on sale are mostly from natural appreciation of real estate over time (on which capital gains will be paid). This is why house flipping is not a more popular enterprise.
> going to charge more for rent
You mean, be able to charge anything at all.. it’s not like we’re taking about buying turn-key properties and updating the cabinetry or something.
> not really doing any labor
Properties require upkeep. (N) properties require N times the upkeep. In addition to normal expenses, there are also risks; for example a tenant may damage your property, and then you need to fix it. You may think your security deposit covers that; in reality that amount of money can usually only cover minor repairs / cleaning. Landlords need to recoup that sort of thing over time, so it ends up getting rolled into your rent.
I really don’t think you understand how expenses for these things work. The way you’ve been talking, it sounds like you think your rent check goes directly into the landlord’s bank account as profit. Maybe you should try home ownership, and see what the actual ledger (expenses + time) looks like over time. Compare that plus your mortgage to rent. You may need to do this for the long haul to see the real picture though, not just a couple of years.
Better yet, acquire some properties and try your hand at rental yourself —- either you’ll end up filthy rich for nothing like you seem to think it works, or you’ll learn a valuable lesson about the true cost of services…
Because, while you assert that landlords offer no value, the fact remains that there are people in this world who want to rent, not own. Without landlords, how is that supposed to happen?
> End of the day, landlords don’t deserve more money and I don’t know why anyone here argues for it. It’s like you want bezos to have even more money - it’s super weird.
See, to me, this vitriol is what seems super weird. It seems like you must be talking about some sort of property shark that owns 8+ figures in property and extracts the maximum possible from the poor peons that dare to want a roof over their heads. Maybe with some large company thrown in the mix for good measure.
My father and grandfather are both in rental (well, they did whatever they could to make their way, primarily carpentry; rental is only part of the picture). Both of them started with nothing and managed to bootstrap their way into some properties, fixing them up as they went. They do all the work on their respective properties themselves. There isn’t a management company involved. They aren’t some evil men trying to extort the populace, the goal is just to live, provide for family, etc. Yet by definition, they are landlords - that thing that so many here despise unilaterally with such passion.
Probably there is considerable diversity (or at least two classes of landlords). But laws are going to apply to both groups.
> If an engineer spends an hour writing a commit message that no one reads, that's an unproductive engineer, compared to where they should be.
Okay, maybe don't spend an hour. It would take a special kind of commit to need more than a few minutes writing a decent commit message.
> And I would argue we shouldn't cater to developers who make documentation difficult to access for everyone else by hiding it where only crappy tools can reach it.
Yeah. Like web browsers. And PDF viewers.
The non-caustic point here is that clearly different people have different ideas about what is accessible.
> I think it's optimized for discussions before integration, which is largely what PR descriptions and comments are largely used for now.
This isn't even a git concept though; it's something that was tacked on top of it. What you seem to be saying here is that a third-party tool building on top of git spawned a social movement that moved this layer up a level. Not every project uses github or a github workflow.
> I think it's optimized for discussions before integration
It's optimized for discussion of the purpose of the code unit in question. That discussion can be useful before integration; but pre-integration discussion can happen any way you like. PR discussions work, e-mails on mailing lists work. Face-to-face discussion works.
The real value (for me, I guess; apparently you just don't see it that way) is explaining the purpose (and possibly circumstances) of the commit, after the fact, when I'm looking at it for some reason or other. Not finding the commit, but explaining it once I'm there. A well-written commit message can be absolutely priceless.
Maybe this last point should go in a top-level response to your original comment, but I'm already here, so I'll just say it here. Saying that commit messages are terrible because only short-messages (the "subject line") are shown by default, seems to me about the same as saying e-mail bodies are useless for the same reason, or that file contents are terrible because `find` only lists file names by default. You 'have' to collapse by default, or you'd drown in a sea of commit messages anytime you tried to list anything.
> Like say you are trying to determine why a 10 line function is the way that it is. You blame it. Not even with the stupid-simple GitHub UI that _I_ originally wrote, but with the more expensive CLI interface that follows renames and ignores whitespace changes, etc. Now you get a list of SHAs of commits and the first 50 chars of commit messages for each line for the last modifications, etc. How do you even stitch those messages into a useful story (in order) to tell you how that function evolved to what it is now and why?
Okay, I hear you, this is not the most ergonomic procedure to one-off. But seriously, you have the SHA commits. If you need to do this often, write a tool that takes those SHA commits, orders them based on log order (or chronological order, w/e, pick an ordering mechanism), and prints out whatever information is interesting to you. A simple display that can expand/collapse full messages, diffs, etc. would probably do nicely. It can be a GUI tool, a CLI tool (menu-driven, maybe); whatever works for you. This should not be a big deal to write for the common case, and if you think it's that critical to the community, publish it.
I mean clearly he’s a menace. Something needs to be done about him. That can be true, and it can simultaneously be true that he is not 100% “evil” or anything else.
A few incidents (or even many incidents) can paint a bleak picture, but they can’t really prove an absolute.
Maybe. As those posts have (allegedly) been deleted, it is now impossible to say. It seems probable though. I do find it interesting that he didn't delete the post, spewing actual verbal abuse at the people who dared to propose possible solutions in good faith.
> It is interesting that nobody in the thread went to check in the code of mpv, smplayer, etc. to see how it's done there. Surely this would be the best response to his request for technical suggestions
He has flatly ignored and refused to address, that these other players can do this at all. He makes only mention of "video editors". Well, and YouTube -- cherry picking the easiest case to attack (on grounds of single file format).
At the end of the day, what he needs is an algorithm, which can then be applied against the VLC codebase. For example:
* track timestamp of latest keyframe
* track nframes since latest keyframe
* optionally, keep some sort of unique id to positively identify this keyframe
- now, scrub back to last keyframe (if time accounting is sloppy for this format, overscrub by some amount, the run forward to the keyframe. If overscrubbing is significant, this is where you could compare the keyframe against the reference, to ensure you aren't way far back and needing to run forward further)
- okay, you've found your keyframe; advance (nframes - 1)
- profit
If he comes back and says "that's not fully general", that's true --- but the people asking for this don't care if it's fully general; it's suitable for common use cases and that's what they want. Let it work where it will work. Give up where it won't.
If he comes back and says "sure, that could work, but I don't have time, send a patch", well, okay, that's understandable.
What's actually happening is he's coming back and saying that won't work at all, that it won't support the majority of cases, will take too much compute, etc. and that's just flat out not true. You can do it selectively for the common cases. He might not want to, but that's different from can't.
Like, consider a scenario where you're playing back realtime video over a network connection. You won't necessarily be able to seek forward in that scenario -- you might not have enough video buffered, or hell, the connection could be plain interrupted. Imagine if they just didn't implement forward seek because the solution could not be fully generalized...
And who is going to spend time coding such a thing up, knowing that it is likely to be rejected as "not fully general"?