I think the civil burden of proof should apply here. Upon the preponderance of the evidence. Given so many studies that exhaustively show correlative effects of phthalates with metabolic and endocrine disruption, especially strongly during developmental stages, I think even that burden of proof is met.
Sure, you can't prove something doesn't exist, but you can make a reasonable determination that given exhaustive study, given correlative negative effects can be ascribed to no other known cause, and given that this is natal and pediatric health especially at stake, we should say until such time as a causative link is proven to lie elsewhere these chemicals should not be used in consumer goods out of an abundance of caution.
The redirection of that claim would be "these profits are more important than moving to protect bodily health especially for those unable to protect themselves, given what we currently know."
Honestly, no knowledge is perfect, but upon the balance we must rest our sacrosanct right to health.
You forget, the reason systemd was originally rationalized for its insertion into our trees was "boot times are too slow". Its chameleon-like nature and ability to solve the hastily described problem du jour seems to be its only consistently touted feature.
Bash scripts that start processes are ephemeral. If it's signal handling you want, that was your program's problem. Either that or your program didn't fork itself, which is a fish of an entirely different feather.
And now we have this sprawling mess of complexity and headache.
Wayland was a mis-fire in terms of user friendliness for the first decade or so. But it is still a big step up from the mess that was a typical xserver back in 2010.
> It reduces features adds complexity...
The irony here is Wayland is part of a huge effort to decomplex an xserver into component parts. A really commendable initiative; the path forward while maintaining the X protocol probably was impractically hairy.
The Wayland protocol design had some glaring flaws, but saying that it adds complexity is unfair. It oversimplified; it would have benefited from some flexibility in providing a standard mechanism to let people inspect the buffers graphics buffers to be composited.
Wayland by itself is simplier -- it is done by "outsourcing" everything a window system should do to the window manager.
There is where the complexity kicks in.
The resulting wayland environments are more complex because wayland itself refuses to define/include features that desktop systems are expected to have. This results in a sprawling mess of competing and incompatible interfaces for those gaps that other parts of the implementations (desktop environments) now have to compensate for by including multiple implementations of the same thing based on all these different interfaces.
Ssh and its child processes are just another agent. Agents of a model that must be up at time-of-convergence as seen from the coordinator node; a remarkably inflexible arrangement that can only be addressed with additional development not otherwise necessary.
Ruby is far, far preferable to shell for ease of idempotence and implicit convergence.
The way in which the author structured the language used to describe things may be the most confusing thing of all. For example:
"HEAD^ and HEAD~ are the same thing (1 commit ago)"
Followed by:
"But I guess they also wanted a way to refer to “3 commits ago”, so HEAD^3 is the third parent of the current commit, and HEAD~3 is the parent’s parent’s parent."
The author's language implies a contradiction they immediately prior said doesn't exist. If these two distinct constructs were indeed different ways to define the same relationship, the second paragraph would say "^3 and ~3 are both ways of saying the third parent of the current commit, or the parent's parent's parent." Instead, they've defined the constructs as different once again.
> If these two distinct constructs were indeed different ways to define the same relationship, the second paragraph would say "^3 and ~3 are both ways of saying the third parent of the current commit, or the parent's parent's parent."
They're not the same thing. Merge commits can have multiple parents, and HEAD^3 refers to the third parent. If HEAD is not a merge commit, then HEAD^3 doesn't refer to anything. HEAD~3, by contrast, refers to following the parent's parent's parent, independent of how many parents any of the commits in question had.
> HEAD~3, by contrast, refers to following the parent's parent's parent,
More specifically, following the first parent only. man git-rev-parse (surprisingly) has a nice explanation:
> A suffix ~<n> to a revision parameter means the commit object that is the <n>th generation ancestor of the named commit object, following only the first parents. I.e. <rev>~3 is equivalent to <rev>^^^ which is equivalent to <rev>^1^1^1.
Is there some large hurdle to having two sets of bdist packages, one set compiled with frame pointer support, and the other without? Like pkg vs. pkg-devel or pkg-src?
pkg-fp, and have the dependency network trigger other installations.
Well, I was being a little flippant dismissing it as largely a complaint about things not showing up in the terminal, but it's obviously deeper than that, yes.
I think this overall situation is most acutely a lack of standard. Someone up in the nosebleed section rightly pointed out that there should be some environment variable for a config to be written to, and I agree. I also want to stress that there should be the inclusion of a single variable on top of that, that all programs should use when constructing the path to their configuration. USER_CONFIG_DIR or something equally arguable should, if unset, default to $HOME, and if set, be used as the root to construct whatever structure therein is desired, also able to be changed with an environment variable specific to that program. Be it filename or further subdirectory, first using a single reference that is /not overloaded/, like HOME, but defaults to HOME if unset.
Well, if nothing else hopefully someone else notices this witness statement exposing the above-linked revisionist history for what it is--a fabrication.
On the topic of Unity: I, a linux user since the mid 90s, worked an actual linux job through the forced deprecation of GNOME 2.. I don't have much anything constructive to say about it. I even used fvwm2 for a while after gnome2 got yoinked.. it was a nice reminder of my halcyon days writing perl in xemacs, running fvwm on my sparc 2. It wasn't too long after that I landed on xfce. I still wonder what gnome2 could've been.
All I ever wanted was a compositing, focus-follows-mouse, raise/lower window manager with a full-featured keyboard shortcut config. I still feel as though we were sold out. I don't think my mental representation of Canonical will ever recover. It just felt so blatantly anti-user during that period, and that impression has not been tempered with the passage of time.
The problem is you're still failing to demonstrate a causal link between threats of legal action and GNOME3 or Unity.
I was around during this time and early adopter of GNOME Shell (i.e. 2.31.x); there was and is zero evidence indicating that legal issues were even a consideration.
There is, on the other hand, mountain ranges of evidence indicating this was driven by everything but legal issues[1][2][3].
Sure, you can't prove something doesn't exist, but you can make a reasonable determination that given exhaustive study, given correlative negative effects can be ascribed to no other known cause, and given that this is natal and pediatric health especially at stake, we should say until such time as a causative link is proven to lie elsewhere these chemicals should not be used in consumer goods out of an abundance of caution.
The redirection of that claim would be "these profits are more important than moving to protect bodily health especially for those unable to protect themselves, given what we currently know."
Honestly, no knowledge is perfect, but upon the balance we must rest our sacrosanct right to health.