No, I'm not mistaken about precision because I never brought it up. It's a strawman solely of your own construction. (I, instead, suggested a much less precise rule, prohibiting all replies/discussion.)
You're implying that the rule here is written like the guidelines, but it isn't.
The guidelines provide some kind of explanation, reasoning, or purpose adjacent to a rule.
The "try explain better, on a case by case basis" doesn't actually succeed, only the same reason, in, perhaps, a different word order.
Surely you don't need that kind of repetition of explanation of purpose for the guidelines, since it's already there to be read. Why such resistance to doing that here, too?
I do disagree with the rule, but I fear you're having a knee-jerk reaction either to me or to any criticism of the rule and thereby missing my point, which I don't believe you've addressed at all:
If you can explain in a short, simple sentence what the broader purpose of the rule is, then do so in the rule itself. Brevity may be the soul of wit but, but I expect a higher standard than rule wittiness from HN. The https://news.ycombinator.com/newsguidelines.html do this fine.
Wouldn't you rather have compliance than enforcement?
The problem here is there's no way to figure out the "spirit" without having followed a rather extensive history - and the fact that the same justifications are repeated every time the rule is questioned in any way is testament to your already realizing that.
Why not just have the rule say what's actually meant, instead? If the desire is "no replies that are or might spark a controversy", then it's clearer for the rule to say that, instead of the vague, terse prohibition on complaints.
Better yet, go all the way and forbid replies entirely. That achieves the same stifling of conversation, in this one context where it's deemed "terrible", without the enforcement that can seem capricious and arbitrary (as you say yourself, "it's often not easy to tell the difference") and can needlessly shame an otherwise well-intentioned commenter.
Keeping it terse and relying on "spirit" is an excuse to maintain that aribtariness.
The problem here is there's no way to know the "spirit" without knowledge of its history.
Why not just say what you mean, instead? If the desire is "no replies that are or might spark a controversy", then why doesn't the rule say that?
Better yet, go all the way and forbid replies entirely. That achieves the same stifling of conversation, in this one context where it's deemed "terrible", without the enforcement that can seem capricious and arbitrary (as you say yourself, "it's often not easy to tell the difference") and can needlessly shame an otherwise well-intentioned commenter.
What about the ongoing cost of waste and eventual cost of decommissioning? Are those affected by quantity of fuel used (or, more specifically, by Transatomic's design)?
Indeed, appending an empty string to -i doesn't modify it in any way, AFAIK.
It's that the GNU version doesn't require an argument, but, if an argument is to be provided, it must be done as part of the flag, not as a separate element of argv. The MacOS version allows either way of providing an argument, so -i.orig tends to be portable (assuming the -i flag is supported in the first place).
Differences in how "traditional" (be they sysv or bsd) versus gnu utilities handle flags and arguments [1] is very well rooted in history, and is hardly unique to sed.
I suspect the main reason this has been forgotten is that Linux, which ships with gnu utilities, has been so dominant for so long, though, even before that, it was difficult to find a then-current unix on which gnu utilities couldn't be installed.
[1] As the sibling comment points out, the source of difference is getopt, of which there were more than just two versions.. including not even using a library
At some point, though, if you're the one complaining about a specific detail, in a way, you're the (only) one.
I've seen plenty of un-portable shell scripting, too, but my professional experience includes a time where, essentially, no software [1] could be assumed to be portable, and I did get some dollars for every time, since it was part of my job to ensure as consistent a build environment as possible.
In light of your clarification, my question becomes: isn't it actually good to have such assumption-breaking differences in that they call attention to something that is likely to have a broader pattern of non-portability, in which case a broadly effective [2] workaround can be applied?
[1] Even/especially GNU tools, where there was something of an assumption that the OS would provide at least fairly complete BSD-compatibility. The existence, and evolution, of libiberty and the autotools, among others, should be instructive.
[2] e.g. installing (all the) GNU tools and putting them first in the path on a system that otherwise uses "traditional" syntax
This strikes me a bit like a "doctor, it hurts when I go like that" problem.
What's the use case [1] for using a zero-length suffix argument (i.e. editing the file "in place" with no backup)?
It's not as if sed is operating on the file actually in place. It uses a temporary file anyway. Varying levels of reliability/portability can be achieved by controlling that temporary file (or subsequent artifacts) oneself, the first level being just to "rm" the backup.
[1] Assuming this is in scripting, since the interactive situation is easily enough adjusted on the fly
This has echos of No True Scotsman. Computer storage media also have ideal conditions that can be used to extend their lifetimes (though, granted, not indefinitely, AFAIK).
What about in real conditions, subject to things like temperature variations (including "extreme" heat that non-operating computer hardware can do just fine in), exposure to light, humidity from the air (to put it back into aqueous solution occasionally), and common oxiders found floating around in the air?
Could one rely on an arbitrary single strand to last even 5 years in an office environment, or are numerous, RAID1-style, copies required to maintain fidelity?
> the outperforming endurance of DNA compared to any modern hardware
This struck me as a strange analogy, considering DNA's inherent fragility, but it would make more sense compared to modern software than hardware.
Alternatively, it also makes sense if "hardware" means a particular model/architecture, with DNA corresponding to an HDL, rather than an instance of hardware (e.g. single CPU, server, or smartphone). A frequent enough topic on HN is the challenge archivists have with archaic software and data formats, even if all the original collections-of-bits are faithfully preserved.
> Vendors have support plans and SLAs so if you need 24/7 support then make sure that is indeed what you're paying for.
Those are totally useless during an existential crisis without associated indemnity (which any vendor would be crazy to provide) against loss due to failur to perform.
> I do not see how having spare engineering talent capable of reading, editing and running a custom database build is the more realistic or faster option for any business in case of issues.
I don't see how it isn't, considering that "custom database build" could be so simple as to be trivial. In the GP's case, it was merely using a specific version.
Even the characterization of the required engineering talent as "spare" seems incongruous, as, in small companies, the talent requird to handle unexpected problems with technlogies fundamenta to running the business is essential, not superfluous.
That hasn't been my experience, at least not on any suitable time scale.
I strongly suspect that the vast majority of those of us who have worked somewhere "not more capitalized and viable" than the vendor share that experience.
Even when a vendor's support engineer is fully capable of solving the problem, the sense of urgency can't reasonably be expected to match that of a much smaller customer facing potentially catastrophic data loss (or other existential-threat-level consequences).
> you seem to be treating bus stops independent of alternative means of transportation
Perhaps you misunderstood my point, which was more about data and statistics, as is the article itself, rather than transportation.
A similar argument could apply to the article's example of "average class size", where that's a valid statistic when observed by a teacher (or facilities manager), but misleading to a potential student. Something like "average size of a freshman's classes" would be more meaningful to a prospective student, and "oversampling" would not be a valid complaint there, either.
> instead of waiting at the bus stop, because of what happened to them yesterday at the bus stop.
It sounds like you're suggesting that there's an even better measure than the two I proposed, rather than the original measure being better. If so, I don't dispute that there could be many more, as I never claimed "best".
In this instance, though, measuring people who never show up to the bus stop in the first place is impossible, and even measuring those who showed up but abandoned waiting (i.e. never boarded) is impossible without additional instruments (whereas, presumably, electronic fare collection equipment could closely enough approximate counting boardings).
I'd argue that it's not oversampling at all, but, rather, that the measure of "average bus arrival time" is what's invalid or misleading.
After all, the point of the bus arrivals isn't in service of the bus (or driver) but of the passengers. Observed average wait time at each bus stop is a better measure. The even better measure would be average wait time weighted by number of passengers [1].
[1] which is tougher to measure empirically, or even model, than just average wait time for that one person, since it requires counting passengers boarding, not just bus arrival times.
Since those words never mentioned contributing back, I was, understandably confused.
> I am saying that contributing back doesn't happen magically because of the GPL.
I don't see where anyone was saying otherwise, ergo you're arguing against a strawman.
> keep the context of the argument in mind rather than keep focusing on being pedantic
That only works for making a (counter-)argument, not attempting to understand the argument(s) in the first place.
In the instant case, I'm now convinced that any disagreement was based on a flawed premise, or there was no disagreement at all. My understanding of hwo the GPL functions (and is intended to function) remains unchanged.
> The event did occur. I saw the source with my own eyes.
You didn't say so, and, even now, you're only implicitly saying there was a GPL violation. The details are important, in order to further understanding.
> The point that you keep on ignoring is that the OP said "companies have to contribute back".
I'm pretty sure I'm not ignoring it, because it didn't happen. That's likely the source of my confusion. You've certainly said so repeatedly, but I'm missing where anyone else in the conversation has said so (hence my thinking it's a strawman).
> One of my points is that they don't even do it though they legally should.
This does sound like you are, again, saying there are circumstances where contributing "back" is legally required, which is the assertion that prompted my own original response. I don't believe those circumstances ever exist. The only obligation is providing (contributing) source code forward. Only when "forward" is the public at large does that end up being, as a side effect, "back".
> The point is that people will abuse goodwill and pretending that it doesn't happen is naive.
I doubt anyone here is actually naive enough to believe it never happens, but there may be a belief that it's rare or exceptional. Without large-sample-size evidence, this can be short-circuited to the usual cynicism vs. "people are basically good" argument.
> Again GPL doesn't magically make people contribute back,
That's my understanding, as well, but that was never asserted, only "play nice", (re-)"release under the GPL", and "gets to live as long as people value it" as you were able to quote upthread.
This seems like contributing forward, not back, or downstream, not upstream.
The eventual effect, for publically-released software, usually ends up being an upstream contribution, but that's not automatic.
I'm not an advocating any particular license, but it does seem like you're responding to a strawman that nobody in this subthread (GPL advocate or not) has argued.
You're implying that the rule here is written like the guidelines, but it isn't.
The guidelines provide some kind of explanation, reasoning, or purpose adjacent to a rule.
The "try explain better, on a case by case basis" doesn't actually succeed, only the same reason, in, perhaps, a different word order.
Surely you don't need that kind of repetition of explanation of purpose for the guidelines, since it's already there to be read. Why such resistance to doing that here, too?