What would this support look like, in the context of JMAP? By the time the email is in your inbox it's already gone through server-side prefiltering. So the only integration I can imagine is a way to fetch and store Sieve scripts so you can edit them from your mail client, but that seems like a very provider-specific thing.
For example, Fastmail themselves support Sieve, except they don't give you a single editable script, instead they convert your structured rules and spam settings into 8 labelled sections in a Sieve script and give you 4 free-form edit boxes to insert your own code at specific points (so you can't edit the code that they synthesize for you). I don't know how a protocol like JMAP would expose this in a generic fashion.
8chan deliberately set itself up such that it's impossible to do anything beyond an IP ban. This was a conscious choice they made, and that doesn't mean they get a pass on failure to enforce rules as a result.
This isn't a free speech issue. We have free speech in most parts of our country without radicalization. This is an issue of a specific environment that actively celebrates hatred and awful behavior. "Free Speech" is a red herring. Just because it's legal to say this stuff doesn't make it okay to say it, and it's society's job to stamp out this kind of thing.
Do posters get banned? If it's not accepted on the board then why does it keep getting posted, and posted sufficiently often that many people are claiming 8chan has CP?
Only reference-counting actually stops dlclose() from unmapping the library, and that just means you haven't balanced out all the dlopens() (well, you can't unmap anything linked from the main executable, or anything in the dyld shared cache either, but those aren't particularly interesting cases). It's generally a really bad idea to unload a bundle containing Obj-C classes, but it's still doable if you can guarantee all instances of classes defined in that bundle have been deallocated (I'm not sure what happens to category methods, I hope the runtime properly removes those, but it's possible those would also cause a problem if invoked later). I assume the issue with Swift classes is identical to the issue with Obj-C classes.
In any case, image unloading is traditionally done with C libraries, not with Obj-C/Swift, and we're talking about a C function (atexit).
As for making it a no-op, they said only on platforms other than macOS, which is fine because the other platforms (iOS, watchOS, tvOS) are sufficiently constrained that there really is no reason to ever dlclose() anyway (there's barely even any reason to dlopen() besides trying to poke at Apple SPIs; I think sqlite will dlopen to load extensions, but that's about the only valid reason that comes to mind).
I question what the author was expecting to happen. If bar_exit comes from a dylib, and that dylib is subsequently unmapped, you can't very well call any functions from the unmapped library, so there's only 4 possible outcomes I can see:
1. The program crashes during termination as atexit() tries to invoke the previously-registered-but-now-invalid function.
2. The function is silently skipped as it's no longer loaded.
3. The function is invoked upon dlclose().
4. dlclose() does not actually unmap the library.
Of these options, only the 3rd actually seems reasonable. The first two are obviously bad, and the 4th seems like it rather defeats the purpose of calling dlclose() if you can't actually unload the library.
According to the page you linked, nobody is spec-compliant.
I'm going to guess that Google's lack of support for Safari boils down to video codec and nothing else.
> A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center.
Apple does not have any support for VP8/9, period. And I will be extremely surprised if they ever add support for a non-hardware-accelerated video codec. Apple believes in power efficiency over pretty much anything else, which makes hardware acceleration mandatory for something like this.
Google Meet is a video conferencing app, not a telephone replacement. AFAIK there's no way to "call" someone. So Web Push seems to be rather irrelevant.
> Network bandwidth on mobile devices is inconsistent, unstable, and often relatively low
I'm not using Google Meet on a cellular network. I'm using it on a wifi network. And if it comes to it, I'd rather have slightly worse video quality with H.264 than slightly better video quality with VP8/9 if it means it preserves my battery life (which is to say, set a network bandwidth target and then use whatever video quality meets that target).
> By restricting video to H.264, your stuck with a legacy codec that has relatively poor compression rates compared to the other standardized codecs.
It's apparently really hard to find an actual practical comparison of compression quality of H.264 vs VP8. What info I did find is about 8 years old now and itself was pretty wishy-washy. My vague impression of all of this is "lots of people think VP8 has better compression quality, but won't say by how much, while other people think you can get about the same results, but either way VP8 is rarely hardware-accelerated on mobile".
In any case, if you want better than H.264, how about H.265, which macOS and iOS both support? I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that.
While it's true that Safari only supports H.264, Google already produces quite a lot of H.264 video. In fact, Google has a Google Meet iOS app; I don't suppose you have any idea if they push H.264 to that app, or if they've actually embedded a software VP8/9 encoder/decoder into the app? I sincerely hope it's the former for battery life reasons if nothing else (though we already know Google doesn't seem to care about power efficiency).
To be honest, I think it's pretty bad that the company with the largest influence on the web is also the company that controls the largest web browser. Chrome should be moved to a different Alphabet company and Google forbidden from promoting it.
Google Meet still doesn't work with Safari, with no explanation. Safari supports the latest WebRTC, and AIUI Google Meet uses the current WebRTC standard, so why does Google refuse to let it work on Safari? This has to be deliberate.
Not at all. They could have actually put effort into it. The problem was that they didn't maintain it. They let it languish, staying exactly the same for years, good enough that nobody wanted to compete with a free product but not actually doing anything to improve the RSS ecosystem, so pretty much nothing happened with RSS for years besides it just existing. And then they decided to just shut down Google Reader with a relatively short time frame, because they never figured out how to monetize it.
They had 3 perfectly good options:
1. Don't build Google Reader in the first place if they weren't interested in actually maintaining the damn thing.
2. Put some effort into it, keep improving Google Reader, make the whole RSS ecosystem better rather than causing it to stagnate.
3. Sunset Google Reader over a much longer period of time, like a year instead of the 3.5 months they gave. Those 3.5 months were just barely enough time for people to build replacement services.
It was a close call. For a number of months there it looked like RSS was going to be well and truly dead.
The fact that my comment is being downvoted tells me that people here have a shockingly poor memory for this sort of thing.
And heck, it's not even the death of Google Reader that was bad for RSS. The life of Google Reader was bad for RSS too. It was a "good enough" product released for free, as in good enough that it wasn't worth trying to compete with a free product so nobody did, but it wasn't actively maintained and just served to cause the entire RSS ecosystem to stagnate for years.
Final Fantasy VI/III was a SNES game. The other 2 SNES Final Fantasy games were Final Fantasy IV (Final Fantasy II in the US) and Final Fantasy Mystic Quest.
> People are more reluctant to make wide sweeping changes such as renames because they're worried about the ensuing conflicts.
I disagree. People generally don't do project-wide find&replaces because it's just not all that common to want to rename a global symbol.
> Projects limp around with broken indentation (tabs/spaces), trailing whitespaces, dos newlines, etc - because fixing whitespace is against policy. Why? Conflicts.
You seem to have completely missed the point of my comment. I'm not saying projects limp along with bad whitespace. I'm saying projects that decide upon whitespace rules typically do a single global fixup and then simply enforce whitespace rules on all new commits. That means you only ever have one conflict set due to applying whitespace policy, rather than doing it over and over again as you suggested.
> You're applying the perceived diff to 1 version, which often differs from the actual diff as it may include subtle differences that aren't easily visible.
Then you're using really shitty merge software. Any halfway-decent merge tool will highlight all the differences for you.
> Without git-mediate? At best you bring up build errors. At worst, revive old bugs that were subtly fixed in the diff you think you applied.
And this is just FUD.
It's simple. Just stop using Notepad.exe to handle your merge conflicts and use an actual merge tool. It's pretty hard to miss a change when the tool highlights all the changes for you.
> You're talking out of your ass here.
And you're being uncivil. I'm done with this conversation.
> See the automated rename example. How do you gain the same safety and ease of resolution without git mediate? This is, unlike you say, an incredibly common scenario.
Is it? I'm not sure if I've ever had a conflict that would be resolved by a global find & replace. Globally renaming symbols isn't really all that common. In my experience conflicts are not "usually due to very wide, mechanical changes", they're due to two people modifying the same file at the same time.
> It is true for not only renames, but also whitespace fixes which are infamous for causing conflicts …
Most projects don't go doing whitespace fixes over and over again. In projects that do any sort of project-wide whitespace fixes, that sort of thing is usually done once, at which point the whitespace rules are enforced on new commits. So yes, global whitespace changes can cause commits, but they're rather rare.
> Instead of having to tediously compare the 3 versions to make sure you haven't missed any change when resolving (a very common error!) you now have to follow a simple guideline: Apply the same change to 2 versions.
> This guideline is simple enough to virtually never fuck it up
You know what's even simpler? "Apply the same change to 1 version". Saying "Fix the conflict, and then do extra busy-work on top of it" is not even remotely "simpler". It's literally twice the amount of work.
The only thing git-mediate appears to do is tell you if a project-wide find&replace was sufficient to resolve your conflict (and that's assuming the project-wide find&replace is even safe to do, as I mentioned in my previous comment). If you're not doing project-wide find&replaces, then git-mediate just makes your job harder.
From reading your "process" it appears that all you really need is a good merge tool, because most of what you describe as advantageous is what you'd get anyway when using any sort of reasonable tool (e.g. jumping between conflicts, showing correct diffs, making it easy to copy lines from one diff into another, making it easy to mark the hunk as resolved).
For example, Fastmail themselves support Sieve, except they don't give you a single editable script, instead they convert your structured rules and spam settings into 8 labelled sections in a Sieve script and give you 4 free-form edit boxes to insert your own code at specific points (so you can't edit the code that they synthesize for you). I don't know how a protocol like JMAP would expose this in a generic fashion.