Slashdot Mirror

Now that persuasion has failed, I suppose he could fork it.

Or, choose a new maintainer. It might be a misread to assume the maintainer meant that RMS is irrelevant. When I read the thread, it seems to me to be more of a throwing-down-the-gauntlet, a my-way-or-fire-me type of statement.

It is worth reading the response from RMS, too:
http://lists.gnu.org/archive/h...
He talks about how the whole GNU Project has to do what is best for the GNU Project, not each package doing what is best for that package. He invokes the responsibility of each package maintainer to do so, and he closes with: "If GNU packages do not support each other, it will be easier for many of them to fail."

His detractors will call him irrelevant whatever he does, but history has examples like XEmacs to show what happens when there is disagreement with the FSF over the GNU packages. Even when the users like the rejected features, the GNU versions have remained more popular than the forks, and ways of moving forwards with features that are in demand have always been found.

And as an emacs user, this is not a threat to the GNU package at all. Almost nobody would use a fork over this, because most emacs users already have to manage a .emacs config that includes non-standard bits. It would just be another third party package to include there.

Actually, you can dynamically link against GPLv2 or older code and be just fine. Likewise, making system calls to a GPL (even GPLv3) application or library (e.g. without linking) removes the requirement that you share any of your code.

Want to use a GPL library in your application? Write a wrapper. Done. It's called abstraction and it's so common I'm amazed any developer hasn't heard of it. Sure, you might have to release the source for that wrapper, but you can most certainly use any GPL code you want in your application, you just have to know how to do it properly.

And before you point to this as an example of how I'm wrong, understand that this is still in reference to linking; there really is nothing stopping you from using an unlinked GPL wrapper in your non-GPL project, provided that you offer the GPL source you are using and, depending on how the wrapper is linked and which version of the GPL is used by the code it links with, possibly the source of the wrapper, as well.

Excellent point, open and free but only in the way he sees freedom... We are talking about the man who is insisting to call Linux, GNU/Linux and likes to flame people for speaking up their minds, with different world visions...

So he tries to persuade people to agree with him, perhaps passionately, perhaps vehemently, maybe even not so nicely ... but (to my knowledge) he has never used force or fraud to coerce people into behaving the way he thinks they should. That sounds perfectly freedom-loving to me. I'm really not seeing the problem here.

If your opinion of the guy is correct, then his methods will cause fewer people to listen to him and he will thereby undermine his own efforts. This means such a situation would be self-correcting. I've never heard of RMS using force or threat of force to make you call it "GNU/Linux". The degree of power he has over you is determined entirely by how much you decide to listen to him*. The ability to recognize this is generally called perspective.

It's as though some people have an entitlement mentality, a manner in which they are self-centered. It leads to them feeling like they've been wronged or mistreated somehow when they discover that someone doesn't agree with them, won't support or otherwise validate them (probably the part that really bothers you), and speaks against them.

* I started to add "and use his software", but then I realized that's not true - you could use Emacs with the LLVM debugger ... or not, whether anyone else likes it or not, because the GPL and LLDB's NCSA license are compatible. RMS deliberately chose a license allowing this to happen. Did you fail to recognize the significance of that? That freedom means people might do things with which he disagrees does not remove his right to disagree. Are you suggesting it should? If not, what exactly are you trying to say, if you are not in fact expressing another entitlement mentality?

I am so disappointed in the open source community. It's like they don't care about the very foundation this community was built on.

The open source movement was started to never raise a user's software freedom as an issue. Read the FSF's essays (older essay, newer essay) on how open source differs from free software and you'll get a very clear explanation of how open source's goal to speak to business means accepting proprietary software and whatever other anti-user stuff businesses want to implement with proprietary software (DRM, spyware, back doors, patent traps, etc.). Mozilla's partnering with Adobe, the Linux kernel accepting and distributing proprietary software as part of the project (code which GNU Linux-libre removes), and Mono developers celebrating Microsoft's releasing .NET software under the MIT X11 license without acknowledging the danger of Microsoft's patent promise are just a few examples of how the philosophical differences between the older ethically-minded free software movement and the younger developmental methodology-focused open source movement play out on the ground.

I am so disappointed in the open source community. It's like they don't care about the very foundation this community was built on.

The open source movement was started to never raise a user's software freedom as an issue. Read the FSF's essays (older essay, newer essay) on how open source differs from free software and you'll get a very clear explanation of how open source's goal to speak to business means accepting proprietary software and whatever other anti-user stuff businesses want to implement with proprietary software (DRM, spyware, back doors, patent traps, etc.). Mozilla's partnering with Adobe, the Linux kernel accepting and distributing proprietary software as part of the project (code which GNU Linux-libre removes), and Mono developers celebrating Microsoft's releasing .NET software under the MIT X11 license without acknowledging the danger of Microsoft's patent promise are just a few examples of how the philosophical differences between the older ethically-minded free software movement and the younger developmental methodology-focused open source movement play out on the ground.

I am so disappointed in the open source community. It's like they don't care about the very foundation this community was built on.

The open source movement was started to never raise a user's software freedom as an issue. Read the FSF's essays (older essay, newer essay) on how open source differs from free software and you'll get a very clear explanation of how open source's goal to speak to business means accepting proprietary software and whatever other anti-user stuff businesses want to implement with proprietary software (DRM, spyware, back doors, patent traps, etc.). Mozilla's partnering with Adobe, the Linux kernel accepting and distributing proprietary software as part of the project (code which GNU Linux-libre removes), and Mono developers celebrating Microsoft's releasing .NET software under the MIT X11 license without acknowledging the danger of Microsoft's patent promise are just a few examples of how the philosophical differences between the older ethically-minded free software movement and the younger developmental methodology-focused open source movement play out on the ground.

Because [the MIT license is] not "Stallman Approved."

The license of X11 is "Stallman approved" in the sense that it's a GPL-compatible free software license. But FSF's favorite non-copyleft license is the Apache license version 2.0, which has stronger patent guarantees in jurisdictions with software patents.

Surveillance does not make people less free.

Violating your privacy infringes upon your freedoms, so yes, it does. The United States constitution's fourth amendment mentions that you are secure in your papers among other things. The papers themselves? No, what is really protected is the information on the papers.

If repressive things happen with the gathered data then that would be a problem but not the surveillance itself.

You can't separate the two, you insufferable moron. One inevitably leads to the other, as history shows. Information is power, and mass surveillance is a means of crushing democracy and destroying people who challenge the status quo. They tried to do that with MLK, they tried it with nearly every anti-war movement, they try it with nearly every movement that challenges the status quo, and now with mass surveillance, they'll be that much more efficient at crushing those who challenge authority.

There are numerous sources to support that. Two that probably hold some weight are:
http://www.gnu.org/manual/blur... and http://www.gnu.org/software/so..., both of which list R as a GNU package.

There are numerous sources to support that. Two that probably hold some weight are:
http://www.gnu.org/manual/blur... and http://www.gnu.org/software/so..., both of which list R as a GNU package.

We don't know if that's him. It might be just some random guy piecing shit together from the Linux and the GNU System page.

I am not a number

So I guess you are sqrt(-1)???

What was wrong with standard Linux distributions such as Debian / Ubuntu / whatever?

The FSF explains that here

Requiring fees based on the deployment platform used does not constitute "free" software under any open source definition I have ever read.

So you have not read any, and have no idea what you are talking about. Start with the open source definition (opensource.org) and the Free Software Foundation (gnu.org).
https://www.gnu.org/philosophy...
http://opensource.org/faq#free...

You are making, unintentionally, an excellent point that one should refer to gratis software and libre software.
https://en.wikipedia.org/wiki/...
GCompris is always libre software, but sometimes not gratis. That is OK with both the FSF/GNU and OSI.

Requiring fees based on the deployment platform used does not constitute "free" software under any open source definition I have ever read.

The software is licensed under the GNU GPL 3, and is thus certainly free software. It follows all four freedoms in the free software definition. It is also open source, under the offical Open Source Definition. In fact, being able to sell the software is integral to it being free software. From the GNU licence FAQ:

Does the GPL allow me to sell copies of the program for money?

Yes, the GPL allows everyone to do this. The right to sell copies is part of the definition of free software. Except in one special situation, there is no limit on what price you can charge. (The one exception is the required written offer to provide source code that must accompany binary-only release.)

And, of course, the source for GCompris Qt is available, at both a KDE Git repository and a GitHub mirror. You’re welcome to compile it yourself, and play it for free, on either a Linux system or an Android system (or any other system you wish to port it to).

Requiring fees based on the deployment platform used does not constitute "free" software under any open source definition I have ever read.

The software is licensed under the GNU GPL 3, and is thus certainly free software. It follows all four freedoms in the free software definition. It is also open source, under the offical Open Source Definition. In fact, being able to sell the software is integral to it being free software. From the GNU licence FAQ:

Does the GPL allow me to sell copies of the program for money?

Yes, the GPL allows everyone to do this. The right to sell copies is part of the definition of free software. Except in one special situation, there is no limit on what price you can charge. (The one exception is the required written offer to provide source code that must accompany binary-only release.)

And, of course, the source for GCompris Qt is available, at both a KDE Git repository and a GitHub mirror. You’re welcome to compile it yourself, and play it for free, on either a Linux system or an Android system (or any other system you wish to port it to).

Some people are on a crusade against using the word "steal" to refer to copyright infringement, patent infringement, or trademark infringement. Larceny, copyright infringement, patent infringement, and trademark infringement are defined in separate areas of law, and they aren't even crimes under the same circumstances. A judge agreed that the term "theft" misleads jurors.

Reminds me of that short story, The Right to Read. ...or, 1984... or when 1984 was remotely removed from Amazon Kindles.

For now you have the tools to write software for the machines you purchase. This may not remain a reality if devkit fees increase and more marketplace owners also publish their own apps.

I had tended to assume that these days most of the libc math functions were implemented in hardware

Why assume or speculate? Download the source code and check it yourself. :)

From GNU glibc download page:
git clone git://sourceware.org/git/glibc.git

Separating content consumption vs content creation (tablet vs laptops) was a break through.

A breakthrough for the incumbent media publishers, that is. Even thinking in terms of "content" and "consumption" benefits the incumbent media publishers over public participation. Say someone buys an iPad instead of a general-purpose computer because he plans to view works of authorship that others have created and thinks he isn't likely to start creating new works. But two weeks later he ends up getting the itch to create new works. Now the iPad is a sunk cost, and he has to go in debt again to spend hundreds on a PC.

Off topic but thanks to open pipes in between different minded individuals. 15 years of linux in an international biz and I had never heard of units.

$ rpm -qi units (edited)
Name : units
URL : http://www.gnu.org/software/un...
Summary : A utility for converting amounts from one unit to another

I do live in the SF bay area and it feels likes most of the rain gets immediately back to the sea. Clearly we have not reached 97 rainfalls yet, when the water went over the levies in the Sac delta IIRC. In a pile of subjective opinions, it is nice to find a rose.

The C++ object model was basically that a simple inheritance model. Classes were union structures that had a self pointer. Methods were just offsets against that pointer in assembly. Inheritance was effectively a code copy. How can you be more simple that that?

In terms of a JIT... https://gcc.gnu.org/wiki/JIT

About those C++ templates, you said, "unless you stick to a very restrictive subset of C++ that's almost C, then you'll end up generating too much code (C++ templates are not just a good way of blowing away your i-cache on high-end systems, they're also a good way of blowing away your total code storage on embedded chips)."

I used to use the -fno-implicit-templates parameter on g++: https://gcc.gnu.org/onlinedocs... when I was doing C++ heavily. I also usually didn't have more than two templated types, mostly to keep the debugging simpler. Do you still have any quantification for the overhead with C++ code generation versus C's as you used it? Did you try options like this? And how heavily templated was the code?

"The inherit risk is that the organization is accountable and accepts the risks if a major bug is encountered within any of the open source applications they are using".

In order to use the software, the end user must accept the license, which in no-way-shape-or-form makes the organization accountable for any such defects.

Limitation of Liability.

"In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who modifies and/or conveys the program as permitted above, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use the program (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the program to operate with any other programs), even if such holder or other party has been advised of the possibility of such damages."

I was alluding to the fact that Android is based on GNU/Linux, and Linux has permissions built into the core. Fair point though.

Aside: apparently there's not much GNU code in Android. Interesting.

Which is pathetic for the CC, honestly. Python's doable because it's *free* just like Java was then- and worse, you didn't need VS to do C++...

Dev C++
With MinGW or Cygwin, Eclipse

Sure, it didn't have some of the glitzy stuff MS was shovelling- but you could have pretty much done Windows or Cross-Platform C++ development back when Java was the big rage at the Community Colleges. And this doesn't even get into them doing Linux for all of it, including Java, Python, etc... They're guilty of some of the same mentality that spawned the notion that these idiot "bootcamps" are a good substitute for a discipline or vocational education. The problem isn't quite the thing Mike Rowe's fingering on this- but he's close enough to not disagree at all. They're guilty of trying to strip-mine all the students for all the money they can. Actually teach something? That's too much into our "BoM" on those grads we're pumping out.

Part of the reason you had problems getting a gig was that they saw the "cookie-cutter" Associate's degree and passed on that. You've nothing to offer except coding for them at that stage, regardless of whether that's true or not- because that's the only metric they've got to go off of. If you actually have ability and can pick up the Engineer's trade, you should get the rest of the BS degree you should get (which won't assure you the job...little will, honestly, unless you've got 2-3 decades of the bleeding edge, self-taught through the school of hard knocks...but it'll HELP, all the same...) and work on teaching yourself any gaps in anything they didn't teach you on your own. There's always something that they won't/don't teach you. You have to learn it on your own. Whether it's C++, OOD/OOA, or the like, you're going to have to be able to grab the ring yourself repeatedly to keep employed. The reason they passed on you is the AS degree- because of the "pathetic" I opined on at the beginning. They're not teaching a trade. They're honestly not teaching a good base to work with at most Community Colleges these days. They're teaching you the in-vogue stuff right then (You shouldn't be learning VS, you should be learning C++ which doesn't really and honestly give a tinker's damn where it's being implemented if you've done it right... You shouldn't be learning Java just because the College is too cheap to get proper Windows tools (which, again, is PATHETIC because the tools have been "there" within reach for nearly 20 years...). You shouldn't be learning Python because that's the big main big-deal in dynamic content websites in there with Java and PHP... You get the idea...) In all honesty, it wouldn't endear you to me if I were to hire help with either my Game Porting interest or my Agritech one. In the former, I'd need a self-starter that understands C and C++. They'd need to be adaptable to pick up Lua if they didn't already know it. They'd have to be able to debug code on X86, ARM, and MIPS. The requirements for the Agritech business I'm starting...are similar in nature, along with "getting" embedded coding. That's the kinds of jobs there's currently work for that's sustainable. An Associate's isn't going to help you there unless you can show you putz with that stuff already and can prove you might grow to fill those shoes in a 6-18 month timeframe being allowed to do it. The same goes for a "bootcamp".

Mono developer Miguel de Icaza has pledged to continue to add Microsoft's code to Mono saying "Like we did in the past with .NET code that Microsoft open sourced, and like we did with Roslyn, we are going to be integrating this code into Mono and Xamarin's products".

But is that wise? To your point, the Free Software Foundation's reaction to Microsoft's similar 2009 action point to exactly how changing ownership of patents render Microsoft's Patent Promise not to sue useless. This very promise could become the basis for a patent trap. In 2009 Microsoft's promise not to sue was called a "Community Promise" but today's .NET promise not to sue is risky in the same way—it's not (as the FSF rightly puts it) "an irrevocable patent license for all of its patents that Mono actually exercises" and neither is the MIT license Microsoft chose to release their code under.

Looking back at that essay from 2009, we see the FSF warn us (emphasis mine):

The Community Promise does not give you any rights to exercise the patented claims. It only says that Microsoft will not sue you over claims in patents that it owns or controls. If Microsoft sells one of those patents, there's nothing stopping the buyer from suing everyone who uses the software.

Falling into this trap will directly adversely affect your ability to run, share, and modify covered software. The FSF points to a practical way out as well:

The Solution: A Comprehensive Patent License

If Microsoft genuinely wants to reassure free software users that it does not intend to sue them for using Mono, it should grant the public an irrevocable patent license for all of its patents that Mono actually exercises. That would neatly avoid all of the existing problems with the Community Promise: it's broad enough in scope that we don't have to figure out what's covered by the specification or strictly necessary to implement it. And it would still be in force even if Microsoft sold the patents.

This isn't an unreasonable request, either. GPLv3 requires distributors to provide a similar license when they convey modified versions of covered software, and plenty of companies large and small have had no problem doing that. Certainly one with Microsoft's resources should be able to manage this, too. If they're unsure how to go about it, they should get in touch with us; we'd be happy to work with them to make sure it's satisfactory.

Until that happens, free software developers still should not write software that depends on Mono. C# implementations can still be attacked by Microsoft's patents: the Community Promise is designed to give the company several outs if it wants them. We don't want to see developers' hard work lost to the community if we lose the ability to use Mono, and until we eliminate software patents altogether, using another language is the best way to prevent that from happening.

I find it no accident that the built-to-be-business-friendly "open source" language is all over this announcement including the aforementioned blog post from a prominent endorser, while the wise warnings of falling into a patent trap come from the FSF who consistently looks out for all computer user's software freedoms—software freedom being the very thing that "open source" was designed never to bring to mind (see source 1, source 2 for the history and rationale on this point).

Mono developer Miguel de Icaza has pledged to continue to add Microsoft's code to Mono saying "Like we did in the past with .NET code that Microsoft open sourced, and like we did with Roslyn, we are going to be integrating this code into Mono and Xamarin's products".

But is that wise? To your point, the Free Software Foundation's reaction to Microsoft's similar 2009 action point to exactly how changing ownership of patents render Microsoft's Patent Promise not to sue useless. This very promise could become the basis for a patent trap. In 2009 Microsoft's promise not to sue was called a "Community Promise" but today's .NET promise not to sue is risky in the same way—it's not (as the FSF rightly puts it) "an irrevocable patent license for all of its patents that Mono actually exercises" and neither is the MIT license Microsoft chose to release their code under.

Looking back at that essay from 2009, we see the FSF warn us (emphasis mine):

The Community Promise does not give you any rights to exercise the patented claims. It only says that Microsoft will not sue you over claims in patents that it owns or controls. If Microsoft sells one of those patents, there's nothing stopping the buyer from suing everyone who uses the software.

Falling into this trap will directly adversely affect your ability to run, share, and modify covered software. The FSF points to a practical way out as well:

The Solution: A Comprehensive Patent License

If Microsoft genuinely wants to reassure free software users that it does not intend to sue them for using Mono, it should grant the public an irrevocable patent license for all of its patents that Mono actually exercises. That would neatly avoid all of the existing problems with the Community Promise: it's broad enough in scope that we don't have to figure out what's covered by the specification or strictly necessary to implement it. And it would still be in force even if Microsoft sold the patents.

This isn't an unreasonable request, either. GPLv3 requires distributors to provide a similar license when they convey modified versions of covered software, and plenty of companies large and small have had no problem doing that. Certainly one with Microsoft's resources should be able to manage this, too. If they're unsure how to go about it, they should get in touch with us; we'd be happy to work with them to make sure it's satisfactory.

Until that happens, free software developers still should not write software that depends on Mono. C# implementations can still be attacked by Microsoft's patents: the Community Promise is designed to give the company several outs if it wants them. We don't want to see developers' hard work lost to the community if we lose the ability to use Mono, and until we eliminate software patents altogether, using another language is the best way to prevent that from happening.

I find it no accident that the built-to-be-business-friendly "open source" language is all over this announcement including the aforementioned blog post from a prominent endorser, while the wise warnings of falling into a patent trap come from the FSF who consistently looks out for all computer user's software freedoms—software freedom being the very thing that "open source" was designed never to bring to mind (see source 1, source 2 for the history and rationale on this point).

RMS predicted this in The Right to Read.

Correlation does not prove causation, but interesting paper none-the-less reading the summary: "Copyright and Creativity -- Evidence from Italian Operas"
http://papers.ssrn.com/sol3/pa...

But even if it was true, should most of humanity be denied access to most of human knowledge via the internet that could otherwise be available right now (like via Google Books) so we might get a few more operas and other such thing?

Beside, current research (even by the US Federal Reserve) shows reward is not motivator for creative works (or sometimes even has a negative correlation of causing artists to just rehash more of the same old thing). Lot of studies are cited in these works by Alfie Kohn and Dan Pink to support my point:
"Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes"
http://www.alfiekohn.org/books...
"RSA Animate - Drive: The surprising truth about what motivates us"
http://www.youtube.com/watch?v...

Also: "Studies Find Reward Often No Motivator: Creativity and intrinsic interest diminish if task is done for gain"
https://www.gnu.org/philosophy...

A better answer to the issue of people having enough time to do quality work (including learning to do it) is to have a "basic income" for everyone (so, for example, monthly Social Security payments in the USA from birth, not just for those 65 and older).
http://www.basicincome.org/bie...

There are plenty of reasons copyrights stifle creativity these days, because artists can't easily remix.
https://gigaom.com/2011/12/12/...

Most, as in 99%+ (my guess), of artistic people are only held back by copyright, because very, very few people can make a living at licensing creative works as authors or composers or whatever, but they instead generally have to pay for access to contemporary novels and music and such. Some of that is discussed here:
http://www.thepublicdomain.org...

For the purists. debian do 99.9% the right thing but give the user the discretion to add 'nonfree' at their whim.

For example, I downloaded the mini installer iso to attempt to install debian on my machine.

It couldn't connect to the network to complete the install! Culprit - My usb wifi dongle, which worked fine under Ubuntu. Acquiescing to load a firmware and I was up and running.

My otherwise 'pure' system is thus tainted but this wifi dongle has served me 5+ years already, so the pragmatist favours working hardware. :)

http://www.gnu.org/distros/com...

The latest version of GNU's Hello World is v2.9. The source download is 707k as a compressed tarball. The actual C source file is about 6k and is internationalized. Most of the remainder of the space is taken by build, test, and documentation. The configure script is over 400k.

Emacs also allows you to add local configuration variable inside each file to customize its behavior.So if you do not want to change tab-width globally, just add the following to each C/C++ file indented using a tab-width of 4:

/* Local Variables: */ /* tab-width: 4 */ /* End: */

This works for almost all major modes using their respective comments

PS: Slashdot insists for removing newline from the code above. More exemples are in https://www.gnu.org/software/e...

Yes, with "M-x doctor" and "M-x hanoi". They've been there for longer than I can remember (which is to say, a lot). More details in the relevant section of the manual.

The mirrors don't all have the latest version yet, so you can download here:

http://ftp.gnu.org/gnu/emacs/e...

But for big data crunching tasks, compiling and the like, why should that [not] be centralized?

I see two reasons. For one thing, I've have to pay a cellular ISP beaucoup bucks to move the bits between my laptop on the bus and the service-as-a-software-substitute provider. For another, I don't necessarily want the service-as-a-software-substitute provider to be able to data-mine what I'm compiling. Finally, for a lot of projects I work on, it takes ten seconds or less to rebuild a project from make clean even on a 4-year-old laptop with a dinky little 1-core 2-thread Atom N450 CPU, and rebuilding with only a few changed files is even faster. It'd take at least that long to push the source over 3G to a SaaSS provider, wait for build, and pull down the binary, and that's if the SaaSS provider supports all the custom data conversion steps that my build process uses.

Further, I suspect you are somewhat forgetting that this is really a phone, an appliance, and not really a computer, even though it has one inside of it - just like a microwave.

On the contrary, I am explicitly rejecting the notion that it's "not really a computer!"

Can you write scripts like that on anything? A script that "knows" the state of another app? ( a real question, not a troll. )It sounds like you want something similar to Applescript, which allows you to write a script which actually launches whatever apps, invokes the methods exposed by the app via the script library, and then does something else, no?

Yes, Applescript (or even Automator) is pretty much the minimum of what I'm asking for (preferably including shell script Actions). Being able to write something that compiles to a native executable would be even better, but Automator would be the minimum.

If so, I think the reason Apple excludes such a thing is twofold: one, sandboxing and security is difficult with such a beast, and two, .0001% of their customer base wants such a thing. Heck, it's almost dead on the Mac. It would be pretty awesome, though!

I don't particularly care "why" Apple chose to rip out that functionality; I think it is wrong of them to have done so. Divorcing owning a computer from being able to program it is dangerous because it enables a "Right to Read" scenario.

For many people (especially in developing countries) a "smartphone" is the closest thing to a computer they'll ever have for the foreseeable future. I do not want an entire generation of people growing up thinking it's "okay" for some corporation to tell them what they are "allowed" to do with their own damn property!

No. If Apple had developed it, it would not have had any command-line interface except for XML files and the "defaults" program, its interfaces would have been proprietary to Apple,

Yes that's why LLVM, Clang, OpenCL, Zero-Configuration, and WebKit only works on Apple machines.

Wait, what? Where'd all this hostility come from? I've used Macs for 25 years, and I'm using a Mac to type this. I like parts of Apple and MacOS X, but I recognize some of its shortcomings. In my opinion, nothing is perfect.

I didn't say that Apple does not do open source. CUPS, LLVM, Clang, and KHTML (predecessor of WebKit) were not invented at Apple, and Apple complies with the license terms of the original projects. ZeroConf and OpenCL are examples of basic infrastructure that Apple decided would be in their interests if they were widely adopted. Apple has some surprisingly small teams for some projects, and I think of ZeroConf as a Stuart Cheshire project more than a faceless corporate project. Even so, Apple initially did their open-source releases under the Apple Public Source License, which is not compatible with GPL, and the existing OpenCL kernels are all proprietary. Or did you not notice that Mesa had to reimplement OpenCL from scratch?

In contrast, I notice Apple protocols such as AirPlay and AirPrint, the whole Designed for iPhone licensing system, and how Apple is going out of their way to avoid any GPLv3 software such as Samba 3.

CUPS was widely used before Apple bought it. Apple can't turn it into an Apple-like program without causing a user revolt, so it's still very much like how it was before Apple bought it.

Yes Apple is EVIL for not completely changing the software they own to be proprietary and they are also EVIL for forking software they didn't own (WebKit). Face it folks, Apple can do no right.

I don't see how you got that conclusion from what I wrote. I said that CUPS was not developed at Apple, so its peculiarities are not typical to Apple.

Alternatively, someone wielding too much market power based on ownership of APIs may have to grant a (compulsory) license on fair, reasonable and non-discriminatory (FRAND) terms.

"FRAND", also called a uniform royalty regime, has been used to deliberately shut out free software and low-volume proprietary software. Let's hope a broad fair use argument can be made, or else the lack of interoperability will cause the software market to balkanize even more than it already has. For instance, The SCO Group might pop back up and accuse FSF of infringing its UNIX copyright through copying of the UNIX API into the GNU system without an explicit license through The Open Group.

Reading and evaluating the licence would take hours. The GPL is complicated too, but it's a single licence, widely commented on and upheld in courts, used by hundreds of thousands of software packages. I'm not going to give each single-program licence the same time I've given to understand the GPL. (And, according to clause 6 of the TrueCrypt licence, this means I'm not allowed to even use TrueCrypt.) FSF's comments on licences are consistently thorough and faire, and for the TrueCrypt licence they're pretty clear:

"This license is nonfree for several reasons. It says that if you don't understand the license you may not use the program. It puts conditions on allowing others to run your copy. It puts conditions on separate programs that “depend on” Truecrypt. The trademark condition applies to “associated materials”. There are other points in the license which seem perhaps unacceptable (...)"
https://gnu.org/licenses/licen...

VeraCrypt's website says it's "based on TrueCrypt", but the licence page says it's released under the Microsoft (!) Public licence (which is a free software licence, incompatible with the GPL.)

But TrueCrypt (now unmaintained) was never released under any free software licence, so VeraCrypt can't be both based on TrueCrypt and be under the Microsoft Public Licence. Anyone know which info is accurate and why they make this conflicting claim?

Of course, using Microsoft's codeplex hosting, and Microsoft's licence raises doubts about the software given that Microsoft has already been caught handing data to the NSA and putting in backdoors for the NSA.

Dawson points to an 'optimisation' in gcc 4.3: constant folding is done using the higher-precision MPFR library. At least the gcc developers seem to think it's an optimisation, but unless it's disabled by default, it is actually a bug. In the absence of undefined behaviour, optimisations must not change observable behaviour. And, as Dawson demonstrates, this one does.

If you need MPFR precision, you should use MPFR explicitly.

If you take away the internet, your computer becomes significantly worse than it was.

There's plenty I can do with my PC while it is disconnected from the Internet. Because I have no Internet connection while commuting to and from work on public transit, I typically carry about three hours of programming work on my laptop that can be done without connection to the Internet. Or I might download a bunch of pages from Cracked and open them in Firefox tabs to read on the bus. Or I might download an entire page of Slashdot comments, compose replies while offline, and post them the next time I connect. (I did just that for most of this very comment.)

Once you stop needing computing cycles locally, why would you upgrade your system (you being anyone/company/institution)?

In the era of computing on someone else's server, desktop CPUs remain important for at least three reasons. First, desktop and server PCs use CPUs of the same or similar microarchitecture. Better CPUs means each server can handle more load. Second, not everybody wants to blow their entire 5 GB/mo cap on bouncing things off someone else's server. Third, using someone else's server means you're subject to the privacy (or lack thereof) policy of the server operator and whatever other anti-user "dark patterns" are implemented in the non-free software running on that server.

From Eric Blake's bug-bash post

bash -c "export f=1 g='() {'; f() { echo 2;}; export -f f; bash -c 'echo \$f \$g; f; env | grep ^f='"

If you see anything like the following:

bash: g: line 1: syntax error: unexpected end of file
bash: error importing function definition for `g'
1
2
f=1
f=() { echo 2

you're still vulnerable. There may be other issues the above does not cover.

You might want to read my post again. Slowly. Note that in my last paragraph, I was not talking about CVE-2014-6271, but about the other thing Norihiro Tanaka tried. Also note the presence of the word "unlike" in my post. Either you missed that, or you misunderstood the information in your link. If so, to clarify: the old by-design behavior for passing a function to a subshell was by itself not remotely exploitable; it merely forced the shell to parse each and every env variable, making any bugs in the parser (we're counting 6 so far if I'm still keeping track) remotely exploitable. What Florian Weiner did is essentially limit the parsing of env variables to the ones that start with "BASH_FUNC_", which ordinarily cannot be set remotely (unless the daemon or client is criminally insecure). This is more a "defense in depth" style security enhancement than an actual bug fix, and it does have the potential of breaking bash scripts that are too tricky for their own good. It's also a must-have, long overdue, and has the beneficial side effect of eliminating potential namespace collisions between shell functions and other variables, so the "too tricky for their own good" script authors will have to suck it up.

The Arstechnica journalist Sean Gallagher really dropped the ball on this one:
- His information was behind even when it was published. On the 25th of September around 22:00 EST (depending on the version you're running), Debian issued a patch that fixes the new vulnerabilitys CVE-2014-7186 and CVE-2014-7187 AND implements the Florian Weimer suggestion, strongly mitigating the exploitability of any future parser bugs. Red Had and Ubuntu took their sweet time validating this patch suite, but eventually followed suit the evening of the 26th and the morning of the 27th, respectively.
- The Norihiro Tanaka "bug" is documented and intended behavior, which Sean Gallagher could have known simply by clicking next in thread! Specifically, it's how bash passes shell functions to a subshell. Unlike shellshock, it could only be exploited remotely when allowing a remote attacker to set variables with arbitrary names, which is not the case for any widespread software package. If it was, you'd be lost regardless of which shell you're using and it would have been exploited ages ago. Even the Florian Weimer improvement doesn't change this.

There is this thing called tyranny of the default. Canonical assumes that most users want know about the spy technology built into the desktop software, and even fewer will realize they can disable it. The only right way to teach Canonical a lesson is to not recommend Ubuntu, and to recommend other distributions; preferably one of the GNU/Linux distros recommended by the GNU project.

What are you talking about? It is completely factual and a valid point. Apple currently bundles 3.2.51, which is licensed under GPLv2. The patched version of bash is the new 4.3.25, which is licensed using GPLv3. Including it would change the license they are using, which I imagine takes some consideration.

Here are patches for Bash 3.2:

https://ftp.gnu.org/gnu/bash/b...
https://ftp.gnu.org/gnu/bash/b...

What are you talking about? It is completely factual and a valid point. Apple currently bundles 3.2.51, which is licensed under GPLv2. The patched version of bash is the new 4.3.25, which is licensed using GPLv3. Including it would change the license they are using, which I imagine takes some consideration.

Here are patches for Bash 3.2:

https://ftp.gnu.org/gnu/bash/b...
https://ftp.gnu.org/gnu/bash/b...

Or you could assume you are vulnerable and patch bash, or remove it.

Patch bash with what, exactly? Patch #25 didn't fix the problem completely and there's nothing newer than Patch #25 at gnu.org:

ftp://ftp.gnu.org/gnu/bash/bas...