> Currently, Grsecurity is a commercial product and is distributed only to paying customers. My understanding from several reliable sources is that customers are verbally or otherwise warned that if they redistribute the Grsecurity patch, as would be their right under the GPL, that they will be assessed a penalty: they will no longer be allowed to be customers, and will not be granted access to any further versions of Grsecurity. GPL version 2 section 6 explicitly prohibits the addition of terms such as this redistribution prohibition.
This is a fundamental misunderstanding of the GPL. The GPL merely requires corresponding source to be made available alongside binaries, so if you get a binary from someone you have a right to the corresponding source from that person. It does not require anyone to offer you a binary; it merely says if they did, you can get the corresponding source.
GRSecurity has no obligation to provide you a binary, they can decline to offer you one because you have a silly walk or a 13-character username or you exercised your rights under the GPL. The GPL does not entitle you to product updates or to continue to be a customer of someone who doesn't want you as a customer, it merely entitles you to corresponding source for binaries.
Some would say GRSecurity's practice violates the spirit of the GPL, but the GPL is not a spiritual entity, it's a legal document, and if you want a legal document that produces a different outcome you can write one up.
Also, you should read the fine print from any other Linux vendor – RHEL, Oracle, etc. You don't have to go on "my understanding from several reliable sources", the documents actually state they'll terminate you as a customer if you redistribute their stuff.
"Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License."
The question of law is if threatening recipients who exercise their rights qualifies as a restriction on them exercising their rights. Thinking that it does is not a fundamental misunderstanding of the text.
> The question of law is if threatening recipients who exercise their rights qualifies as a restriction on them exercising their rights. Thinking that it does is not a fundamental misunderstanding of the text.
It is a fundamental misunderstanding of the law, and it is not (an open) question of law.
In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fire you for exercising it. Whether that threat is a restriction on your rights is perhaps a question in philosophy or ethics, but from a legal point of view it's very clear: your employer is not restricting your speech, they are restricting their own hiring policy.
So it is here. Legally speaking, you are not restricted from redistributing the software. You may be restricted from GRSecurity wanting to do business with you afterwards but you don't have a right to be someone's customer under the GPL, you only have the right to corresponding binaries.
"In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fire you for exercising it."
This is a trolling technique known as derailing. It seems to have worked a little since most of the replies are about "free speech", which isn't what this conversation is about.
You are talking nonsense. The "right to free speech" in the United States has developed over hundreds of years of jurisprudence. It is impossible to summarize here but for starters involves not only Congress but also states (Gitlow v NY) and even private parties (Snyder v. Phelps). I don't mean to suggest it is arbitrarily broad but it is certainly much broader than to say it is "only" the text of the first amendment.
Secondly, "intimidation" carries a very specific legal meaning, for example here's the Montana statute [0]:
(1) A person commits the offense of intimidation when, with the purpose to cause another to perform or to omit the performance of any act, the person communicates to another, under circumstances that reasonably tend to produce a fear that it will be carried out, a threat to perform without lawful authority any of the following acts:
(a) inflict physical harm on the person threatened or any other person;
(b) subject any person to physical confinement or restraint; or
(c) commit any felony.
Unless GRSecurity is threatening to break your legs, kidnap you, or rob your store, they are not intimidating you.
What we are talking about is refusing to do business with you, which is very legal. There are some exceptions, such as if the basis for that refusal is due to your race/sex, or if GRSecurity is a cartel, or if they are refusing in order to obstruct an investigation into some other illegal activity, but I'm not aware of those kinds of facts here.
In the US, your only "right" to free speech is protection from the government restricting your speech. Indeed, if your employer is the government, then there are significant (but not absolute) limitations on how much they can retaliate for your speech.
If that case were decided the other way, it would mean that government had a law that restricting their right to free speech. You will notice that they did not have the right to speak at the funeral, because the private entity running the funeral is not obligated to give them freedom of speech.
It is true that there are exceptions to the "congress shall make no laws ..." part of the first amendment; so by analogy, there might be some exceptions to the GPL's "no further restrictions" clause, but you have not explained why grsecurity falls into any of those hypothetical exceptions.
> In the US for example, you have the right to free speech. But except in very unusual circumstances, your employer can fire you for exercising it.
Are you sure about this? Are you an attorney? I am not.
I ask because it was my impression that, more than each individual having a right to free speech, each individual has a right to be free from a certain set of governmental restrictions or punishments for their speech, and that this is also true of the non-governmental-employer-employee relationship, but the set is smaller.
For instance, it was my impression that:
(A) People who are not governmental employees have the right to be free from the government restricting them from criticizing Congress in most locations at most times (and have the right to be free from the government punishing them for this criticism)
(B) Governmental employees have fewer rights that (A) in certain respects related to their employment
(C) People who are non-governmental employees can generally be fired for their speech, though not for certain speech, like stating that she is pregnant or whistleblowing to the federal government (under some circumstances)
Free speech applies to to public (government) entities. You can prevent someone from exercising their rights if they are within your private property. In public spaces this isn't the case, as it's public, but an employer doesn't have to allow any freedoms to their employees (minus human rights violations, which are explicitly stated in law).
So a company could say you aren't allowed to say a single word during work hours while working for them. They would also not have employees.
"Also, you should read the fine print from any other Linux vendor – RHEL, Oracle, etc. You don't have to go on "my understanding from several reliable sources", the documents actually state they'll terminate you as a customer if you redistribute their stuff."
I don't know about Oracle, but I know about Red Hat. They not only do not prohibit one from distributing source code and the patches they apply to it, they distribute it freely themselves, and help maintain a free distribution of RHEL called CentOS built from the same sources they use for RHEL.
There is no reasonable way to compare Red Hat's policies about source distribution and availability to grsecurity.
The same goes for SUSE as well. Not only that, but the openSUSE community created an entirely new distribution based on the SLE sources (openSUSE Leap).
> Red Hat. They not only do not prohibit one from distributing source code and the patches they apply to it
Of course they prohibit it. e.g. from [1]
> This EULA does not permit you to distribute the Programs or their components using Red Hat's trademarks, regardless of whether the copy has been modified. You may make a commercial redistribution of the Programs only if (a) permitted under a separate written agreement with Red Hat authorizing such commercial redistribution, or (b) you remove and replace all occurrences of Red Hat trademarks.
from [2]
> Distributing the Software and Services (or any portion) to a third party outside the Portal or using the Software and/or Services to support a third party without paying for each Instance is a material breach of this Agreement even though the open source license applicable to individual software packages may give you the right to distribute those packages
from [3]
> Any unauthorized use of the Subscription Services is a material breach of the Agreement, such as... (d) using Subscription Services in connection with any redistribution of Software
Your first quote covers trademarks. That is unrelated to source code. CentOS ships with a different set of trademarks. If you want to rebuild and redistribute the RH sources, you remove the trademarks. That's well understood and well within the terms of the GPL.
Second refers to binary builds of the software. Also well within the terms of the GPL.
Third refers to the Subscription Service which includes access to binary builds, access to a customer portal with knowledge base, private support tickets, etc.
None of these refer to distribution of source, which is explicitly permitted by Red Hat.
> Your first quote covers trademarks. That is unrelated to source code.
Source code contains trademarks, that is why CentOS has to remove them. If you distribute the source code you get from the RHEL subscription area you have violated your RHEL agreement.
You are not in violation of the GPL, but that is precisely my point: everybody does this, and nobody (except OP) believes it is a GPL violation.
I'm not interested in re-litigating the trademark discussion here. It's not relevant to the grsecurity conversation, and it's been settled for a decade or so. Trademark law is separate from copyright law and really has no place in a copyright discussion.
Red Hat places branding in their own packages, generally, which is easily replaced by distributions...they do their own re-branding in Fedora and CentOS; the trademarks are built to be removable. Red Hat went out of their way to make it easier to build a from-source RHEL without violating trademarks, despite not really having a legal obligation to do so.
My assertion had nothing to do with whether they made it easy or hard to remove their trademarks.
My assertion was that Red Hat customers make agreements with Red Hat in which they agree not to redistribute RHEL. That is directly analogous to the GRSecurity case, except there we are relying on something OP heard thirdhand and in the case of RH we can read the agreements.
"My assertion was that Red Hat customers make agreements with Red Hat in which they agree not to redistribute RHEL. That is directly analogous to the GRSecurity case, except there we are relying on something OP heard thirdhand and in the case of RH we can read the agreements."
Then your assertion is a lie. I feel like I'm talking to a wall.
Red Hat very clearly does not prohibit distribution of the source of their kernel, or any other GPL component of RHEL, and in fact they make it available for free in the form of CentOS, and they do not prohibit others from distributing it either. Everything you've quoted above says nothing about what you keep saying it means.
You don't understand the issue then (and your assertion is patently false as I outlined elsewhere).
First of all, requiring trademark removal is something the FSF considers acceptable so long as it is reasonable to do[1]. Both RHEL and SUSE have all of their branding in specifically labeled packages so it is easy to replace.
Second of all, GRSecurity will always penalise you if you distribute their sources (regardless of whether you remove any trademarks they may have in their source -- which I don't think they do).
The two issues are completely different and you're muddying the waters by bringing up Red Hat, even though the free software community has agreed that removal of trademarks is acceptable[1]. You're bringing up a non-issue in a discussion about an actual issue.
> Also, you should read the fine print from any other Linux vendor – RHEL, Oracle, etc. You don't have to go on "my understanding from several reliable sources", the documents actually state they'll terminate you as a customer if you redistribute their stuff.
While that may be true for Oracle (I doubt it), it's absolutely not true for Red Hat and SUSE. Not only are most of our projects developed in the open under free software licenses in the first place, we provide corresponding source for every package (regardless of the license terms, as long as it's a free software package) through our package manager as source RPMs.
The only restrictions that companies such as Red Hat and SUSE have is related to trademarks and distribution of the binaries that we compiled.
* Trademarks are a completely separate set of laws to copyright, and it has been long accepted in the free software community that as long as it is reasonably easy to remove trademark branding then this is acceptable (in Red Hat's and SUSE's cases, all branding is placed in separate and clearly marked packages -- so you can remove it by replacing those packages)[1].
* As for distribution of binaries, this policy exists for practical reasons and doesn't affect the community (the sources are available and we also provide an entire build service [Open Build Service[2]] that you can use directly to rebuild all of our sources and ISO images if you wished to).
openSUSE Leap is a community distribution created from the SLE sources. CentOS is similarly a distribution built from the RHEL sources.
[ I work for SUSE, and am also an FSF member -- I find spreading of misinformation like this incredibly harmful to the wider community. I would not work for SUSE if I felt that our actions were mistreating users. Opinions my own, obviously. ]
The word binary appears nowhere in this article. And indeed, the quote you quoted is saying something entirely different from what you're refuting. It is correctly claiming that the GPLv2 license prohibits one from adding additional restrictions to the redistribution of the source code. That means GRsec can't tell you not to redistribute their GPLv2 licensed code, as it's a clear violation of the kernel license.
But that's not what they're saying. If you read their statements on the subject you'll see that they explicitly permit redistribution under the rules of the GPL.
What they will do is terminate your contract and you will not receive further updates.
There GPL does not mandate that you receive updates to anything. All it says is is that no restrictions can be applied on the source code that you have received.
Let's back up for a moment just to make sure we're talking about the same "they." "They" being the author of this article, absolutely said almost verbatim what I claimed they said.
My post: "It is correctly claiming that the GPLv2 license prohibits one from adding additional restrictions to the redistribution of the source code"
The article: "This is tantamount to the addition of a term to the GPL prohibiting distribution or creating a penalty for distribution. GPL section 6 specifically prohibits any addition of terms."
>If you read their statements on the subject you'll see that they explicitly permit redistribution under the rules of the GPL.
Now it seems you're talking about GRsec and not the author of the article, but I definitely didn't claim GRsec said anything, I only made assertions about what the article said.
Then, going a step further, what you're arguing is yet another separate issue entirely, which is more relevant but still different than anything in this thread: Your claim is that their contract's rules of punishing someone for redistribution is not covered by GPL section 6. This may well be true, but I would personally guess not.
"You may not impose any further restrictions on the recipients' exercise of the rights granted herein" seems pretty clear cut to me. It implies that you can't impose any further restrictions. You can't even write a contract regarding the terms of redistributing GPLv2 software. And indeed, as far as I can tell, there's absolutely no precedence for being able to do that. If you could do that, then anyone could defeat the GPL by making a contract with sufficient punishment for redistribution.
Seems pretty clear. They cannot stop you from redistributing the binary of v1, and anyone you redistribute the binary to can demand the source if it's not already included. They can say that if they find out you redistributed v1, they're not going to give you v2 in the future, but if you get v2 some other way you can still ask for the source (and whoever distributed that one might not get v3 etc.). There may be further restrictions from trademarks to make redistribution perfectly legal (like CentOS just removing mentions of RHEL) but it can quickly become a lost battle for upstream.
This is a common misconception. It is "traditional" macroeconomics (e.g. Keynes) did not engage with microeconomics at any point [1].
It was not until the 1970s and the Lucasian rationalist critique that microfoundations became an important inquiry. And that shift didn't occur because people were sentimentally attached to micro (if anything, they were attached to prevailing macro theories), it happened because Lucasian rationalism explained an empirical phenomenon (a shift in the Phillips curve) that was not explained by the other approaches. Since that time support for microfoundations has waxed and waned a few times, in response to several other empirical shifts.
In practice, economics is much like the other sciences, with a slightly wider diversity of thought. Like the other sciences, most people only understand a caricature of it that is given through the lens of politics. Unlike the other sciences, more people seem inclined to accept this caricature and criticize it on that basis, which is unfortunate.
The problem is that the notion that 'microfoundations' can be linked to the macro economy by searching for 'deep parameters' suffers from precisely the same critique.
It's even proved wrong within the body of theory that embraces it. The Sonnenschein-Mantel-Debreu theorem.
Economists then do a lot of hand waving and point to 'data', without acknowledging that the 'data' is collected from a system that has been under the influence of their ideas for over 40 years and therefore will, inevitably, be the right shape.
If you collect data from a man in a straitjacket, unsurprisingly it will look like a man in straitjacket. It can tell you nothing about ideas that involve removing the straitjacket.
Non-falsifiability of theorems is the hallmark of macroeconomics. Because it is an ideology dressed up as a science.
Believe it or not, this compiler option is named `-disable-objc-interop`.
> Could someone explain why I should build a language developed entirely by and for writing Apple ecosystem products?
Possibly because you have an affinity for value types, performance, or safety. A language is a lot more than just a checkbox of platforms it supports, although iOS is a pretty large checkbox right now.
> the long list of benefits suddenly looks much, much smaller compared to e.g. JVM, .NET, Go, etc etc.
Swift isn't trying to compete with any of those. I mean sure in the "world domination 10 year plan" sense, but for the forseeable future the bullets that make Java attractive to enterprises (lots of developers, lots of libraries, lots of platforms) are not on anyone's todo list in the Swift community.
Rather, the short-term goal is to compete with C/C++/Rust. So you are writing a web server (e.g. nginx alternative, not a webapp) or a TLS stack or an h264 decoder and buffer overflows on the internet sounds scary, you are doing pro audio plugins where 10ms playback buffer is the difference between "works" and "the audio pops", you need to write an array out to network in a single pass to place your buy order before the trader across the street from you, but still have a reasonably productive way to iterate your trading algorithm because Trump is elected, etc.
As far as JVM/.NET, a cardinal rule of software is that it bloats over time. So JVM/.NET/Go can never "scale down" to the kinds of things C/C++ developers do, but it is less known whether a low-level language can "bloat up" to do what .NET developers do. In fact, C++ kinda does "bloat up", because C++ .NET exists. But that is basically an accident, because C++ was not designed in the 80s with .NET developers in mind, and perhaps for that reason it is not the most popular .NET. To the extent we have a plan, the plan with Swift is to try that "on purpose this time" and see if it works better when we're designing it to do that rather than grabbing a round peg off the shelf and hammering it into our square hole. It probably won't ever be as good at .NET problems as .NET, but perhaps it can get close, for useful values of close.
> you can never just "forget about it for the first draft" the way you can a VM's GC.
Similarly, ARC does not exist to compete with your VM on ease-of-use, it competes with malloc/free on ease of use (and your VM on performance). If your VM is performant enough (or you can afford the hardware to make it so), great, but that just isn't the case for many programming domains, and that's the issue we're addressing.
There is also a quasi-non-performance aspect to ARC that is often overlooked: deterministic deallocation. Most VM memory models are unbounded in that resources never have to be deallocated, but in a system like ARC we have fairly tight guarantees on when deallocation will take place. So if your objects have handles to finite resources in some way (think like open file handles, sockets, something to clean up when they blow away) the natural Swift solution will be much more conservative with the resource use relative to the natural JVM solution. Because of that it may be more useful to think of ARC as a general-purpose resource minimization scheme (where memory is merely one kind of resource) rather than as a memory model or GC alternative itself.
> There is also a quasi-non-performance aspect to ARC that is often overlooked: deterministic deallocation.
Assuming there are no pauses due to deletion of deeply nested data structures, or worse, stack overflows.
Herb Sutter has a very interesting presentation at CppCon 2016 about these issues, where he then presents a kind of C++ library based GC to work around them.
Also ARC has performance impact, because increment/decrements need to be synchronized due to threaded code.
The problem with "the freedom to exclude" is that the same argument underpins, for just one example: racial segregation. If the blacks want to go to the movies, well then they can have their own movie theater. We can't abridge the proprietor's "freedom to exclude" people from his own business.
Except we can, and we did, and society was better for it. So as it turns out, the "right to exclude" is more of a guideline than a rule, riddled with dozens of exceptions. And "the current regime has existed for a long time" is not very predictive of long-term societal shifts.
So it is here. You are right that there is fundamental tension between the right of free speech and the right of exclusion.
But one of those is a right so fundamental that it appears first when you ask people to list freedoms. The other is something we regularly cede in large and small ways when we live with other humans in a society. Where the two oppose, there is only one way the arc of history can go.
Our grandchildren will be just as puzzled by the "right to exclude" argument as we are when it is made by the generations before us.
>If the blacks want to go to the movies, well then they can have their own movie theater. We can't abridge the proprietor's "freedom to exclude" people from his own business.
I'm sorry, but this doesn't disprove the OP's assertion. Doing business with someone is not the same as speech, and business in general is far more regulated than private life ever was.
As a counterpoint, (in the US) there's still nothing preventing people from excluding minorities from their homes and friendships, and even private organizations are allowed to discriminate by race or sex, and do. (Golf clubs are infamous for this.) Businesses that are "open to the public" are not allowed to; that's the compromise we made, and it's worked out well IMO. If you're a black person, it'd be really awful if you desperately needed a medication, and the one pharmacy in town refused to sell it to you. But being excluded from someone's home or golf club isn't really hurting you.
Similarly, if you run a business, there's many other regulations you must follow: collecting sales tax, using commercially zoned property if you have too many customers, various regulations on how you can treat employees, etc. And part of this is not being allowed to discriminate based on race or sex, unless you have a really really good reason for it (like you're filming a movie about JFK for instance; a black woman isn't going to get far complaining that you didn't audition her for the part). You don't have so many restrictions on your private property.
You misunderstand my argument, and OP's. I'm asserting something like "our children will be protected from firings when they express an unpopular opinion." This would be a regulation that applies to business, so the arguments you construct around business being a regulated sphere are actually arguments in favor of why this will happen. It is also a point that directly disproves OP's assertion that "the first amendment only applies to the government", because here it would be applied to the average employer.
As far as I know, at-will employees can absolutely be let go for expressing an unpopular opinion. It is only illegal to exclude a quite short list of "protected classes", mostly (entirely?) defined by immutable traits like race. To be clear, I don't think this "freedom to exclude" should be protected constitutionally the way freedom of speech is, and I'm a big supporter of all the exceptions to it that I know of, but I still think it's a worthwhile concept that should be considered when discussing freedom of speech as it pertains to private entities.
You're right, I seem to have misread that comment. Too bad I can't downvote myself :)
FWIW, I don't necessarily disagree with that hope/belief, but I have some questions about how such a thing would work in practice. Clearly, some private organizations (like churches and political parties) rely on the ability to discriminate based on belief. But perhaps there's a clue there for how such a regulation could be drawn - those are not for-profit enterprises.
> Moreover, you won't find any reputable study on the web where the average person lost 10%+ of their body weight and kept it off for five years. Not even one.
Was going to link to the National Weight Control Registry, thanks! I'll just add that all those studies in GP seem to prove is that A) weight loss programs (especially fad diets) don't work and B) it is a psychological issue. There are plenty of people on MFP, /r/loseit or just counting calories themselves that have successfully kept off weight for years. I'm one of them.
Many times I'll read a story of someone who lost weight and kept it off. And then they detail their pre weight-loss diet and I think, well of course you were overweight. You were inactive and had a terrible diet (sugary drinks, processed foods, etc). You started getting some exercise and learned a few things about nutrition and the weight fell off.
But then there are others who seem to do everything right and are over weight in spite of that.
For example. I was never overweight as a kid and relatively active. In college and for the start of my career, I stopped being active and my diet was awful (e.g. I thought a large Jamba Juice smoothie and a carrot cake was a healthy breakfast choice). My weight ballooned up to almost 190 lbs (20+ lbs overweight), my blood pressure went up, I started having rosacea.
I started running and fixed my diet. Quickly my weight dropped down to 150 and I've kept it in the 140-150 range for over a decade. The other health issues cleared up as well. But it wasn't hard work for me. Being thin is my natural state if you will, and I had to do everything wrong to stay overweight.
My wife meanwhile continues to struggle with her weight. She's successfully lost weight through extremely diligent calorie counting, but after a year or so she starts to put it back on. I have never counted calories. Our diets are similar (in kind, not quantity of course, she eats much less than me). She is active, but not quite as active as me. So similar diet and life styles, but my weight stays off and hers does not.
Hereditarily, no one in my family is over weight. There is obesity on both sides of her heredity.
And I see this playing out in our kids. My son has an athletic build and will probably never have weight issues. My daughter takes after her mom and it will take a life time of diligence for her to remain at a healthy weight.
It seems that some people are optimized for famine, and some for feast. :-(
Obviously there are a lot of factors involved in the growing obesity crises. But I feel for people who struggle with their weight despite doing all the right things, I really do.
The food tastes too damn good! I've only been overweight because of binging and poor eating. I've never eaten in a normal, healthy way, and gained weight.
Calories are such that if you screw up once per week (birthday party, company event, family dinner) that could mean you gain weight if you eat regularly the rest of the days.
> "It seems that some people are optimized for famine, and some for feast. :-("
You're actually onto something there! I don't know if you've read much about epigenetics, but if a person experiences a famine, it can "switch on" prepare for famine genes in their descendants. It's fascinating stuff.
> Our diets are similar (in kind, not quantity of course, she eats much less than me).
Maybe. I've heard this sort of story before, and I don't tend to believe it. It's hard enough to estimate how much you are eating yourself, and comparing against others is even more error-prone.
I'm facing a similar situation, but I'm loathe to start counting calories just to confirm my hypothesis. Being forgetful and apathetic about meals almost certainly contributes to why I've maintained a healthy weight. I worry that the rigor required for proper observation will change my behaviour.
Kelly Brownell, director of the Rudd Center for Food Policy and Obesity at Yale University, says that while the 10,000 people tracked in the registry are a useful resource, they also represent a tiny percentage of the tens of millions of people who have tried unsuccessfully to lose weight. “All it means is that there are rare individuals who do manage to keep it off,” Brownell says. “You find these people are incredibly vigilant about maintaining their weight. Years later they are paying attention to every calorie, spending an hour a day on exercise. They never don’t think about their weight.”
That just described reddit subs focused on weight loss.
> they also represent a tiny percentage of the tens of millions of people who have tried unsuccessfully to lose weight.
They also represent an unknown number of people who do keep off weight successfully, but never report in, for whatever reason. As just one example, I asked for an application and when it came I realized I did not qualify for the registry as I don't have a before photo.
> “You find these people are incredibly vigilant about maintaining their weight. Years later they are paying attention to every calorie, spending an hour a day on exercise. They never don’t think about their weight.”
Anti-dieters love to trot this out, but they have no evidence to back it up. There are plenty of people who log in MFP, check to see if what they are contemplating ordering fits their budget for the day, then go about the rest of their lives. It takes all of a couple of minutes. There are other people who just more carefully mind what they eat, listen to their body, have changed habits (eg, cutting out soda) and never even track calories. I'm one of them.
As for spending an hour a day on exercise, that's not unreasonable. Most people spend multiple times that amount of time on things like TV or web browsing. It's also not mandatory for weight loss.
Rather than just positing the question, share with us why you think it shouldn't have been downvoted. And explore reasons—even if you don't agree with them or think they're groundless—why someone might downvote it. Of course there are those out there who downvote for reasons we think are frivolous: they're not likely to respond to your comment anyway.
The guidelines ask us not to comment on being downvoted: I think in general this should extend to commenting on other's downvotes as well: it makes for boring reading. You mention this yourself—it's a broken record. If you are going to do so, put some effort in to make the comment worthwhile. It's also a good exercise in improving discourse, if that's something you're interested in.
I kind of agree with you but doing that would turn a a genuine question into a high school hand-in complete with a discussion of the results.
I will likely consider your opinion next time I'm tempted to point out that someone is downvoted for seemingly no good reason and with no explanation.
But I am not sure of the outcome - I would like others to defend me when I am accused or picked on for no good reason. Basically I'm doing to others what I hope they would do for me.
But I am not sure of the outcome - I would like others to defend me when I am accused or picked on for no good reason.
Right, and by providing a explanation than just posing the question, you're doing a better job of doing exactly that—showing why you think it shouldn't have been downvoted—while also contributing to the conversation. In my experience, the people who are responding to such questions are not the people who have downvoted—they're doing some version of what I've outlined above. If you have no idea why something might be downvoted, it likely would be good for you to stretch a bit and imagine how someone else might read or take the comment you're referring to. It'll likely make you a better comment writer and reader.
Thanks for following with a citation, but I am well aware of that research. The national weight control registry is a heavily self selected group of people who have already lost significant weight before joining - therefore weeding out most of the failure rate. And even then, only 20% of their audience lost over 10% of their initial body weight and kept it off for one year.
> you won't find any reputable study on the web where the average person lost 10%+ of their body weight and kept it off for five years. Not even one.
To refute this, it's sufficient to present a counterexample. Since many studies exist, and they are reputable, the only argument is whether the people in them are average.
You say they are not, because they lost weight. But that cannot be your whole argument, because if we assume average people don't lose weight we assume the premise you have taken up to prove.
So again: other than the fact that these people lost weight, what exactly is exceptional about them?
Hang on, has a counterexample been presented? Maybe we're reading the challenge differently, but I parsed "reputable study on the web where the average person lost 10%+ of their body weight and kept it off for five years" as meaning a study in which a bunch of already-overweight people were selected to try some specific intervention (eg, "follow this diet & exercise program") and as a result of the intervention the median outcome was to lose that much weight and keep it off for 5 years.
A study of only people who succeeded, selected for the study because they succeeded, tells you nothing about how effective their particular strategy is.
For instance, suppose there exists a Grapefuit Diet which has the following effect: 1% of the people who try it lose weight, 2% of the people who try it gain weight, and 97% of the people who try it see no effect. If you take 100 people, tell them to try that diet, that is the result you'll get - a result which tells you the strategy is no good. But if you look at the national weight loss registry you'll only find people who were in the tiny 1% for which that diet worked. In fact, even if there are a LOT of Grapefruit Diet successes in the registry, that just tells you how popular the Grapefruit Diet was, it doesn't tell you if the Grapefruit Diet works.
What we want is an intervention study where a bunch of fat people do some specific thing and that thing is actually effective at producing a clinically significant and stable amount of weight loss. Ideally we'd want them to lose enough weight such that they are no longer "overweight" and then maintain that state.
Does that study exist? Is there any study meeting that set of criteria? My impression is that it does not; there is in fact no non-surgical intervention known to "work". Which explains why people keep grasping at straws to find options that plausibly might work.
Swift 4 (unreleased) has source compatibility with Swift 3 [0], so all Swift code working today should work in the next version, no migrator necessary.
Additionally, the goal of Swift 4 is to finalize the ABI. Once that is done, you can mix and match different Swift versions in the same project.
The real "problem" here is that Swift wants to be a "big" language, in the vein of C++ or Rust, as opposed to a "small" language like C or JS where you can read one book. (Swift does have a book, it's 1200 pages.) There's a lot of "stuff": a complex typesystem, many basetypes, generics, extensions, both static and dynamic dispatch, programmer-assisted memory management, closures, visibility, ephemerals, optionals, a mutability-based memory model, etc. etc.
Inevitably some of that stuff won't be quite right and so you have churn. But ideally you only need 10% of those (it's just that everybody needs a different 10%) and so the amount of churn you personally have to deal with should be low, and can be lower with the appropriate tooling.
It is an ePub, so your mileage may vary. On my iPad, it is 1077 in landscape, 892 in portrait (edit: playing with the font size in iBooks, I got it down to 484 pages while still being eminently readable for my myopic eyes)
More importantly, that ePub on my iPad shows only 16-ish on a page in landscape mode, 22-ish on portrait. A printed book probably would be around 300-400 pages.
In comparison, the PDF I have for "small" language ISO C 2011 has 701 pages, a draft of ECMA-262 for JavaScript 252.
My guess is that it is not ideological. Swift feels like it wants to be 'everything'.
Because of this, it's almost too much.
I want to like Swift, but I run into a lot of trouble with it.
The decision to be compatible with ObjC was one of the big issues: obviously, pragmatically, they felt that they just had to do it. In hindsight, I wonder if it would have been better to just have a clean break.
> In hindsight, I wonder if it would have been better to just have a clean break.
Language-wise - sure, it adds a lot of complexity. Platform-wise, they would risk people staying on what they had and ignoring Swift entirely, and that would mean Apple would need to support objective-c a lot longer than they want to.
But I wonder. They are a $700B company. What if they just 'did it right' - i.e. made sure all of the APIs and documentation were available in 'new Swift' which had no relation to ObjC.
Because the 'fallback on ObjC' has more problems than integration.
A lot of people want to make apps for iPhone and ObjC is not in their vocab. Me, for example.
Swift could have been an easy-to-approach language.
But because of 1) lack of docs and 2) dependency on a lot of ObjC residue ... guess what? To make app in 'Swift' - you still had better know a lot of ObjC!
So - to really make use of 'the new' - you still have to know 'the old' - which totally defeats the purpose!
I wish they had made a clean break - great docs, examples that are clear and well marked in terms of versions, all new APIs for Swift, left in beta for longer, and made mostly backwards compatible changes. And left a few things out.
But many of their customers aren't. Lot of them have no budget (or will) for complete rewrite. And if you force them (or just make them believe you may do it) they will complain and it means bad press, in a very competitive market. It may not be something Apple can afford.
> What if they just 'did it right'
You can't "did it right" without support of large amount of users, regardless of the money. The definition of "right" in programming languages is "works for users". And to get users onboard, you have make sacrifices.
> A lot of people want to make apps for iPhone and ObjC is not in their vocab.
And even more has existing apps to maintain. Tradeoffs have to be made.
> great docs, examples that are clear and well marked in terms of versions, all new APIs for Swift, left in beta for longer, and made mostly backwards compatible changes
All those things will come. If you want them, wait for them. Being early adopter has its cons.
"Lot of them have no budget (or will) for complete rewrite. "
I don't mean they should force people onto Swift. I mean that Swift, should be totally independent of ObjC, so that customers, if they choose to use it are not dependent on it.
Also - Apple could feasibly provide a 'lib/bridge' - just as Android can use C++ code as well, if you want to use it.
I think Apple could surely commit to keeping ObjC around for quite some time - maybe 4 years official support, and then maybe 8 years on the devices, but with no more documentation/support.
"All those things will come. If you want them, wait for them."
I don't agree - this is 'doing it wrong'. It's been out for years. This is way past 'early adoption'.
'Doing it right' means that it is easy for new and old developers. Right now - it's hard.
Doing Swift 'right':
1) Make Swift a clean break, get rid of some of the more obscure things that make it difficult. Get rid of relationship to ObjC.
2) Detailed docs, tons of examples. Examples for every single class, every single attribute. 100% of functionality should be 'explainable by example'.
3) Beta for 1 year, then production.
4) No backwards-incompatible changes after out of beta. (Easier said than done).
5) Docs, examples etc that clearly demarcate versioning.
6) Tons of support on Stack Exchange: dedicated staff to simply monitoring, answering, clarifying issues just on Stack Exchange.
7) 'Free Support and Training' for anyone who wants it and who can make it to a major city, i.e. NYC Jan 1-5 or 'weekend course' for anyone who registers. Free. Once every few months. At least 100 Engineers just doing training, and going into dev/studios companies to help them with stuff.
8) Free online courses, for newbs, and those coming from other languages, and Objc.
They made Swift a little too complicated, and left devs hanging in the dark on so many issues.
> I don't mean they should force people onto Swift. I mean that Swift, should be totally independent of ObjC
If you will not provide seamless integration, you will seriously limit amount of people who migrate. There are other problems here too: what should library authors do? Write two versions?
> It's been out for years. This is way past 'early adoption'.
Looking at all programming languages I've ever used, getting out of this childhood period always took years. Sure, Apple could do better job perhaps in many aspects, but it really takes a very long time to get a language and stdlib to usable shape.
>Make Swift a clean break, get rid of some of the more obscure things that make it difficult.
If you make a clean break, you limit amount of your users. Without users, you can't tell what obscure things are difficult for those who didn't opt in.
I agree with all those beta periods, stability guarantees, docs and training. I am now appreciating more how well those things work in Rust.
"If you will not provide seamless integration, you will seriously limit amount of people who migrate. "
I don't agree at all.
Tons of people are 'starting out' on Swift - moreover - if Swift were done a little better - it would actually be used on other platforms, etc. - as opposed to an 'iPhone only' type thing.
New projects start all the time.
Major re-factors and re-writes happen all the time.
Second - I do not believe that the premise of: "well I can switch some of my code to Swift, but keep most of my libs on ObjC" - is reasonable. This is a minority case.
And of course - as I said - they could have provided access to ObjC libraries through an interface exactly as Android does.
You want to use 'legacy C++ code' on Android? You can do it. It's just not so clean, but you can do it. The same should have been provided for Swift-ObjC
So - companies who don't want to migrate - can stick to ObjC for a few more years.
The rest can switch over.
"If you make a clean break, you limit amount of your users."
Again I don't agree at all. Node.js has more developers than Swift. With Apple backing it (i.e. 'making it good' - but also making it 'the basis for iPhone) - they could have had an incredible number of users.
There's no reason that Swift couldn't have been used in internal-alpha for a while, then external beta for a while - then then have a 'solid v1'.
AS you say - many languages were 'around for a long time' - but they have also been stable for a long time!
Java for example, did not do anything at the .lang level that was not backwards compatible. The only non-backwards compatible bit was java AWT, which they replaced with Swing. But even AWT is still supported!
So, there's no excuse for rapid rollout of versions that are incompatible with one another, no excuses for huge gaps in documentation etc..
Considering that was going to be hard requirement, maybe the problem was introducing so many things that are so incompatible with ObjC? There are tons of ways you could vastly improve the programming experience without introducing all this incompatible stuff.
If your an objective-c programmer, a lot of swift concepts are very close to each other. Most of the time you just pick it up as you go along. In many ways it's a cleaned up objective-c.
I think this is really the core of the issue. For someone to "adopt" my software but not contribute in any way (whether that be patches, documentation, support, financial, repetitional, etc.) it's not an especially desirable outcome. I suppose there is something to be said for merely living generously (and I do license quite a bit of code that way) but as a society we have unfortunately not yet solved how to sustainably develop software projects without the sticks and carrots in the general case.
It is fair to look at whether e.g. AGPL limits adoption, but I think it is equally fair to ask if it makes sense that a software developer in a broom cupboard is donating his time to AWS, or whether AGPL allows software to be written that might otherwise not exist, or might not exist in the open.
But here's the deal: for someone like AWS who isn't giving back, the choice is not "do they give back or don't they?" -- it's "do they run your software or someone else's?" So: do you want to grow the ecosystem around your software or not? Do you want AWS to at least create a market for people who understand your software? Do you want at least the intrinsic satisfaction that your software is being used in an important capacity, even if it doesn't mean immediate remuneration? Finally, if AWS runs your software and it becomes core to their business, there is a non-zero probability that they will contribute something tangible in the limit -- if they do not run it, there is, in fact, zero probability of such contributions. It's not dissimilar to the arguments around open sourcing otherwise proprietary software[1]: you need to get out of "what will this buy me?" and into "what does this cost me?"
> there is a non-zero probability that they will contribute something tangible in the limit
I wouldn't hold my breath for that, frankly. My experience in working for a few large companies has shown that they actively discourage contributions, since it opens the doors for lawsuits (frivolous or not), further contribution and maintenance expectations. To them, the cost is not worth the benefits.
There are, of course, the exceptions to this rule - but that's all they are, exceptions.
For one great example, look at the plight of OpenSSL. Before it broke way open, how many companies really contributed to it? And how many just used it, not giving a second thought to using it unless there was a CVE?
>For one great example, look at the plight of OpenSSL. Before it broke way open, how many companies really contributed to it? And how many just used it, not giving a second thought to using it unless there was a CVE?
So you think there were a large number of companies privately fixing bugs in OpenSSL? Or how would a less permissive license forced companies to contribute to a project they weren't actively improving?
And on your earlier points, keeping changes private likely requires more future contribution and maintenance expectations
> But here's the deal: for someone like AWS who isn't giving back, the choice is not "do they give back or don't they?" -- it's "do they run your software or someone else's?"
That assumes 1) the other software exists (GPL/AGPL has much more effect for software without viable competitors), 2) the license causes more of a problem than switching does, 3) you don't sell an alternative license that costs less than switching does.
> So: do you want to grow the ecosystem around your software or not?
In short: of course not. Or at least "not at any cost".
Open source projects do loads of things that reduce the potential ecosystem. People choose to work on projects that aren't web browsers, for example. Or they choose languages that aren't the #1 most popular. They target a platform that has less than 50% marketshare. All of those things turn away potential users in exchange for authorial convenience of some form or another.
It is a foreign concept to me to write e.g. a developer tool for a minority environment and then all of a sudden worry about the license being some major barrier.
But more broadly your position is very strange to me in its wider implications. Let us say that some voice actor could donate some spare reel to Disney. Or that some author could donate a manuscript to Penguin. Or that some musician could donate their track to Sony. Do you believe they should do so, under the theory that this in some way "grows the ecosystem" for their work?
How much is that "market for people who understand your software" worth? Sometimes those people are your competitors, using your own code plus local improvements (or "improvements") to sell against you. It's not as simple as saying you'll always win or you'll always lose. There are both opportunities and risks, which have to be weighed on a case by case basis. I've seen my own code sold against me too many times to believe permissive licensing is always the right answer.
Most people do pay dumb amounts of money for content. They pay their carrier for the bandwidth to download the ads. That's in the ballpark of a nickel per page [0].
You can't say that micropayments doesn't work when ads ARE micropayments. They're just micropayments with a particular set of properties.
The only question remaining is which of those properties are necessary. Is it actually necessary that your nickel causes an ad to be displayed, or is it just easier and the way we've organized things so far?
And yet, when I turn on ad-block for a month, my cable internet bill does not go down.
So, no, it is by no means a micropayment. And even if I were charged for overage, and I were over my monthly limit, I wouldn't be charged at a rate of $1 for 20 MB.
The term is based on a figurative bug being found. OED traces this usage to
> Mr. Edison, I was informed, had been up the two previous nights discovering ‘a bug’ in his phonograph—an expression for solving a difficulty, and implying that some imaginary insect has secreted itself inside and is causing all the trouble. - The Pall Mall gazette, 1899
which seems to be reporting a bit of jargon in use at Menlo Park at that time that would be completely unfamiliar to the reader.
At some point the jargon spread more widely in engineering culture, this usage from The Journal of the Royal Aeronautical Society 1935 assumes some familiarity with the term, and attributes it to a whole country instead of a lab:
> Casting, forging and riveting are processes hundreds of years old, and, to use an Americanism, ‘have the bugs ironed out of them’.
In this context, the "First case of an actual bug being found" would be the first time that a problem was traced to a literal bug, instead of a figurative one. This would have been engineering humor, as if Google Cloud Platform went down due to a thunderstorm.
As the term "bug" became more closely tied to computer culture, we started thinking of its origins in strictly computer terms (and so you pose the question about the invention of the "computer bug"). The moth story is certainly an early usage in computing, and was a major inflection point for the computing usage, so as origin stories go it is a reasonable answer to the question.
It's just that the label of the computer bug does not reflect the real development of the term. Bugs were part of the engineering jargon long before computers, so the extension of this vocabulary to yet another engineering field would not have been notable at the time.
This is a fundamental misunderstanding of the GPL. The GPL merely requires corresponding source to be made available alongside binaries, so if you get a binary from someone you have a right to the corresponding source from that person. It does not require anyone to offer you a binary; it merely says if they did, you can get the corresponding source.
GRSecurity has no obligation to provide you a binary, they can decline to offer you one because you have a silly walk or a 13-character username or you exercised your rights under the GPL. The GPL does not entitle you to product updates or to continue to be a customer of someone who doesn't want you as a customer, it merely entitles you to corresponding source for binaries.
Some would say GRSecurity's practice violates the spirit of the GPL, but the GPL is not a spiritual entity, it's a legal document, and if you want a legal document that produces a different outcome you can write one up.
Also, you should read the fine print from any other Linux vendor – RHEL, Oracle, etc. You don't have to go on "my understanding from several reliable sources", the documents actually state they'll terminate you as a customer if you redistribute their stuff.