mmt

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?

If you're going to prevent me from responding and having my response visible, then go ahead and just delete my original comment.

I have, of course, personally read all these justifications for the rule before, but they do nothing to address my question.

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.

How is this posting to complain?

It's a question about a potential existential threat in the form of recent regulatory scrutiny.

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

the right sterile environment

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.

they would solve it for you

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).

California has about 8.5% of the US population.

I think you misread the line for California in your footnoted reference #1, which shows it at 12.14%.

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.

the original posters words

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.

'Secret' purely internal use of modified GPL software is not a violation - if the modified software is never distributed publicly, there's no issue.

As the parent pointed out, purely-internal isn't what he meant. Distribution can be non-public, which is distribution nonetheless. Such distribution would require availability of source, but that availability wouldn't be public, if the original distribution wasn't public.

The parent seems to be focusing on "theft" (GPL violation) by relatively-unknown companies, which didn't necessarily occur. It's plausible that it did, but, even if the violation were corrected, since that correction doesn't require public release of source code, is likely irrelevant to the overall discussion.

You seem to be focusing only on publically-released software, which may or may not be the majority (by whatever measure).

I have no "side" in this, just trying to understand the points, which I've failed to grasp. Are you talk past each other?

Maybe I didn't make it very clear. Each time I observed it the company I was contracting for was selling it to a 3rd party

Indeed, that wasn't at all clear. The comment to which I was responding only used the word "company" (singular and plural), without any modifiers, which I read as describing the same party.

That clears up some of my confusion, since that's an obvious violation (assuming source code wasn't available to those same 3rd parties, which you also didn't explicitly state).

The OP specifically said that one of the benefits of the GPL is people had to contribute back because they have to make the code public.

Such an assertion (which I see in neither ancestor comments nor the article) still seems mistaken, so perhaps it's a strawman?

The GPL, IIUC, is meant to protect the user, aka downstream, not provide benefits to "upstream". If the binary itself isn't made public, then the source code need not be, either (though I suppose the user/customer in your scenario would have the freedom to choose to make it public, they have no obligation and little, if any, incentive).

I'm a bit confused, since, initially, you mentioned dehumidifying.

However, I'm getting the impression that the heat pump in this case is entirely internal to the machine, which is not what I had in mind when mentioning heat pumps (thinking of their coefficient of performance of 3-4) [1]. Were I aware of these machines, I would have specified:

It's not as if modern dryers are using a heat pump with an outdoor source to raise the temperature of the clothing instead of burning gas or "burning" electricity with resistive heating.

That said, a 2x efficiency gain, by whatever method, is more than I expected, though still falling into what I would categorize as "not much room", especially if the gain comparison always assumes the oldest, least-efficient 5kW model only ever running at its highest setting. The other key assumption in all these comparisons is that all these dryers can finish the same sized load in the same amount of time, which can't possibly be true in the real world.

If my $40-to-repair machine already has some efficiency tweaks such that its worst-case is only 4kW, the $500 machine's worst-case is 2.5kW, but my actual behavior averages out to running them at 70% power, I'm saving barely over a kilowatt per hour, and I'm back up to 3500 hours to break-even at $.12/kWh electric rates. $1800-for-1kW is nearly 14k hours, or nearly 18 hours a week over fifteen years, and I don't do that much laundry.

[1] If this is so, it strikes me as odd to call it that, just as it would strike me as odd to call out a free-standing dehumidifier having a "heat pump", even though that's the crucial to the device functioning.

I don't understand what compilation has to do with anything, if the company (user) in question isn't distributing the software outside the company.

How is it any different from an individual making changes to GPL software and using it (compiler or interpretted) on a personal computer? Surely that individual isn't obligated to share anything, either.

The real point to take away is that any modifications will never reach upstream.

The GPL doesn't mention, AFAIK, any such concept. I thought the point was freedom for users of software, not implied benefit to some "upstream" programmer.

IOW, since the GPL is about the user, it's about protecting "downstream" and, without redistribution, there's none to protect.

Electricity is far more expensive than gas.

That's usually only if the gas is natural gas, and that's not available. Even then, "far more" can be misleading.

My experience in California is that it's on the order of 4x cheaper than using resistive heating in a residence (i.e. buying naively from the utility at retail rates).

My latest PG&E bill shows "procurement" costs (which I assume are the wholesale energy-only part of the bill [1]) of $.009-$.01/kWh [2], and, IIUC, wholesale electricity is about 4x that.

This is to say that an efficient enough electric heat pump (which I believe is plausible for whole-house heating, not high-temperature use cases like a dryer) could at least get close to gas in operating cost.

[1] only about 1/7th of the retail total, something which would likely surprise most consumers. This seems true for electricity, too, where, IIRC, the energy costs $.04/kWh, but PG&E charges upward of $.24/kWh at the highest residential "tier".

[2] converted from $/therm using 29.300111111111 kWh/therm

Their energy consumption is about half that of a condensation drier.

Again, this is not necessarily a fair comparison, if what's being pumped actually costs something that can't be measured at the dryer's plug.

$500 would likely be worth it, even at $.12/kWh, but the market may not think so if they're not available for that price in places with cheap electricity (and/or cheap enough natural gas, which can be much cheaper, ranging between $.04/kWh and $.06/kWh, equivalent, on my last bill).

the heat pump is used to dehumidify the processing air.

This seems a bit strange to me, but it makes sense, especially if there's recirculation going on.

The air is still heated using electricity. It just doesn't waste as much heat.

This is pretty clear from the efficiency only being 2:1, which is much worse than what I'd expect from a heat pump being used for heating.

there is an almost 10 year old Miele dryer in my apartment, with a heat pump.

I stand corrected. I'd be curious if it's actually any more efficient, especially if the heat it's pumping comes from gas, oil, or resistive heating (in the winter, assuming cold climate). It can appear more efficient, of course, if one only measures the dryer itself, but that wouldn't be apples-to-apples.

Here's their top of the line current offering in the USA

$1800 is an eye-watering price. That'd buy me 3750 hours of 4kW [1] dryer usage, so buying it for long-term savings alone is hardly an obvious choice.

clever uses of natural gas

Raising temperature by burning it seems like the least clever use of natural gas (or any combustible).

[1] I figure the least efficient resistive heating dryer is 5kW and that Miele is 1kW.

I think you (and the OC) will find that, with dryers, there's really not much room to gain efficiency. It's not as if modern dryers are using a heat pump instead of burning gas [1] or "burning" electricity with resistive heating.

[1] and natural gas tends to be cheaper than electric heat pumps, especially nowadays

software that is only deployed on one or two servers on a company intranet and the general public will never see it.

I thought that, in this case, it's the company itself who is the "user" of the software and isn't obligated to do anything to/for/about upstream (since there is no stream.. they're not re-distributing it). In that sense, they're not stealing anything, just using what was, explicitly, free to use.

Not quite. I believe the point is that it's not an edge case, since "master" isn't a particularly unusual name, not in the Unix tradition, nor, AFAIK, on any other OS.

You'll note that, for example, your "rm" didn't require a double-hyphen.

The OC's point (and maybe the GP's point [1]), ultimately, is about git command syntax ambiguity. With traditional Unix commands, there's not much ambiguity. At worst, there's merely no obvious way to pass an argument that's a filename starting with a hyphen. The question "what does 'ls -l' do?" would not plausibly have an answer of "output '-l' if a directory entry with that name exists" in addition to "output a long listing of all directory entries".

[1] Does git actually behave differently based on the existence of a directory entry named "master" or does it merely require extra effort to work with such an entry, which would actually be directly analagous to filenames beginning with a hyphen?