> Is there somewhere they are saying the name is morally wrong?
Literally that wording? No.
But that's the same as a politician doing favors for their biggest donor and then pretending there's no pay to play here since you didn't literally see him taking piles of banknotes in a smoke filled back room. Come on.
> they made a commercial decision
Yes but why? Because according to them it promotes objectionable items/behavior - that's a moral decision, it is also a commercial one but based on a moral judgment.
A commercial decision is not a class on its own. It is taken based on some factors. What were the factors here if not that Apple finds the name/icon morally questionable?
From experience, I highly doubt it was actually unrecoverable. I did something similar many times & all it takes is to read archlinux.org news section & apply .pacnew config diffs where needed. Arch is a bleeding edge distro constantly marching ahead; that's one of its primary advantages, so it's best to update regularly. That being said it is very much possible to not update for months, just requires a bit of extra care when you finally do due to the large number of accumulated changes.
I even did an online, in place switchover from SysV to systemd in 2011 and despite that being a scary amount of changes at once still got a working system.
I have yet to see solid evidence it is any bigger of a nightmare than a mess of bash scripts that was what came before, but ok.
> taking over various network services ... poorly.
The networking features of systemd are entirely optional. If you don't know how to disable them if you don't want them, the right course of action is not to blame systemd.
People who grew up on SysV init like to shit on systemd as it erases their existing knowledge, but to pretend that SysV init wasn't a total, inconsistent mess or that anyone was maintaining consolekit before logind came around is distorting the truth, to put in mildly.
“systemd contains a lot of unnecessary attack surface; it attempts to do far more things than necessary and goes beyond what an init system should do.”
I’d want the author to explain this further. Perhaps they could tell the admin of the system how to reduce the attack surface, detail what services it should not be providing (and why), what services it provides that are worse than the alternative, and how to turn them off or harden them.
“An init system should not need many lines of code to function properly.”
That’s a ridiculous statement. Lines of code is an absurd measurement to determine the security of anything.
Systemd provides a lot of network functionality in systemd-networkd, journald, timesyncd, etc. that is remote attack surface. All the systemd "cloud of daemons" is tightly coupled by dbus interfaces that enable an attacker to move from one exploited system service to the next. Even if the attacker doesn't manage to find an exploit in another system service, DoS is easily possible because the DBUS interfaces are quite fragile. Even as a benevolent admin it is easily possible to get the system into a state where e.g. clean shutdown is no longer possible because systemctl doesn't want to talk to systemd any longer and you cannot fix that. systemd-udevd also has raceconditions galore, so sending any message to it in the wrong order relative to another one will kill the system, maybe even open exploit vectors. At the very least I would, for hardening, recommend not using any network-facing systemd functionality.
And lines of code are not ridiculous, they are the best first-order estimate available. Of course an actual inspection of the code is better for a comparison, but that is a huge task. sloccount is quick and easy.
> Systemd provides a lot of network functionality in systemd-networkd, journald, timesyncd, etc. that is remote attack surface.
Everything systemd does is something the OS was already doing before, just using a bunch of independent-upstream-project daemons glued together with RC scripts. That attack-surface existed before. That LOC-count existed before. It just wasn't monolithic under one project/org, and so wasn't being perceived as a problem.
The various interactions between daemons, also weren't getting audited during upstream-project security audits, because all the interaction potential only existed in the downstream distribution, rather than being part of systemd's monolith + integration test-suite.
> DBUS interfaces are quite fragile
What, and what it replaced (arbitrary ug+w sockets in /var/run, speaking to custom one-off RPC-listener ABIs for each daemon) wasn't fragile?
IMHO, all that's changed is that there's more uniformity, meaning a single set of tools can be used to test+harden all such RPC interfaces, and security flaws can be fixed in one place (DBUS itself) rather than requiring theory-level descriptions of vulnerabilities to be communicated to each project, whereupon they're hopefully translated to separate one-off patches the affected daemon.
> systemd-udevd also has raceconditions galore, so sending any message to it in the wrong order relative to another one will kill the system, maybe even open exploit vectors
100% true of what came before it. Hell, some of my Linux systems from the 90s and early 2000s would lock up hard just because I `modprobe`d a webcam driver when the webcam was already USB-connected.
> What, and what it replaced (arbitrary ug+w sockets in /var/run, speaking to custom one-off RPC-listener ABIs for each daemon) wasn't fragile?
Sockets like initctl are far less fragile. You don't need a dbus-daemon that you can't restart if you cant talk to systemd. Your parser needs to recognise single-character commands instead of a complex rpc syntax plus an xml parser or javascript vm for filtering. You can't honestly believe DBUS isn't miles from the robustness of initctl.
> IMHO, all that's changed is that there's more uniformity, meaning a single set of tools can be used to test+harden all such RPC interfaces, and security flaws can be fixed in one place (DBUS itself) rather than requiring theory-level descriptions of vulnerabilities to be communicated to each project, whereupon they're hopefully translated to separate one-off patches the affected daemon.
Instead of easy-to-audit socket permissions you get a complex mess of xml and javascript filtering rules. This isn't progress in terms of security, its quite the opposite. Pounds of additional attack surface and additional obfuscation hindering defense.
What systemd gives is structure + consistency; service definitions are declarative and knowledge distro portable.
To me that that is the big benefit of systemd over sysV init.
> Pounds of additional attack surface
Again, show me a major in the wild exploit that abuses these supposed 'pounds of attack surface'. As was said before, systemd doesn't actually have that much new surface that wasn't there before. It's just before it was not maintained in any sort of organized manner but rather was scattered across tens of different projects in various state of no longer being actively maintained, as I said consolekit is a perfect example.
systemd is actually pretty modular. You don't have to run the components that are not useful to you thus limiting the attack surface greatly, if you're actually concerned about it.
I know some people have an allergic reaction to Poettering, but the guy's willing to touch some of the rotten parts of the ecosystems few others dear.
> People who grew up on SysV init like to shit on systemd as it erases their existing knowledge...
Painting people who doesn't like systemd like old, beardy creatures afraid of learning new stuff is extremely simplifying the situation if not being misleading.
My personal opposition about systemd is about binary logs and going against "doing one thing, well" principle. I may rant it all day long about the things I don't like about systemd and praise its useful features for a similar amount of time but, I'd never bring up "I learn to everything from ground up again!" as an issue.
Software evolves, everything evolves. We need to adapt regardless of we are system administrators of a big farm or a user of a measly Linux system.
> My personal opposition about systemd is about binary logs
syslog-ng supports the systemd journal natively so you'd never see a difference from before if you don't want to.
> doing against "doing one thing, well" principle
The principle is dogma that has held back Unix imo. It's useful for simple CLIs but that is about it. By your definition the kernel itself goes against the principle.
systemd is a systems manager, it takes care of it during its entire lifecycle, keeping home directories portable is one thing it can do for you that is entirely optional but very useful, managing containers is another. These are however separate components - homed and systemd-nspawn respectively. It is not all rolled into a single 'systemd', this is a misrepresentation.
systemd is very modular. People like to paint it as a monolith because it lives in a monorepo for the most part, but it is not actually built as one and individual components can be disabled or swapped out.
> syslog-ng supports the systemd journal natively so you'd never see a difference from before if you don't want to.
We use rsyslog with systemd and it works too, however it's just another level of abstraction so, I'm not fond of piling stuff over and over. Binary logs' and journals' usefulness can be also debated. It of course brings some advantages to the table but, it doesn't enable anything groundbreaking for me.
> The principle is dogma that has held back Unix imo. It's useful for simple CLIs but that is about it. By your definition the kernel itself goes against the principle.
Actually I don't consider it dogma, because it has some very important results and corollaries. This principle reduces secondary complexity (glue logic, complexity required to do many things with one code base, etc.) greatly hence the software can be relentlessly optimized. grep, find, sed, awk, cut, head, tail, less all are extremely performant tools. I develop high performance scientific applications and making a tool accomplish more than a couple different functions either reduce performance (generalized algorithms) or increase size a lot (specialized functions for everything). Its refactoring, verification, maintenance gets complicated and expensive fast.
UNIX pipes and small optimized tools are much more useful beyond simple CLI commands and small scripts. Since the tools are fast, low memory footprint performance behemoths, you can build very fast and reliable machinery with them. You can even do data mining with them [0]. We have some impressive stuff running under the hood in our cluster which only use standard GNU utilities.
Also, tools like rsync and rdiff can lift much more than their size. They're proverbial ants of data transfer and they also do one thing well. Same thing can be said for vi and nano too for text editing. Similarly, modern tools like Atom still shudder and die with a single big file while using extreme amounts of memory. OTOH, vi doesn't even sneeze with files thrice as large.
Kernel doesn't breach this principle either. It provides an interface between the hardware and software & lives in its own space; that's it.
> systemd is a systems manager, it takes care of it during its entire lifecycle, keeping home directories portable is one thing it can do for you that is entirely optional but very useful, managing containers is another. These are however separate components - homed and systemd-nspawn respectively. It is not all rolled into a single 'systemd', this is a misrepresentation.
The problem with systemd is not purely technical. Also, I want to be clear that I'm not a die-hard systemd critic. The technical side can be summarized as "Hey! This thing is complicated, developed very fast and can bring some (stability and security) problems back during its teething. Please be careful". Other side is social and can be summarized as "Hey! You're developing this, but you're not listening to us and pushing your opinions down to us using your power. This dangerous in every aspect. We can develop this together to something better but, you don't listen to us.".
Also I want to remind that, parallel sysV-init was pretty fast machinery and was very manageable.
I'm aware that systemd is modular. I'm not using more than half of it right now and I'm happy this way. One of the problems with systemd is opaqueness. When systemd overtakes a part of the system with its module, it's very hard to discover it. Disabling the module and using an older or alternative approach is also not straightforward sometimes. As a result, systemd feels like an overzealous octopus with no indication of its intention. Holding everything it can reach with a death-grip and requiring some serious strength to pry it off.
With a better communication and feedback loop, we'd be in a very different place. Maybe systemd would be the same systemd but, without the unproductive rock-throwing, flaming & shouting.
Linux is evolving like every other software or anything in life, but some ground principles are much more valuable than they seem. Throwing them away and labeling them as dogma just because they're old is considered harmful and dangerous.
> I want to remind that, parallel sysV-init was pretty fast machinery and was very manageable.
That does nothing for the fact that SysV init was a pile of shell scripts inconsistent across distros and even individual packages. I'd take systemd's declarative, portable service definitions any day over that mess.
SysV init did not take care of consolekit being an unmaintained mess either. systemd did.
Besides, systemd can recognize that I had plugged in a specific kind of device that needs this sort of setup and do that for me automatically. Hence the 'manager' part. None of its supposed 'competitors' can do that themselves.
> Kernel doesn't breach this principle either. It provides an interface between the hardware and software & lives in its own space; that's it.
I don't know, eBPF for example is an entire complex beast of its own that could be argued to violate that, well beyond what's 'required'.
If you take the view that as long as the system has a single defined job, (interfaces to hardware and exposes APIs to userspace for the kernel), systemd does have a definition like that too. It manages the system's dynamic resources during its lifetime. That's a 'single' job. It's not if you decompose it, but the kernel is in a similar situation at that point.
> When systemd overtakes a part of the system with its module, it's very hard to discover it.
systemd does not do that, sounds like you're blaming bad distro defaults (optional components being enabled by default) on systemd.
> That does nothing for the fact that SysV init was a pile of shell scripts inconsistent across distros and even individual packages.
I've never seen the inconsistencies, sorry. All the service files I've written were greatly portable around what I've used so far.
> SysV init did not take care of consolekit being an unmaintained mess either. systemd did.
No other service should hide the shortcomings of other services. This sounds like WoW's extreme tricks or Kubernetes' dockershim layer to keep compatibility. Now, doing this is wrong.
> Besides, systemd can recognize that I had plugged in a specific kind of device that needs this sort of setup and do that for me automatically. Hence the 'manager' part. None of its supposed 'competitors' can do that themselves.
That's the point. If that task can be handed over to another daemon (like udev) for setting it up, why systemd assumes that setting it up is its job? I'm not trying to say that doing this is flat out wrong but, when asked about why, getting "we're doing it , because why not?" as an answer leaves a bad taste in the mouth.
> systemd does not do that, sounds like you're blaming bad distro defaults (optional components being enabled by default) on systemd.
I think I failed to convey what I tried to say there. I wanted to say that there's no easy way to see whether a feature is managed by systemd or not and hence systemd tries to "self-heal" things sometimes, system management becomes a tug-of-war until one understands that systemd is managing that. If there was an easy way to understand that, it'd be an easier path.
All in all, I personally don't oppose what systemd brings to a table and see the inspiration from macOS' launchd. However, the main thing I strongly oppose and criticize is the blind egg-throwing to other init systems, the overzealous
protection of systemd and avoiding discussing its potential shortcomings and problems altogether.
I want to reiterate that I'm not against change and evolution, I'm against forcing it with a stance of "we, only we know the best. now shut-up and use it!".
I've seen plenty to convince me that having a full shell scripting language and not a very good one at that as your service definition language is a terrible idea.
> No other service should hide the shortcomings of other services.
I don't think you get it. It is not hiding the shortcomings of other services. It is implementing its own service because the other one was a pile of unmaintained crap. But I guess that kind of security risk is OK as long as it's a separate repo? What a weird dogma.
> That's the point. If that task can be handed over to another daemon (like udev) for setting it up, why systemd assumes that setting it up is its job?
It does hand it over to udev, but someone needs to notify udev stuff is happening. systemd has easy access to that information so it does the job. Also, you do realize that the people who maintain udev are the same who maintain systemd right? Again, because it was a hard job and nobody else, including other init systems, were willing to pick up the slack.
> what I tried to say there. I wanted to say that there's no easy way to see whether a feature is managed by systemd or not
I understand that but imo that should be on the distro to communicate. On Arch for example, the wiki always gives a clear indication of whether a thing like DNS can and is managed by a systemd component or not.
A `systemctl component list --status=enabled` would perhaps be a nice addition, agreed.
> I strongly oppose and criticize is the blind egg-throwing to other init systems, the overzealous protection of systemd and avoiding discussing its potential shortcomings and problems altogether.
It's funny you say that because as a very early adopter of systemd I saw things up close and it was the exact opposite. People were literally threatening Lennart Poettering with violence for writing a (good imo) piece of free software. That he decided to stay on the scene despite that is honestly remarkable.
But as for other init systems, I don't doubt there's some good ones, sysV init wasn't it, but the main problem is that all the others seem only interested in the init part and are happy to depend on rotten parts of the ecosystem. Unlike systemd, none of them were saying; 'ok, consolekit is unmaiintained, let's pick up the slack on session management' (maybe in a separate repo if you insist) or 'oh, udev is struggling, let's pick up the slack' - no they were like am going to do init and hope these other pieces don't come crashing down like a pile of bricks.
Also, I've started using systemd-homed to make my setup portable across my machines. None of the supposed competitors of systemd offer that either.
I like to compare it with PulseAudio; people suggest to me all the time how OSS, ALSA etc. are 'good enough' etc. but I have a fully FLOSS wireless audio house setup right now thanks to PulseAudio, none of the supposed 'competitors' offer that, so they're not competitors for me, (PipeWire eventually might by literally re implementing all of Pulse).
bayindirh is raising valid points of criticism, which I think you can tackle without trying to raise a stink.
The point about scope e.g. isn't "weird dogma" imo, but very valid, because it has security implications for an init system.
The points you raise about unmaintained alternatives is also valid, but doesn't invalidate his criticism.
I understand you feel that systemd has been treated unfairly before, but I suggest you shouldn't try to match the level of spite and throw it the other way, especially when someone is very nicely bringing up what they are worried about.
> I've seen plenty to convince me that having a full shell scripting language and not a very good one at that as your service definition language is a terrible idea.
If we look enough, we can find convincing examples about Python being very backwards and brainfuck being the best language in the world. I had a friend who tried to solve every problem in OCaml. Another one thought that Lisp is the one and only way to do anything with computers. If there's one important thing I've learned over the years, it's the harmful nature of being fixated to ideas. Again, I want to re-iterate that I'm no enemy of systemd. I use it everyday on a 1000+ server fleet. I also used sysV-init on the same fleet. Both got the job done, albeit differently.
> I don't think you get it. It is not hiding the shortcomings of other services. It is implementing its own service because the other one was a pile of unmaintained crap.
Yep, I didn't get it. I missed when systemd reimplemented/replaced consolekit. I thought it shadowed it and hid its shortcomings via intervention, my bad, honestly. When systemd started to get adopted fast, I was working literally underground in a time sensitive project, isolated from outside world. I spend ~2 years without being able to track this stuff closely.
> It does hand it over to udev, but someone needs to notify udev stuff is happening.
I thought there were external mechanisms which notified udev reliably. I remember triggering it for a USB flash drive related event, intertwined with PAM, some network services and other inputs.
> Also, you do realize that the people who maintain udev are the same who maintain systemd right?
Nope, I was buried underground, cut-off from outside world. Again, it's one of the parts I've probably missed.
> Again, because it was a hard job and nobody else, including other init systems, were willing to pick up the slack.
Other init systems didn't notify udev because they thought that it's not their job but another deamon had to do it, because other so-called competitors only care about services. Hardware, hostname, time, resolver, containers, home folders, and the kitchen sink shall have their own daemons they've thought probably.
> It's funny you say that because as a very early adopter of systemd I saw things up close and it was the exact opposite. People were literally threatening Lennart Poettering with violence for writing a (good imo) piece of free software. That he decided to stay on the scene despite that is honestly remarkable.
I'd never threaten anyone about the software they write or the way they behave. Again, at that time I was underground so I had no chance to see it. I also don't support anyone doing this to anyone, for any reason. However, if one of my fellow developers got banned from submitting patches to kernel because they're not fixing their own mistakes and kicking everyone like a spoiled goat, I'll definitely have a good talk with him about it. Using fame to blame others is not the good way to do it.
> But as for other init systems, I don't doubt there's some good ones, sysV init wasn't it, but the main problem is that all the others seem only interested in the init part and...
Pardus' "Mudur" was similar to systemd in many aspects however, it was so integrated that it was not possible to install it part by part. It was faster than both upstart and parallel sysV-init ever be. IIRC Ubuntu wanted to use it, but adopting it was too disruptive and they gave up the effort.
> Also, I've started using systemd-homed to make my setup portable across my machines.
If that fits the bill, that's nice. I don't need portable homes across my systems (all of them are intentionally setup differently due to reasons and preferences) and wouldn't use it for now. If I decide to use it, I'll enable it but, I'm fine with the old method now.
> I like to compare it with PulseAudio; people suggest to me all the time how OSS, ALSA etc. are 'good enough' etc. but I have a fully FLOSS wireless audio house setup right now
PulseAudio brought some needed things to Linux audio, but it needed a lot of hammering in the head to bring it to this level. Initial implementation was a bit boneheaded in behavior. Its automatic umpixing of stereo streams to multichannel still doesn't make sense in most cases. So it needs more sensible defaults from the source tree.
Also, you use the word competitor in a rather aggressive and provocative way. I don't know whether that's your intention but, we're just conversing here. I'm not angry or something or I'm not trying to sabotage the projects you like. I'm just telling the things I see as wrong and try to make some constructive criticism. I may be failing at doing it in an excellent way, but I'm no way hostile to you, or the projects in general.
You know? There were init systems before systemd, working differently than 'with bash scripts', and working very well. They still are available, still working very well, still being developed, still adapted, still lean and mean.
This dichotomy systemd vs. SysV init is simply false, and only applies to the fortgeschrittene Fertigfutterfresser who are slaves of shrink wrapped anything ready to run.
Like obese McDonaldians, trying to discuss gourmet-food :-)
Were these other systems willing to pick up the slack in maintaining consolekit or coming up with their own solution? Didn't look like it. What about udev? Why did systemd devs have to pick the slack on that too?
Is is perhaps because the other init systems are only willing to touch a very narrow definition of init while depending on rotten, unmaintained pieces of the ecosystem like consolekit without being able/willing to maintain it themselves?
Or perhaps the plan is to let systemd folks do that while shitting on it so we can cook up a 600 LoC 'minimal init' while outsourcing a whole lot to systemd maintainers while taunting our minimalism?
> I used to be a big WikiLeaks supporter but these days are long gone.
Then you've been duped. The prosecution of Assange is based on his work with Chelsea Manning on US war crimes in Iraq.
But if the lives of poor brown people far away are not as important as cheap partizanship then the CIA can make you believe anything.
Not to mention the fact HRC called for the assassination of Assange and his treatment has been characterized by the UN as torture. I presume you're OK with torture too as long as you think it serves your club?
> Not to mention the fact HRC called for the assassination of Assange and his treatment has been characterized by the UN as torture.
The claim of Clinton calling for Assange's assassination seems to be a completely unsubstantiated rumor.
Your "torture" claim is plainly false (even if it were true, what's the point in appealing to the authority of UN?), the "characterization" is by Nils Melzer, UN special rapporteur on torture (so he's just something like an independent consultant).
More importantly, basically everything Melzer said about Assange is bullshit. I read the interview of Melzer that seems to be the source for all of the absurd claims; and all of Melzer's claims there are vague, unsubstantiated, unverifiable or nonfalsifiable; except for one:
Turns out that Melzer's only concrete accusation is based on a misreading of evidence at best; the one against the Swedish police, of how they supposedly tampered with (even fabricated) one of the testimonies. The evidence for that is inconclusive, Melzer was possibly confused with the format of the Freedom of Information documents released by the police, but in any case Melzer is making a big fuss out of nothing and downplaying rape with his other comments at the same time.
Also see the comment by one of Assange's alleged victims:
> One of the women interviewed by Melzer later sharply criticised him and demanded his resignation. She said that by defining how a "proper rape-victim" would have to act, Melzer was engaging in victim blaming and that his report was partially "untrue and defamatory"
I think it should be pretty clear that Melzer's word is worth very little.
The only dupes at this point are the useful idiots who still support WikiLeaks. It has long since passed from being anything useful into being an cult of personality built around Assange.
I'd call it halfway between cult of personality and idealistic belief that maximizing free flow of information maximizes beneficial outcomes without attention to measuring whether that assumption is true.
It turns out some secrets are harmful, and some are helpful to the stable function of a society. Practically speaking, I believe it is hard to make a case that Wikileaks has been a net positive, unless one can see a president Trump as part of a net positive story. On the flip side, history is also dotted with obvious examples of secret keeping resulting in long-term damage.
The truth, I think, is that the beneficial nature of secrets is something you can only evaluate situationally.
The Manning leaks were hugely irresponsible. While whistleblowing is a vital activity, the data dumps Manning pulled from the military network and State Department were unredacted raw dumps. They catalyzed Arab Spring by pushing the delicate realm of international diplomacy into the eyes of the public, leading to hundreds of deaths and, fundamentally, no real change. Possibly setting back democracy in the Middle East by a generation or so.
I like Manning as a person, but state secrets exist for a reason and she deserved to be imprisoned for her crimes.
> The Manning leaks were hugely irresponsible. While whistleblowing is a vital activity, the data dumps Manning pulled from the military network and State Department were unredacted raw dumps.
WikiLeaks tried to get the Pentagon to help them redact documents[1].
They refused to do so knowing there would be people like you accusing WikiLeaks/Manning of wrongdoing here.
> I like Manning as a person, but state secrets exist for a reason and she deserved to be imprisoned for her crimes.
You do realize she shed light on war crimes right? Do you consider war crimes 'state secrets' that 'exist for a reason'?
The reason, oftentimes, is simply to hide wrongdoing, as was the case here. The fact Manning was imprisoned, (and tortured), while the killers of civilians and journalists she exposed were not shows that this is not a just system. It's designed to chill whileblowers and allow atrocities to continue, unpunished.
The military leaks did shed light on (possible; there is dispute in the international community) war crimes, and had Manning only leaked those specific videos, my opinion would be very different.
The State Department cable leaks were grossly irresponsible, as were most of the rest of the military intel leaks. She slurped and dumped without understanding of the ramifications of divulging all that information, which can endanger her fellow soldiers in the field, who had not committed war crimes. That she appears to have gotten lucky and it did not, in fact, endanger soldiers in the field is irrelevant to the reason such a slurp-and-dump is a court-martial offense.
I think reasonable people can disagree on whether, in aggregate, she did more harm than good. She shed light on (what we would want to be) senseless deaths of several civilians in a military theater, and separate from that, she catalyzed multiple revolutions resulting in the deaths of hundreds.
>You do realize she shed light on war crimes right? Do you consider war crimes 'state secrets' that 'exist for a reason'?
What warcrimes? Please be specific. Because if you're talking about that Helicopter gunship video, that was not a warcrime, and was selectively edited by Wikileaks to try to make it look worse. All of which made Wikileak's claims far more dubious.
Wikipedia gives a pretty good summary of how one arrives at that conclusion. https://en.wikipedia.org/wiki/July_12,_2007,_Baghdad_airstri... --- the short form is that the laws around war crimes give broad leeway to soldiers in the field interpreting a situation on the ground, and from the point of view of the gunship, they may have believed they were firing on attackers attempting to reach RPGs in the vehicle. This is one of the tragedies of modern insurgency warfare... Since nobody's in uniform, how can one be sure that the person in civilian clothing crawling through the operation is trying to escape or going for a concealed weapon?
I'm personally inclined to agree with Mark Taylor that "...what this video shows is really a case that challenges whether the laws of war are strict enough."
Within the US, there is a similar broad cultural argument ongoing on whether laws protecting police officers err too far on the side of assuming the cops' in-the-field interpretation of what happened should guide how the law understands what happened.
The Apache gunner did not know that they were firing on a journalist, they had believed they were engaging a legal target and were doing so within given rules of engagement. Which is legal. It's a tragedy that they were mis-identified, but again, not a warcrime. Had they known they were non combatants and fired on them still, that would have been a warcrime.
I suspect many who believe in meritocracy are already successful people who like to tell themselves they got there by merely being so much smarter than everyone else around them, dismissing the access, luck, (i.e. quality of schools they were born near), family wealth etc. almost entirely as a factor.
I personally just think everything works better when the best people are in charge and rewarded for being the best. Yes, there's tons of luck, and it's not fair in any "everyone deserves a shot" sense. Still a better strategy, because most people are bad at most things. We should take care of them, but we should not pretend they're competent if they're not.
> I personally just think everything works better when the best people are in charge and rewarded for being the best.
The problem is that they're not necessarily the best i.e. some poor person if given the same resources, education, access etc. might in fact do a lot better with what they have, we'll just never know.
I mean if you look at the state of today's world, handling of COVID, shams like Nikola etc. are these really the 'best' people humanity has to offer?
How is "being smart" a genetic lottery? Are you serious? That brings up all sorts of implications with race and whatnot. "Being smart" is often a proxy for the things the GP mentions: strong stable family, access to good schooling, and a sprinkle of luck.
The previous comment's argument appears to be that heritability of "being smart" is not strictly limited to genetic factors, that measures of "smartness" such as an IQ score also measure other factors that are not strictly related to genetics
Heritability and genetic factors are overlapping but distinct things - for example, socioeconomic status influences many aspects, is hereditary but not genetic.
> Russia involves itself only in affairs of few neighboring countries
Was presumably meant in reference to neighboring countries where Russia involves itself to the point where it would be wiser for a citizen of such a country to store their data in the West.
The U.S. is not a country fitting this definition by any stretch.
The USA is Russia's chosen archenemy (regardless what half of Americans think), with most of Russian intelligence, military and diplomatic effort focused on confronting it. Even when Russia screws over its smaller neighbours they always explain it away as countering America.
But even if it wasn't this whole argument is the good old "I don't have anything to hide" re-stated but for foreign powers. It goes fine until you end up with your piss tape.
Speaking to Russians, they'd tell you that they'd love to get along with the US, but that Americans only have 2 modes of operation i.e. be submissive to US like the EU is, (that certainly is the case with the EU as someone living there I can conform, just look at the weak EU response of the US pulling from the Iran Deal for example), or be an archenemy that needs to be vilified & threatened.
They'd tell you that NATO is threatening their borders & that the US would never tolerate Russian troop buildup in Mexico.
Take the 2016 US election as an example, everyone freaked out. Hardly anyone ever mentioned that the US started meddling in Russian elections more than two decades earlier.
Granted, I think the current 'setup' with the US being the archenemy suits the Russian government just fine for domestic audiences, which is especially ironic as it actively hurts real, independent, democratic movements.
It also suits US defense contractors, 'cyber' experts and various grifters offering to combat misinformation.
It means that T does not have non static references, so it is not a requirement that it lives for the lifetime of the application but can do so.