thanks GNU! - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2017, 02:18:58 pm
content: QuoteThus I have to waste 1 day to sync a new rootfs

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2017, 02:32:57 pm
content: thus, two affected compilers which I happen to use a lotsys-devel/gcc-4.4.7dev-lang/gnat-gcc-4.3.5

author: Kalvin
author_rank: Super Contributor
timestamp: August 22, 2017, 03:24:01 pm
content: Use virtualized environment and do not update the tools.

author: RGB255_0_0
author_rank: Frequent Contributor
timestamp: August 22, 2017, 03:58:42 pm
content: Quote from: Kalvin on August 22, 2017, 03:24:01 pmThen what do you do when your software gets hacked because of some exploit?

author: ataradov
author_rank: Super Contributor
timestamp: August 22, 2017, 04:12:54 pm
content: Don't use Gentoo if you want stable system. I've been using Linux since 2001. Debian -> Ubuntu -> Mate. Never had a real problem.

author: Kalvin
author_rank: Super Contributor
timestamp: August 22, 2017, 04:19:05 pm
content: Quote from: RGB255_0_0 on August 22, 2017, 03:58:42 pmCompilers get exploited when they are not updated any more? Keep your host updated. Backup your stuff. Use the virtualized environment for compilation and development stuff only. Use multiple virtualized containers if you need to support multiple legacy tool-chains.

author: Kalvin
author_rank: Super Contributor
timestamp: August 22, 2017, 04:20:20 pm
content: Quote from: ataradov on August 22, 2017, 04:12:54 pmPretty much similar path here too.

author: RGB255_0_0
author_rank: Frequent Contributor
timestamp: August 22, 2017, 04:35:28 pm
content: Quote from: Kalvin on August 22, 2017, 04:19:05 pmhttps://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-960/GNU-GCC.htmlhttps://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.htmlNot all exploits result in compiled applications being exploitable but it doesn't mean you can be ignorant by thinking that just because you've isolated your build machine that your apps you've compiled using them are not.

author: Kalvin
author_rank: Super Contributor
timestamp: August 22, 2017, 04:53:51 pm
content: Quote from: RGB255_0_0 on August 22, 2017, 04:35:28 pmGood points.

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2017, 07:33:01 pm
content: Quote from: ataradov on August 22, 2017, 04:12:54 pmUnfortunately I need it for several reasons.

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2017, 07:37:44 pm
content: Quote from: Kalvin on August 22, 2017, 04:19:05 pmYup, I have created a miniroot of the old rootfs as well as a full backup.Also I have already moved stuff into a VirtualBox machine as well as a UML.(user mode linux)I prefer the UML-way for toolchains, but VirtualBox is the simplest way, and my customers prefer it.

author: legacy
author_rank: Super Contributor
timestamp: August 23, 2017, 08:43:39 am
content: in the meanwhile I am moving the new rootfs to gcc-v5.4.0

author: legacy
author_rank: Super Contributor
timestamp: August 23, 2017, 09:21:44 am
content: I mean, it's highly suggested, and I suggest you to do the same, guysin order to avoid future problems

author: bd139
author_rank: Super Contributor
timestamp: August 23, 2017, 09:32:10 am
content: Sounds like fun!Use a stable distribution (CentOS/Debian or something) and build your own cross toolchain on top of it. It's the only way this doesn't come and bugger you randomly one day. I speak from experience. If you build a cross toolchain then make sure you automate the build via make or something. Takes a few hours to get it right the first time but you can build individual compiler/binutils/valgrind versions as and when they drop or do the opposite and never patch a damn thing.I have two environments, one with LLVM and one with GCC in it so we can test each in isolation.Not a fan of virtualizing/containerising it. It's difficult to make that build repeatable in the future unless you build the environment with docker/vagrant and those require more effort than the above.

author: legacy
author_rank: Super Contributor
timestamp: August 23, 2017, 10:02:08 am
content: Quote from: bd139 on August 23, 2017, 09:32:10 amMan, I have 15 years of experience with gentoo.Everything (including experimental stuff) I do for whatever architecture I have to support { MIPS32BE, HPPAv2, POWERPC, X86} is done by Overlay recipes, while the whole rootfs is under Catalyst, and Catalyst compiles every new rootfs as chroot.The main rootfs is safe and never update until things have passed the stable level (whose severity level is more fussy than on Debian-stable, I mean I am fussier than those guys).Things are under control, but GNU sucks a lot, and their FSK software is always broken, indeed even guys behind Ubuntu, Centos, etc, have the same problems I have every FSK time we need to update something.Now the whole GlibC is ... fragile

author: ataradov
author_rank: Super Contributor
timestamp: August 23, 2017, 10:07:03 am
content: What's the point of complaining? Don't like it - don't use it. Since you keep using it, there must be no better option, so GNU guys did pretty well, I would say.Everyone can complain, if you think you can do better - contribute, and everyone will be better for it.

author: bd139
author_rank: Super Contributor
timestamp: August 23, 2017, 10:21:40 am
content: Quote from: legacy on August 23, 2017, 10:02:08 amThat sounds painful but it's not a terrible solution.Agree with glibc being shit. So many WTFs and GNUisms in there. Why do you think we've got an LLVM build going? Hopefully libc++ will be usable at some point

author: legacy
author_rank: Super Contributor
timestamp: August 23, 2017, 11:09:07 am
content: Quote from: ataradov on August 23, 2017, 10:07:03 amMan, I don't like it, but it's my job.Likes dislikes, they don't matter with your customers.

author: legacy
author_rank: Super Contributor
timestamp: August 23, 2017, 11:20:25 am
content: Quote from: bd139 on August 23, 2017, 10:21:40 amNah, it's common routine once you have mastered Catalyst and written some hundred OverlaysQuote from: bd139 on August 23, 2017, 10:21:40 amYup, the best idea everUnfortunately I have some ebuilds (gentoo-way to say "building recipes") which needs C++, and some problem supporting LLVM under HPPA and MIPS (they are both experimental with LLVM), but it's a MUSTbeDONE point in my todo list.

author: legacy
author_rank: Super Contributor
timestamp: August 23, 2017, 11:38:18 am
content: also be warned aboutthisproblem, caused by cmake!

author: bd139
author_rank: Super Contributor
timestamp: August 23, 2017, 12:48:55 pm
content: Argh cmake is just shit. We use BSD make.

author: bingo600
author_rank: Super Contributor
timestamp: August 23, 2017, 03:49:31 pm
content: Quote from: ataradov on August 23, 2017, 10:07:03 am/Bingo

author: bd139
author_rank: Super Contributor
timestamp: August 23, 2017, 04:53:02 pm
content: Thats something that someone who hasn't contributed to an open source piece of software says. The reality is it's a nightmare. I've made hundreds of pull requests, patches via email over the years and the accept rate is around 5%. Most are ignored, deleted or closed silently or result in a flame war because some little big man's ego has been damaged by the idea that someone wants to contribute. So I gave up, maintain patch forks of some things we use.

author: legacy
author_rank: Super Contributor
timestamp: August 23, 2017, 05:03:49 pm
content: Quote from: bd139 on August 23, 2017, 04:53:02 pmExactly the point! GNU has the lowest quality of guys to deal with!Their EGO ...Have you ever tried to read and study the GCC internals?have you ever tried to point out that ... some piece of code is too obscure (thus, it might be hide a bug)? If you point out this to someone in the maillist you will be considered an inferior idiot until someone in the CLUB blesses you.Well, they can have a basket of pine cones attached to my bug-reports

author: bd139
author_rank: Super Contributor
timestamp: August 23, 2017, 07:31:20 pm
content: Yep exactly that.Some of the shit it spews out when you crank up optimisation is funny. I could a few years ago actually get it to eliminate live code and optimise out a loop so it only ran once. I think it was Theo De Raadt who explained that only the basic x86/x64 back ends are actually even slightly tested. Ugh it's just horrible.

author: Mr. Scram
author_rank: Super Contributor
timestamp: August 23, 2017, 08:07:17 pm
content: Quote from: bd139 on August 23, 2017, 04:53:02 pmI had the same experience contributing to Wikipedia. Naively, I thought it'd be cool to contribute to something I've found so very useful. So I rewrote an article to be more unbiased, clarified a few things and removed other ambiguous things without sources. Within a day, the whole thing was fully reverted by the original author. I've tried rewriting my contribution a couple of times in various ways, but most of it was trashed within hours.It seems authors appropriate certain articles and will not accept any contribution or change to their work. This guy was also part of a group that considers itself guardian of the subject, which may contribute to a sense of entitlement and a lack of acceptance of any other contributions. That's been the first and last time I ever tried contributing anything to Wikipedia, other than fixing a few typos.Sadly, it seems open source also has this problem. Ideas and project are split into myriad fractions, each of which compete but often do the same thing. Most of them do not have enough momentum to produce well rounded products, leading to a huge mass of not very amazing software and hardware products or, if there is some momentum, a dazzling array of alternatives with little differences between them. Long term support also is often very shaky. Ego seems to be a large part of that. Rather than working in the service of another, people would rather fork and do something themselves, even though the end product suffers. Disagreements also often seem to be 'resolved' by forking, rather than working things out together. That's a bit like taking the ball and going home, except that the ball gets copied. Due to the many competing opinions and no one to sign off on decisions, projects often are a jumbled mess of ideas and strategies.Don't get me wrong, I really appreciate the concept and philosophy of the open source community and am happily using various products that have resulted from it, but there are a few serious issues that cause the whole effort to be much less fruitful than it could be.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: September 03, 2017, 12:57:13 am
content: What? There are software people and coders with poor people skills? Who knew?And you mean they gravitate to tasks which minimize their need to expose those lacks? How strange.

author: aandrew
author_rank: Frequent Contributor
timestamp: September 04, 2017, 01:24:44 am
content: Quote from: Kalvin on August 22, 2017, 03:24:01 pmAbsolutely, 100% this. This is exactly how I do my dev environments. The disk files will work for as long as you can boot the VM, and they won't ever change unless you need them to.I don't know why more people don't do this. It's the only sane approach.

author: aandrew
author_rank: Frequent Contributor
timestamp: September 04, 2017, 01:32:35 am
content: Quote from: RGB255_0_0 on August 22, 2017, 04:35:28 pmWhile technically true, this is *such* a remote case that you're far, far, far more likely to be bitten by your own poor software development before a compiler exploit makes you look bad. Worry about the most common causes of software vulnerability/exploitability before worrying that an old compiler version is making your software vulnerable.

author: Howardlong
author_rank: Super Contributor
timestamp: September 04, 2017, 03:47:57 pm
content: Quote from: aandrew on September 04, 2017, 01:24:44 amIndeed, that has been my approach for some time now. Without it, you unnecessarily end up down long rabbit holes blaming your continually changing environment. It brings stability to your build environment, and when you come to maintain something months or years later, you don't have to spend days of your life rebuilding a working toolchain, because half the stuff you used is now deprecated.Much of the time there is no reason for it to be connected to the Internet, or any network for that matter. And as you've no doubt backed the entire VM up, you have a crisp known working setup to go back to should anything go badly wrong.I'd say your average internet connected PC is at significantly greater risk compared to a sandboxed VM.

author: bd139
author_rank: Super Contributor
timestamp: September 04, 2017, 05:17:32 pm
content: Just to add, build your build environments with ansible and vagrant. That means you have the recipe stored as well. If you need a specific package upgraded or to test something it makes reproducing that environment trivial.we cd into a directory, type vagrant up and ten minutes later you get a fresh VM sitting there with all tools deployed.

author: macboy
author_rank: Super Contributor
timestamp: September 06, 2017, 03:29:33 pm
content: Quote from: bd139 on September 04, 2017, 05:17:32 pmWe do something similar, but using simple chroot. It's not a full blown VM, but you do get the same, fresh filesystem with all the build tools set up exactly as intended, with no leftover garbage from last time.

author: Mr. Scram
author_rank: Super Contributor
timestamp: September 06, 2017, 08:28:31 pm
content: Quote from: bd139 on September 04, 2017, 05:17:32 pmCan you tell a little more about Ansible and Vagrant? They have a very well looking and polished website that manages to convey suprisingly little about what their product is and does.

author: bd139
author_rank: Super Contributor
timestamp: September 06, 2017, 08:40:49 pm
content: Vagrant is a tool that allows you to build virtual machine images using a single definition file. You point it at a system image and it will go fetch it, set up virtualbox, set up all the networking and everything, deploy all your software and off you go. Example:Code:vagrant init centos/7vagrant up# wait a few minutes the first time as it downloads and caches the imagevagrant sshAnd you're in a VM! See:https://www.vagrantup.com/intro/getting-started/for details. You can store the Vagrantfile definition in source control and share that between team members if you need to afterwards as well. It will set up synced folders etc as well.Ansible happens as part of the above. Ansible is "desired state configuration" so you can say "i want these packages", "i want this file to be here", "i want this to happen", "i want these ports open on the firewall" and it will take whatever the state of the system is even if you've fudged it around and make it happen. These definitions are stored in files as well, in source control. This means you can version your entire toolchain, environment, everything!Just git checkout the tag, vagrant up and your toolchain is online. That includes the toolchain you had 7 years ago if you want.Your entire toolchain becomes a few kb of configuration in a source repository. No storing gigabytes of crap for years.Ansible intro.http://docs.ansible.com/ansible/latest/intro.htmlhttp://docs.ansible.com/ansible/latest/playbooks.htmlAnsible is pretty amazing. You can use it to talk to hundreds of machines at once and make them all dance the same dance or just use it to set up a single one.Here's a list of what it can do automatically:http://docs.ansible.com/ansible/latest/modules_by_category.htmlAs an example, if you don't want to do local dev or need a hefty build machine for a big source project, you can point it at Amazon EC2, fire up a massive instance using EXACTLY the same configuration you have in your local image, compile everything, deliver the compiler output, then shut it down and send you an email.

author: savril
author_rank: Regular Contributor
timestamp: September 08, 2017, 11:18:29 am
content: Another option for "virtual" environment isDocker. It use Linux cgroup abilities to provide an environment with a separate set of libraries while running the process in the same space as your main Linux (but with a level of isolation). The virtual environment is called a container. Containers have the advantage of being much faster to build and launch while it has less isolation with your main system.It can also run with Mac and Windows, it run in a VM but provide roughly the same functions. You can for example run a shell command in the container but launched in your main system command shell.For example you can rundocker execmycontainerid"echo hello world"and it will run the echo in the container while it will output the result in your Windows shell. Withdocker -i execmycontaineridbashyou can have an interactive shell running in the container while you enter your commands in your Windows shell.You can also access your local filesystem within the container.You can build the images with a simple Dockerfile.Code:FROM ubuntu:zestyARG DEBIAN_FRONTEND=noninteractiveRUN apt-get update && apt-get -y install \gcc-arm-none-eabi \build-essential \cmake \gitDocker tend to replace Vagrant in the IT world. For build and continuous integration, the major advantage is the faster time to launch the virtual environment. A container launch in less than a second. So you don't have to keep a VM started. And it consume less memory too. In a VM you have to get the whole system running with its necessary utilities (for example cron, ...). In a container, you just launch the programs you need.However, if you run docker in Mac or Windows, keep in mind that you'll have a VM running with a strip down version of Linux (1G of RAM seem a reasonable minimum for the VM).

author: legacy
author_rank: Super Contributor
timestamp: September 08, 2017, 11:42:38 am
content: Quote from: bd139 on September 06, 2017, 08:40:49 pmoh, it looks gentoo-ish CatalystBut thanks, it's very useful, and simpler!And thanks for your example!

author: legacy
author_rank: Super Contributor
timestamp: September 08, 2017, 11:43:56 am
content: Quote from: savril on September 08, 2017, 11:18:29 amWOW. It's a brilliant idea