Grsecurity stable patches to be limited to sponsors

Posted Aug 31, 2015 0:31 UTC (Mon) by RCL (guest, #63264)
In reply to: Grsecurity stable patches to be limited to sponsors by clump
Parent article: Grsecurity stable patches to be limited to sponsors

My comments were indeed trollish, but I genuinely don't understand why Linux is chosen for firmware given that comparable more permissively licensed options exist. I suppose it is not always the case of one being technically superior to another, but rather a matter of popularity and "brand recognition".

Grsecurity stable patches to be limited to sponsors

Posted Aug 31, 2015 1:43 UTC (Mon) by pizza (subscriber, #46) [Link] (24 responses)

> I genuinely don't understand why Linux is chosen for firmware given that comparable more permissively licensed options exist.

The thing is, "comparable more permissively licensed options" don't actually exist.

Would Google have used Linux for the Android kernel if it had anything remotely viable as an alternative? This is the same Google that replaced *every* other GPL component component, after all.

The Linux kernel is very far ahead of everything else (permissive or otherwise) in both features and hardware support, even if you only count mainlined stuff.

Grsecurity stable patches to be limited to sponsors

Posted Aug 31, 2015 1:50 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (17 responses)

That's a dangerous position to take. GCC developers thought like this too, yet LLVM has pretty much took over the world.

Grsecurity stable patches to be limited to sponsors

Posted Aug 31, 2015 2:15 UTC (Mon) by pizza (subscriber, #46) [Link] (16 responses)

Yup, LLVM is rapidly replacing completely proprietary compilers.. with other proprietary compilers.

Granted, the latter is generally of a much higher quality than the former, but let's be honest here -- to the end user, the old situation is the same as the new situation -- You're still at the complete mercy of your vendor.

Grsecurity stable patches to be limited to sponsors

Posted Sep 2, 2015 14:18 UTC (Wed) by RCL (guest, #63264) [Link] (15 responses)

Not just proprietary compilers; clang is better than gcc in many aspects as well.

Grsecurity stable patches to be limited to sponsors

Posted Sep 6, 2015 7:08 UTC (Sun) by jospoortvliet (guest, #33164) [Link] (14 responses)

I haven't looked into this myself but I will believe it when Linux distributions start to compile their code with it instead of gcc...

Usually that marks the point where a technology is better than its predecessor. See LibreOffice for example...

Grsecurity stable patches to be limited to sponsors

Posted Sep 7, 2015 0:47 UTC (Mon) by RCL (guest, #63264) [Link] (13 responses)

You need to see what is used by professional developers who have to bet their money on it. Sony, Apple and Google used to rely on gcc heavily; these days all moved on to clang.

Grsecurity stable patches to be limited to sponsors

Posted Sep 7, 2015 1:21 UTC (Mon) by pizza (subscriber, #46) [Link] (10 responses)

> You need to see what is used by professional developers who have to bet their money on it. Sony, Apple and Google used to rely on gcc heavily; these days all moved on to clang.

FWIW, That's not a very good metric. Apple in particular is the primary backer of LLVM. I can't speak of Sony or Google specifically, though I know the latter heavily uses (and contributes to) GCC as well. (And last I checked, Android's NDK still uses GCC). GCC is heavily "used by professional developers" day in and day out.

Incidentally, "professional developer tools" are amongst the worst I've ever had the mispleasure of using. I can't name names because I'd open myself up for legal action.. then again, that's also an example of the sorts of crap one has to deal with when using proprietary tools. One of them even has BSD (4-clause) "open source" stuff in it, not that said code has been sync'd with upstream in years -- leaving us end-users dealing with bugs long since fixed upstream. But hey, it was built on business-friendly "open source", with so much freedom that we can't do anything to fix it.

Grsecurity stable patches to be limited to sponsors

Posted Sep 7, 2015 2:33 UTC (Mon) by RCL (guest, #63264) [Link] (9 responses)

> And last I checked, Android's NDK still uses GCC

Matter of time; they switched: https://www.phoronix.com/scan.php?page=news_item&px=M...

> Incidentally, "professional developer tools" are amongst the worst I've ever had the mispleasure of using.

FOSS code is usually no better; Heartbleed and Shellshock provided the occasion to peek into the most commonly used software, only to find the practices outrageous.

Most importantly, commercial products are being QA'd since they come with guarantees, thus no matter how the code looks, it works (usually, or at least there's someone accountable to make it work). Testing of most Linux distributions is less formal, and for "rolling" ones essentially happens in "production", so all bets are off.

Grsecurity stable patches to be limited to sponsors

Posted Sep 7, 2015 14:24 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> Most importantly, commercial products are being QA'd since they come with guarantees,

HAHAHAHAHA

I can tell you've never been on the receiving end of any commercial product.

Grsecurity stable patches to be limited to sponsors

Posted Sep 13, 2015 17:15 UTC (Sun) by RCL (guest, #63264) [Link] (2 responses)

I am quite often on a receiving end of commercial products. Escalating issues with the vendor works way far more often than it does with FOSS.

Of course, this may depend on the company size and I suspect that if I were escalating issues as a singular end user and not in my employer's name they might have been prioritized differently, but that is expected: end users outnumber developers 99 to 1, no project - FOSS or commercial - can address all their needs at the same priority (and, no, most users cannot fix the issue by themselves in a FOSS product).

So in practice: with commercial products you have at least some feedback mechanism, while with FOSS, if you cannot fix the issue yourself (which may be because you simply don't have time, not just because you lack skills), you won't see the fix in reasonable time.

Most of the bugs I filed against FOSS products (SDL being an exception) are still open. They might have been fixed in practice, but there's no QA pipeline in place to verify that for each new release; unlike commercial vendors, FOSS don't seem to have resources to conduct regular bug scrubs.

Grsecurity stable patches to be limited to sponsors

Posted Sep 13, 2015 17:41 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

>I am quite often on a receiving end of commercial products. Escalating issues with the vendor works way far more often than it does with FOSS.

Did you mean proprietary products here? FOSS != non-commercial.

Grsecurity stable patches to be limited to sponsors

Posted Sep 13, 2015 18:03 UTC (Sun) by RCL (guest, #63264) [Link]

Indeed, these products tend to be both commercial and proprietary. E.g. feature requests in clang are addressed more readily by particular vendors that provide a flavor of it and only then bubble up upstream. __attribute__((optnone)) is a good example.

Grsecurity stable patches to be limited to sponsors

Posted Sep 7, 2015 14:26 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

>> And last I checked, Android's NDK still uses GCC
> Matter of time; they switched: https://www.phoronix.com/scan.php?page=news_item&px=M...

Um, I respectfully suggest you actually read the articles you reference.

That article says that now google uses LLVM to compile *CHROME* for production release builds. It does not apply to the rest of ChromeOS (aka heavily customized Gentoo), nor does it apply to Android.

Grsecurity stable patches to be limited to sponsors

Posted Sep 7, 2015 16:49 UTC (Mon) by nye (subscriber, #51576) [Link]

I was wondering about that too. It is specifically talking about the Chrome build for Android though, and it seems like a reasonable - if not particularly safe - assumption that it's built using the NDK and can therefore be used to infer something about the NDK, maybe.

Grsecurity stable patches to be limited to sponsors

Posted Sep 13, 2015 17:01 UTC (Sun) by RCL (guest, #63264) [Link]

Indeed, I cannot find any public references as to what they use for compiling Android, however I see inclusion of clang in the NDK and switch of some Google software to it as a clear indication of the direction.

Also, lldb is being preferred to gdb, for which I was able to find a public reference: http://tools.android.com/tech-docs/android-ndk-preview

Grsecurity stable patches to be limited to sponsors

Posted Sep 8, 2015 17:36 UTC (Tue) by lsl (subscriber, #86508) [Link] (1 responses)

> Most importantly, commercial products are being QA'd since they come with guarantees

What kind of software comes with guarantees that are actually worth a shit?

Grsecurity stable patches to be limited to sponsors

Posted Sep 13, 2015 17:16 UTC (Sun) by RCL (guest, #63264) [Link]

Working feedback to vendor is more important than one-time guarantees.

Grsecurity stable patches to be limited to sponsors

Posted Sep 13, 2015 6:54 UTC (Sun) by jospoortvliet (guest, #33164) [Link] (1 responses)

You might not be aware of this but the people USING tools at big companies and open source communities are all 'professionals'. The difference is that decisions in Debian and other distributions are MADE by these professionals, while the decisions at G/A/F/M and so on are made by their management, usually for reasons that have little to do with quality, performance or anything like that.

That is exactly why I said what I said: I will believe it when distributions move. Because they will move to using CLANG the day it is actually, technically better than GCC. Unlike Apple, Google and others who would move for business reasons or reasons related to sales, relationships between individuals within the companies and so on. If you have been exposed to decision making in large companies you would know, for sure...

Grsecurity stable patches to be limited to sponsors

Posted Sep 13, 2015 12:07 UTC (Sun) by pizza (subscriber, #46) [Link]

> That is exactly why I said what I said: I will believe it when distributions move. Because they will move to using CLANG the day it is actually, technically better than GCC.

Clang is already technically superior than GCC for many purposes -- Most prominently being its considerable advantage over GCC in C++ compile times (for roughly equivalent code size and performance). LLVM/Clang is also a much nicer codebase to work with, with a more modular internal structure, and is much easier to embed. This opens up entire classes of uses that are nearly impossible to do with GCC -- the fact that pretty much every graphics stack (F/OSS or otherwise) now uses LLVM to compile shaders and whatnot is a testament to that.

I know there are several efforts in play to utilize Clang by the major distributions, but that effort is focused more on uncovering subtle bugs that just happen to be hidden by what basically amounts to a compiler monoculture, and to a lesser extent finding ways in which Clang can be improved. There is no real desire to get rid of/replace GCC outright (outside of the big commercial concerns that are pumping so much money into LLVM, that is. You really must ask yourself why they're doing this, and what it means for you as a developer and/or an end-user..).

While I'm personally glad LLVM/Clang exists and has matured so rapidly, I'm disappointed that so much of the "enthusiasm" surrounding it is solely due to its licensing allowing proprietization and rabid hatred of anything to do with the FSF and its GPL. In doing so, they are enthusiastically acting against their own long-term interests, and proud of it.

Grsecurity stable patches to be limited to sponsors

Posted Sep 2, 2015 12:34 UTC (Wed) by nye (subscriber, #51576) [Link] (5 responses)

>Would Google have used Linux for the Android kernel if it had anything remotely viable as an alternative? This is the same Google that replaced *every* other GPL component component, after all.

In a very real sense, it *isn't* the same Google, given that this choice was made before Google bought Android. It's entirely possible that, had Android started out as a Google project, it could have been based on FreeBSD.

Grsecurity stable patches to be limited to sponsors

Posted Sep 2, 2015 14:09 UTC (Wed) by pizza (subscriber, #46) [Link] (4 responses)

While what you say is plausible on its face, Google bought Android Inc ten years ago (July 2005), two years before anything was publicly revealed (November 2007), and more than three years before anything was made commercially available (October 2008 with the HTC Dream running Android 1.0)

During those years, Google made many, many, many changes to the platform definition, but despite their massive effort to replace all other GPL components (even a new libc!), they chose to heavily modify Linux instead of making similar changes to another kernel.

Since then, Linux's feature and performance gap versus other Free kernels has only grown larger. (For all the complaining about how Linux's ARM stuff is a ginormous mess, everyone else is far, far worse...)

Grsecurity stable patches to be limited to sponsors

Posted Sep 2, 2015 14:35 UTC (Wed) by RCL (guest, #63264) [Link] (1 responses)

There are many FSF-type guys inside Google; so this choice might have been affected by their religious approach to the matter. Other vendors shipped BSD kernels on non-x86 consumer hardware within that time frame and it worked well.

Grsecurity stable patches to be limited to sponsors

Posted Sep 2, 2015 14:46 UTC (Wed) by pizza (subscriber, #46) [Link]

> There are many FSF-type guys inside Google; so this choice might have been affected by their religious approach to the matter. Other vendors shipped BSD kernels on non-x86 consumer hardware within that time frame and it worked well.

That explanation doesn't fly, because Google went well out of their way to replace (and in many cases, create from scratch) alternatives to *every* other traditionally GPL component of a Linux system.

Grsecurity stable patches to be limited to sponsors

Posted Sep 3, 2015 11:46 UTC (Thu) by nye (subscriber, #51576) [Link] (1 responses)

>During those years, Google made many, many, many changes to the platform definition, but despite their massive effort to replace all other GPL components (even a new libc!), they chose to heavily modify Linux instead of making similar changes to another kernel.

Well, you've sort of countered your own point there: after two years of heavy modifications, switching kernel would have increased the time to market by enough that Android might never have taken off. All of the other components were much more readily replaceable, either with drop-in replacements already existing, or by developing their own in tandem (based at least partly on BSD code, as it turned out), but the kernel was the largest and most specialised part.

I'm certainly not convinced (or trying to claim) that, given the choice from step zero, Google would definitely not have chosen Linux. I am convinced however that by the time Google bought Android it was already far enough along that changing the OS it's built on would have been commercial suicide for the project, and that Android doesn't therefore make a good example of Google's choices, because I don't believe they really had one.

Grsecurity stable patches to be limited to sponsors

Posted Sep 3, 2015 13:56 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> that Android doesn't therefore make a good example of Google's choices, because I don't believe they really had one.

Sure they did, they could have not bought Android and went somewhere else, or started their own in-house because they certainly got a good look at the technology stack and roadmap as part of due diligence before purchasing the company. Google has invested a lot in the Linux kernel, not just in Android, over the years so it is still a good fit for the company, they have (and had at the time) a lot more Linux kernel expertise than BSD, even if in many cases what they run on top of the Linux kernel is Google proprietary.