The FSF defines freedom as the four freedoms. Copyleft is about preserving those four freedoms. Copyleft is still free software in terms of the four freedoms. Sure, you could take freedom as being able to do completely anything (or more things than just the four freedoms), but this is like saying the declaration of human rights is bad because it doesn't give you the freedom to enslave others.
So the question comes down to whether or not you think nonfree software is a bad thing. If you don't think nonfree software is bad, then how does it hold that you're saying you care more about user freedom than those who use copyleft?
To me, those who really like and care about freedom to use, study, modify and share software have no problem with copyleft. The people that seem to have a problem with it seem to just want to deny users that freedom. That's really what it is all about. I don't know how on earth you came across this as being like "War is Peace, Freedom is Slavery, Ignorance is Strength", when not having the four freedoms in the case of nonfree software is the real slavery here. And copyleft prevents such nonfree software.
TLDR haiku by RMS:
Using GPL
is encroaching on our right
to encroach on yours
BTW, the LGPL, GPL and AGPL licenses are all "open source" in the sense that they are approved by the OSI, who are the ones who created and defined the term "open source" in the first place. So saying the GPL is not an "open source" license is technically incorrect and confusing.
> What the world needs is an operating system (or systems) or even an application or set of applications that almost everyone would want to use that require programming in some form or fashion to accomplish everyday tasks better.
Tangentially related, but this is why I think Emacs is a great... should I say, 'platform'. Maybe not for young children as in the case you talked about with yours, but a quote from one of RMS's talks about Emacs [1] I think shows what I mean:
> The editor itself was written entirely in Lisp. Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.
Maybe it was the syntax of lisp (by which I mean the use parentheses/'S-expressions' vs. using other 'strange code-like' symbols such as curly braces or semicolons) was a part of why they didn't realise they were actually programming?
Of course, this will not work today because editing/writing text in anything other than a WYSIWYG word processor interface is too unfamiliar to the average general purpose computer user, and therefore Emacs would too easily 'scare' off most users. But your comment reminded me of this and I thought it would be interesting to mention.
I tend to suspect it's partly Lisp syntax but mostly that the entire environment was far enough removed from what people, including the mentioned secretaries, thought of as "programming", that it didn't register with them that that was what they were doing.
You can see the same thing today with stuff like VBA macros in Excel. I've seen some amazingly complex business logic implemented that way by people who absolutely did not think of themselves as programmers, and indeed tended to respond with bafflement to the suggestion that what they'd done could be described as programming.
Having recently started coaching a FLL Robotics Team on programming, I'd say the modern day version of that is something like LabView. Drag and drop programming. I think anyone with half a logical thought in their head could make something that works with LabView or Mindstorms.
That's exactly my point. Using a "request-pull" instead of a "pull-request" will probably mean you can do this git-lfs thing with it. My understanding was that it was not working with "forked" repositories, which you need to have to make a "pull request". To make a "request pull" (or to just send a patch file), you don't need to "fork". ;)
What? Couching is not all scouting... no one's denying that Wenger is always on the look out for young prospects.
But Wenger is a sort of 'old fashioned' coach. He prefers focusing on how his players can do better, rather than trying to focus on the weaknesses of the opponent, which is definitely not 'modern'. This has been slowly changing the past few seasons however.
That being said, I'm definitely no #WOB just in case you think that.
I do agree with your above points, but he has his football (sorry American) philosophy which not most fans understand.
The past decade, he cut his spending to just build a new stadium for Arsenal, budget is tight, so what to do? Bring in the new blood, and the hard data + analytics help!
I'm hoping to see he can also bring in some data-driven approach on his on-field tactics and off-field strategy.
If by football philosophy you mean "the thing about Arsenal is...", skc got it right I think because 15 years ago he was definitely considered 'progressive' or 'modern'. But now I think he's considered "a stubborn old man" because of a "lack of a plan B...". (Of course, past few seasons that "lack of plan B" criticism is not really relevant anymore, but you probably know what I mean.)
About football the sport, I've always seen him as 'progressive' because for example he has always advocated for video replay technology to be used, goal-line technology to be used etc. And so it's definitely possible that he's not afraid of using all the technological help he can for coaching.
It's just that he has rejected using 'technology' to help his coaching in the past. By which I'm referring specifically about him not using video replays of how his opponents play to coach his players with (which has since changed). But I think that is more the case of just not being part of his coaching philosophy, rather than not wanting to use 'technology' or something.
Gotta disagree there. Take the game against Bayern a couple of days ago - he knew that Guardiola prefers to play possession football so he let him do that. Arsenal defended deep in response, hitting Bayern on the counter and reaped a 2-0 result. He certainly exploited the flaws in Bayern's game.
There were no big flaws in Bayern's game that day. Arsenal sat deep specifically to shut down what muller and lewandowski could do, but I wouldn't call that exploiting. In fact Arsenal didn't really 'exploit' or target any aspect of Bayern's game (it's hard to find flaws against "top top class" teams anyway), they were just really well disciplined and played some really good high tempo counter attacks. The lay-low and counter attack was just a good gameplan, not really an 'exploit'.
But Bayern still mostly dominated and played really well. Arsenal's goal was mainly due a horror error by Neuer, he really should have caught or punched that. (Yes it's a set piece so anything can happen, but other than Walcott's header, Sanchez's chance and Giroud's late header from a corner, I don't really remember many more threatening set pieces, so Neuer should have really dealt with that, especially after the Walcott save.)
The only 'flaws' that Bayern had were that they didn't finish. Costa should have scored. Lewandowski should have scored maybe twice even though it was a quiet game for him by his standards. (Sanchez's mistake was what lead to Costa's chance on goal too.)
That last goal by Ozil was really just more of a case of Bellerin being a freak surprisingly right at the end of the match rather than Arsenal specifically exploiting anything. Arsenal was not high pressing (as a team) on that play, it was just a mistake (slow pass) combined with the incredible anticipation and speed from Bellerin (not to mention the desire to bolt into the box rather than jog to the corner flag).
In fact, you could clearly see throughout most of the match that Bayern was the one that kept wanting to target Nacho. Which was pretty weird because if they did their homework, they should have known how massively impressive Nacho has been recently.
> This has been slowly changing the past few seasons however.
And despite all of what I just said, I am acknowledging that Arsene isn't as 'old-fashioned' as he was maybe 5 years ago. Because that comment was more of an observation in general of the post-Highbury era, not literally the past few days when it's obvious that there's more to Arsene's game nowadays.
If you wanted to use a recent example anyway, the game against United would have been a much better example imo (league games is generally when you should be 'exploting' anyway, not in the cl, because you should be expecting anything in cl games, just because of the occasion). You could clearly see that Arsenal specifically targetted United's slow midfield by high pressing on them (Walcott's and Ozil's workrate was impressive). And they were basically one-twoing their way past Bastian "cannot run no more" Schweinsteiger the whole match.
With magit, it's easy to only stage individual 'hunks' so that you can have only the relevant parts of a file staged. And so this problem goes away.
I also imagine it's easy to do this in fugitive as well.
It's probably also possible on the cli, but I imagine that would be too 'hard' or time consuming, hence you will probably start to be lazy about doing it correctly.
>It's probably also possible on the cli, but I imagine that would be too 'hard' or time consuming, hence you will probably start to be lazy about doing it correctly.
I do it all the time, you just use `git add -p` and it steps through hunks letting you stage them or not. As long as you don't make too many changes without committing, it's not particularly tedious.
This was the 'killer app' that compelled me to switch to Git from Subversion back in the day, rather than anything else about Git intrinsically. The ability to organise my commits logically rather than temporally (i.e. not just as a stupid log of change over time) was like night and day.
Sweet! I never bothered to check how to do it on the cli, and instead of being interactive, I just assumed you would have to reference the hunks by line number or something. Naive of me.
"git add -p" can be fun, but it's a little scary because it's super easy to end up making commits that don't actually stand on their own. Super simple to miss an import here or a new field there. If you do a whole series of them, it might actually be worse for others to come back to (or bisect in) if they don't realize the original developer never actually compiled and tested each commit as-is.
Well ideally you could use `git stash -k -u` (-keep index, stash -untracked) to set your working directory to the state you're actually committing, and then run some tests.
For the most part though, I just try to avoid having so many hunks to step through that this is even an issue.
> It's probably also possible on the cli, but I imagine that would be too 'hard' or time consuming, hence you will probably start to be lazy about doing it correctly.
It's extremely easy. git add -p and then you can select to add the hunk or not.
This, in my opinion, is one of the very compelling reasons to use a GUI for these types of operations.
As an example, refactoring something that touches many files often leads to several related/required changes that aren't part of the main refactor. When you first do the change, you're not 100% sure it will stay around, and committing at this point can be a pain later. As a result, you can end up with many files changed and several logical units of work done, and some may be [parts of] a single file, while some may be [parts of] many files. For 5 or 6 hunks, git CLI is usable. Beyond that, for say, a hundred, a UI where you can jump around is basically essential in order to make usable commits.
I know there are still people that snobbily look down on and dismiss GUI tools, but some things lend themselves well to GUI, so I'd suggest giving them a try.
SourceTree in particular works seamlessly with CLI. When I first started with it (being used to git CLI), I jumped back and forth quite a bit with no issue. Now I really only use git CLI for remote branch operations or viewing reflog, and occasionally for a 'git commit -am' if I happen to already be in a shell.
The other thing for me is that git is inherently very very stateful. There's tons of detail to keep in mind as you execute commands - your branch, what's staged or isn't, the state of the remotes, whether you have anything stashed, etc. To me that's a recipe for a tool that should be used through a GUI.
I'm not sure cabal can really be considered a package manager as the article here states [1]. Stack helps, but I think just using a dedicated package manager to manage haskell things is probably the way to go.
Nix has a lot of haskell packages in it already, and guix has a hackage 'import' tool which helps you with writing a new package definition for a project that hasn't already been packaged.
You may think that's overkill, and fair enough. But I've been through cabal hell before, and I'd honestly rather not anymore, ever.
