What gets me is all this fuss over words in the damn *comments*. Who gives a crap either way.
Changing a pronoun is not worth of developer resources. I would have reversed it too -- we don't need everyone's principled opinions infiltrating the codebase and starting problems between people's values and beliefs.
The thing is, the change was done by some third party. Rejecting it and justifying actually took *more* work than just accepting it. The change was just inside comments. Now if the change was to function names or something, that would be different.
If I were faced with a commit that just changed he to they or he to she or she to he or they to he, I'd probably accept it because I don't care what a comment says. The exception would be if it became apparent that two committers cared in different ways about such an asinine thing, then I'd have to think. As this stands, someone rejected a practically patch that some people cared about and should have just accepted the damn patch.
People don't fork 'just because they can'. They fork because they are failing to get what they want out of the project. It remains to be seen if they are wasting their time.
It could be like ethereal to wireshark, where the holder of the copyright has precisely *zero* development skin in the game.
It could be like XFree86 to Xorg where both had some nominal capability to continue, but it becomes quickly apparent that the fork is where the development effort went.
It could be like Wayland fork where the fork pretty much died (though the main project isn't seeing massive adoption either).
Worst case would be something like the ffmpeg/libav fiasco, where both forks go and which one is available readily for a given distribution is almost more a matter of politics than technical merit, and yet they have significantly diverged.
A 'project' is a vague concept. What 'sponsorship' means can be vague too. Are they providing hosting services? Are they managing the authentication configuration? Did they impose some CI where they get final say? Did they provide employment to some or all participants? Did they pay as part of a contract arrangement for the time of some developers?
In short, knowing how corporate sponsorship historically happens in open source, the corporation maybe provides some contribution, but does take control of the project hosting and copyright such that the 'authoritative' source follows their will, but they do not actually offer many of the developers financial benefit or bind their hands to fork.
This happens not infrequently to very prominent software in open source land, sometimes without the commercial facet. MySQL and MariaDB. Ethereal and Wireshark. gPXE and iPXE. XFree86 and Xorg. ffmpeg and and libav. Openoffice and Libreoffice. Usually it becomes clear where the *real* meat of development was and only one fork is technically viable.
Why I said 'for most'. High end database applications with poor data locality in datacenters is not really something 'most' have to contend with. If I tried to be comprehensive in my statement, the people that understand the nuances would recognize and I'd be preaching to the choir, but most would glaze over and skip it because precisely and accurately describing the entire reality is too complicated for most to want to read.
I don't know why Intel and Micron get any special consideration given that right in the summary the fact that Samsung has already announced the same move.
Also incorrect assertion that drives don't go faster than 7200 (there are 15k drives, just they are pointless for most with SSD caching strategies available).
a) The prosecutor wants to bring a prosecution if the evidence allows
I'm assuming that if the prosecutor doesn't *want* to get a trial, they similarly would not *want* to win a trial. I'm not saying they are trying their best as a given, I'm saying that their effort in trying to get a trial should be indicative of their effort in winning a trial. One should not expect a prosecution team that did not get a trial would do a better job of incriminating a guilty party *at* trial should one have been hypothetically held. I'm trying to ascertain who the hypothetical party would be presenting the defendant in a *more* negative light than the prosecution.
Breaking down how this thread has proceeded, it *sounds* like you are saying that the prosecution wanted the grand jury to think that the deceased was being aggressive, and that somehow during trial some other party would convince them that the deceased had surrendered. The defense would not do that. If the prosecution willfully did that in the hearing, why would they change mind in a trial?
As did the decision not to indict.
I don't think anyone interprets this to mean a person should be *forced* to face trial when they otherwise wouldn't actually face charges at all. I cannot say whether the defendant *should* have faced a trial in this specific circumstance. However imagine you have pissed off a district attorney in a perfectly legal way (dated their ex-spouse or something). If that DA could retaliate with malicious prosecution and force you to be in a trial without any cause whatsoever, I don't think you would appreciate that your right to a fair trial of the accused was not interfered with when it could have otherwise would have been completely dismissed.
The US justice system is designed such that it resists being used to harass an innocent person to the point that it errs on letting the guilty off in some cases. This is not to say innocent people manage not to face abuses at the hands of the system, but that things are just set up to mitigate that risk and there are tradeoffs.
A trial, while imperfect, is adversarial and offers the chance to present more evidence and make counter arguments on any terms. The grand jury was limited to what the prosecutor decided to allow.
If the prosecution is not going to make a strong enough case to even *get* a trial, they sure as hell wouldn't make a strong enough case to *win* a trial. Who do you imagine would present stronger evidence than the *prosecution* implicating the defendant? Do you think the defense is going to do that?
If the prosecution was sympathetic to the defendant as you imply, then a trial wasn't going to do any better, because the only party interesting in proving guilt is by definition the prosecutor. I frankly haven't followed the facts of the case well enough to agree or challenge that implication, but the logical consequence of the implication doesn't suggest a trial would have gone differently.
Hydrogen is a terrible energy storage medium compared to modern battery technology.
Well maybe for combustion, but wait til we put fusion plants in every car...
In the TV market, they were valued because the cable/broadcast/satellite services had no idea what frequency band users were paying attention to and thus no idea what was effective and what was not without some proactive examination of the viewer base. This was important for the program producers to value product placement, integrated advertising, and for the cable/satellite people to know what content was worth/not worth licensing.
For unicast streaming, the streaming service knows *precisely* what the users are paying attention to. For content producers, they control the licensing terms so they should be able to force Hulu, Amazon, and netflix to provide data as part of the deal of licensing it, in order to have data for soliciting things like product placement.
The streaming services themselves have all the data they need to entice advertisers that are independent of the content. Additionally, the advertisements are in no way hard linked to the streaming media. If the service wants to show you that ad, they don't need to give a rat's ass about *which* program you are watching.
Certainly the people providing the service know which pieces of content they license and how much they are watched to evaluate relative value of their library.
So the two remaining purposes are to let Amazon know which parts of Netflix library are valuable enough to fight for versus not bothering, and academic curiosity of the viewership. Of course, the former might be workable by requesting the data from the content owners as part of negotiations, and the latter doesn't really mean revenue...
Neither side is being particularly constructive in helping fix systemd's issues.
Those in the systemd camp largely plug their ears and just think doubters are merely stubborn or unsophisticated enough to understand just how *awesome* it is and that it is worth the downsides (if they'll even admit something is a downside).
On the other side, mostly the criticism is just roll back and leave things as-is. Which leaves systemd advocates unhappy because they don't get their shiny capabilities at all. Not much discussion is had on how to amend certain strategies to placate the sensibilities of today while delivering the capabilities of something new. For example, if journald simply made plaintext logging alongside (not as a downstream add-on by piping to syslog, natively doing it alongside binary data), people would probably not balk nearly so much. If a systemd unit could degrade to start without being able to talk to pid 1 or cgroup support available (with loss of function), then some debug activity is made more straightforward in a rescue environment that may chroot (yes, spawning a container is usually possible, but why not degrade to cope to the extent possible). If open ended init scripts were better accommodated and didn't try to forcibly constrain sysv init scripts to force it to fit the only models that systemd understands.
Of course some concerns are more fundamental (bringing everything possible under one monolithic development effort rather than modular design that has discrete owners using simplistic yet consistent vocabulary to communicate with each other). But a lot of the specific technical issues could be alleviated by modification of systemd while preserving the stuff that there is to like.
It's like predicting how these 'automobiles' will be a big part of our lives (news is 100 years too late, but at least accurate). Predicting the future by simply stating the present, brilliant!
xbmc can do what plex does... if you mess with advancedsettings, apply a ton of special filename recognition patterns, set it up to store things in a shared sql database, and trick it into having an instance running somewhere headless and prod it to update library ever so often. For plex, they have a naturally headless server that takes care of all of that.
On the flip side, there is a gob ton of stuff I can do with xbmc that I can't with Plex. One painful one for me is integrate with my mythbackend *kind of* (still missing the closed captioning of ATSC streams, only mythfrontend seems to handle it).
I think my ideal world would be for xbmc to have a headless, auto-indexing library server that shares it's 'advancedsettings.xml' in a more trivial fashion and subtitle support for ATSC streams. The etensibility and community of xbmc with the simplicity of Plex and a tiny amount of capability from mythfrontend that is lacking...
But my ISP provides an SMTP relay. I configured postfix to use my ISP relay. This doesn't really impact my mail service or how it's stored or how it may be addressed/migrated in the future, but it gets me past the common blackhole filtering.
SMTP has just not scaled well and the mitigations have impaired the openness of the network somewhat, but SMTP relay facilities are usually available.