[solved] I really HATE gnu and linux - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 03:10:38 pm
content: a customer needs to supportsandpoint-x3/kernel-2.6.22Code:make-ppcCode:Makefile:1449: *** mixed implicit and normal rules: deprecated syntax/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/Makefile:1449: *** mixed implicit and normal rules: deprecated syntaxmake: *** No rule to make target 'silentoldconfig'. Stop.make: *** No rule to make target 'include/config/auto.conf', needed by 'include/config/kernel.release'. Stop.otaCode:make-ppc -dand the above command tells a lot of crap: how to solve?deprecated syntax, crap scripts, and once again …… it looks like a mission impossible(where the FSCK is my personal jesus ?)

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 03:13:11 pm
content: the above was perfectly working in 2008thusWHY ?!?they want to change thingswith the result of making them brokenmy pants

author: Bud
author_rank: Super Contributor
timestamp: April 02, 2016, 03:32:47 pm
content: Quote from: legacy on April 02, 2016, 03:13:11 pmYou must be kidding. They often brake things with the next update, that was a major reason I abandoned my hard work attempts to introduce Linux to myself.

author: f1rmb
author_rank: Regular Contributor
timestamp: April 02, 2016, 03:45:09 pm
content: Hi,This has nothing to do with Linux (I love this kind of false arguments about Linux and the inability for people to open their mind and change their (bad) habits); GNU make was tolerant in the past with some rules, but that was cleaned out:http://osdir.com/ml/bug-make-gnu/2011-04/msg00011.html(googling <30s BTW)Cheers.---Daniel

author: jancumps
author_rank: Unknown
timestamp: April 02, 2016, 03:48:02 pm
content: EEVBlog is in an operating system deadlock now. We have a thread where we hate Windows, and one where we hate Linux. There's no way out from here...

author: AF6LJ
author_rank: Unknown
timestamp: April 02, 2016, 03:55:58 pm
content: As someone already pointed out; it is not the fault of Linux...

author: Kleinstein
author_rank: Super Contributor
timestamp: April 02, 2016, 04:06:48 pm
content: You likely got the same warming (deprecated syntax) in 2008, so there was plenty of time to fix the make-file.The good thing is, the make-file is human readable, at least in principle. So there might be someone who can translate to old / mixed syntax.

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 04:08:09 pm
content: my effort to fix the jam, practically it will take the whole weekend(I had been thinking it would have taken just a couple of hours)let's go fixing things (can i change my job?the summer is coming and I want to sell ice creams)

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 04:15:56 pm
content: Quote from: Kleinstein on April 02, 2016, 04:06:48 pmthere are 2132 errors, inside a hierarchical tree with things written sparse around, oh,plus things that seem written by bot, do human beings write things with so much complexity?because G-Boys and Loooooniiiiix-boys: want to be called "GURU"while I am an ICE-cream salesman (and I sell just 5 kinds of tastes)

author: nctnico
author_rank: Super Contributor
timestamp: April 02, 2016, 04:20:53 pm
content: Quote from: f1rmb on April 02, 2016, 03:45:09 pmA change -however technically justified- which makes things backwards incompatible is a no-go. Unfortunately many programmers don't understand that and don't see that changing a version means re-testing everything again which usually is a very tedious and time consuming task.So unfortunately if you need to support older GNU software then you have to have a virtual machine with that version because newer versions are likely to break things.

author: nomadd
author_rank: Contributor
timestamp: April 02, 2016, 04:26:05 pm
content: Quote from: legacy on April 02, 2016, 03:10:38 pmNot sure how long you have been involved in software development? In my case, about 33 years. And all I can say is: I've seen worse. Far worse.It's giving you the relevant details. Look at the section of breaking code, the error message, and Google a bit. Then get stuck in and fix it - it's only a make file after all.If you have such a hatred for Linux and the GNU toolchain - and are going to react this way every time you hit a problem with a piece of code you haven't run for EIGHT YEARS - then I really would suggest that career in ice cream sales you were mentioning.Unless this is actually April 1st and I'm missing the joke here?

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 04:28:25 pm
content: Code:make-ppc -d(-d, forcing debug)Code: compilingGNU Make 4.1Built for i686-pc-linux-gnuCopyright (C) 1988-2014 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.Reading makefiles...Reading makefile 'Makefile'...Reading makefile '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include' (search path) (no ~ expansion)...Reading makefile 'include/config/auto.conf' (search path) (don't care) (no ~ expansion)...Reading makefile 'include/config/auto.conf.cmd' (search path) (don't care) (no ~ expansion)...Reading makefile '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile' (search path) (no ~ expansion)...Makefile:1449: *** mixed implicit and normal rules: deprecated syntaxUpdating makefiles....Considering target file '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile'.Looking for an implicit rule for '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile'.No implicit rule found for '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile'.Finished prerequisites of target file '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile'.No need to remake target '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile'.Considering target file 'include/config/auto.conf.cmd'.File 'include/config/auto.conf.cmd' does not exist.Finished prerequisites of target file 'include/config/auto.conf.cmd'.Must remake target 'include/config/auto.conf.cmd'.Successfully remade target file 'include/config/auto.conf.cmd'.Considering target file 'include/config/auto.conf'.File 'include/config/auto.conf' does not exist.Considering target file '.config'.Finished prerequisites of target file '.config'.No need to remake target '.config'.Pruning file 'include/config/auto.conf.cmd'.Finished prerequisites of target file 'include/config/auto.conf'.Must remake target 'include/config/auto.conf'.Putting child 0x9e83290 (include/config/auto.conf) PID 3422 on the chain.Live child 0x9e83290 (include/config/auto.conf) PID 3422GNU Make 4.1Built for i686-pc-linux-gnuCopyright (C) 1988-2014 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.Reading makefiles...Reading makefile '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/Makefile'...Reading makefile '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include' (search path) (no ~ expansion)...Reading makefile '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile' (search path) (no ~ expansion).../root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/Makefile:1449: *** mixed implicit and normal rules: deprecated syntaxUpdating makefiles....Considering target file '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile'.Looking for an implicit rule for '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile'.No implicit rule found for '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile'.Finished prerequisites of target file '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile'.No need to remake target '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/arch/powerpc/Makefile'.Considering target file '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include'.Looking for an implicit rule for '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include'.No implicit rule found for '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include'.Finished prerequisites of target file '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include'.No need to remake target '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include'.Considering target file '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/Makefile'.Looking for an implicit rule for '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/Makefile'.No implicit rule found for '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/Makefile'.Finished prerequisites of target file '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/Makefile'.No need to remake target '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/Makefile'.Updating goal targets....Considering target file 'silentoldconfig'.File 'silentoldconfig' does not exist.Looking for an implicit rule for 'silentoldconfig'.No implicit rule found for 'silentoldconfig'.Finished prerequisites of target file 'silentoldconfig'.Must remake target 'silentoldconfig'.make: *** No rule to make target 'silentoldconfig'. Stop.Reaping losing child 0x9e83290 PID 3422Removing child 0x9e83290 PID 3422 from chain.Failed to remake target file 'include/config/auto.conf'.Considering target file '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include'.Looking for an implicit rule for '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include'.No implicit rule found for '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include'.Finished prerequisites of target file '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include'.No need to remake target '/root/sandpoint-x3/kernel-2.6.22-sandpoint3-G4/scripts/Kbuild.include'.Considering target file 'Makefile'.Finished prerequisites of target file 'Makefile'.No need to remake target 'Makefile'.Updating goal targets....Considering target file 'zImage'.File 'zImage' does not exist.Considering target file 'vmlinux'.File 'vmlinux' does not exist.Considering target file 'arch/powerpc/kernel/vmlinux.lds'.File 'arch/powerpc/kernel/vmlinux.lds' does not exist.Considering target file 'init'.File 'init' does not exist.Considering target file 'prepare'.File 'prepare' does not exist.Considering target file 'prepare0'.File 'prepare0' does not exist.Considering target file 'archprepare'.File 'archprepare' does not exist.Considering target file 'checkbin'.File 'checkbin' does not exist.Finished prerequisites of target file 'checkbin'.Must remake target 'checkbin'.Putting child 0x9e82858 (checkbin) PID 3455 on the chain.Live child 0x9e82858 (checkbin) PID 3455Reaping winning child 0x9e82858 PID 3455Live child 0x9e82858 (checkbin) PID 3456Reaping winning child 0x9e82858 PID 3456Removing child 0x9e82858 PID 3456 from chain.Successfully remade target file 'checkbin'.Considering target file 'prepare1'.File 'prepare1' does not exist.Considering target file 'prepare2'.File 'prepare2' does not exist.Considering target file 'prepare3'.File 'prepare3' does not exist.Considering target file 'include/config/kernel.release'.File 'include/config/kernel.release' does not exist.Considering target file 'include/config/auto.conf'.Recently tried and failed to update file 'include/config/auto.conf'.make: *** No rule to make target 'include/config/auto.conf', needed by 'include/config/kernel.release'. Stop.doneis it clear? do you understand something?

author: Kalvin
author_rank: Super Contributor
timestamp: April 02, 2016, 04:30:47 pm
content: Just switch to Windows and you will be happy again

author: linux-works
author_rank: Super Contributor
timestamp: April 02, 2016, 04:32:08 pm
content: doing a make as root inside a root folder....LMAO!just hire someone to fix your problem. I doubt you'll ever get there yourself.

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 04:54:46 pm
content: Quote from: nomadd on April 02, 2016, 04:26:05 pmlong life and prosper, looooooniiiiiiix, the following was "easy" to be fixedCode:config %config: scripts_basic outputmakefile FORCE$(Q)mkdir -p include/linux include/config$(Q)$(MAKE) $(build)=scripts/kconfig $@Code:## fixed#config menuconfig: scripts_basic outputmakefile FORCE$(Q)mkdir -p include/linux include/config$(Q)$(MAKE) $(build)=scripts/kconfig $@2132 -1 = just 2131 errors still need to be fixednot mention thatI have also a lot of hardware problems waiting to be solvedI am not the looooniiiix-guy, thus …… I am telling you what I am going to do: I am going to put my old (2008) laptop's stage4 into QEMUsince it was and it's still perfectly able to recompile the old linux kernel 2.6.22this way I will avoid to- have to understand what changed between 2008 Makefile and 2016 Makefile, and adjust scrips(1)- have to understand what is going wrong with GCC-v5, and why it is refusing to compile the 2.6.22 kernelQuote from: nomadd on April 02, 2016, 04:26:05 pmabsolutely

author: f1rmb
author_rank: Regular Contributor
timestamp: April 02, 2016, 05:01:36 pm
content: Quote from: legacy on April 02, 2016, 04:15:56 pmQuote from: nctnico on April 02, 2016, 04:20:53 pmHow could you browse the net with your NCSA Mosaic?Sometimes, you have to break API/ABI, this is how things evolves.Could you drive a horse on a highway?The makefiles was designed to be used with an old make version, which was supporting some (probably) ugly rules mixing. It was decided that should be cleared, and that breaks the oldest makefiles using that "feature".If the OP wants to build such old kernel, he needs to make this with a 8 years old system, or fix the makefile's rules to comply with the new gnu make semantics.Cheers.---Daniel

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 05:03:50 pm
content: Quote from: nctnico on April 02, 2016, 04:20:53 pmprecisely!Quote from: nctnico on April 02, 2016, 04:20:53 pmexactly what I am going to do

author: nomadd
author_rank: Contributor
timestamp: April 02, 2016, 05:09:46 pm
content: Quote from: legacy on April 02, 2016, 04:54:46 pmProbably by far the best approach. That is an old kernel built with much older versions of the toolchain. I doubt it's worth the effort of trying to get it all to work on more recent versions of the toolchain, tbh.I realise it's frustrating.. I've had similar issues all week myself porting some code - written just last year - to a newer version of the same product.. In my case, I have no option to turn back - the client insists on rushing firmly into the future full speed!Anyway, best of luck.

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 05:18:28 pm
content: Quote from: nomadd on April 02, 2016, 05:09:46 pmprecisely, I hope you can appreciate my dry humor in this topicused to hide the sad Truth: linux is a very frustrating experience!especially during the weekend (I have to respect a deadline)Quote from: nomadd on April 02, 2016, 05:09:46 pmI have to provide a couple of Sandpoint boards to a customer (in China),I was supporting VxWorks for an other customer in Automotive, I have a few skill with PowerPC and with such a board(a few products are based on Sandpoint X3, and I played with them)unfortunately my last customer doesn't want to pay the license (to Winderiver),thus they asked the last available open source linux kernel with a customizationand here we areQuote from: nomadd on April 02, 2016, 05:09:46 pmthank you

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 05:22:29 pm
content: herea few lines about "makefile-rule-error-mixed-implicit-and-normal-rules"

author: mazurov
author_rank: Frequent Contributor
timestamp: April 02, 2016, 05:44:40 pm
content: Quote from: legacy on April 02, 2016, 03:13:11 pmNext time you backup a project don't forget to include the whole toolset.

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 06:59:12 pm
content: Code:include/linux/compiler.h:40:2: error: #error no compiler-gcc.h file for this gcc version#error no compiler-gcc.h file for this gcc versioninterestingCode:gcc-config -l | grep powerpc powerpc-unknown-linux-gnu-5.3.0 *

author: Howardlong
author_rank: Super Contributor
timestamp: April 02, 2016, 07:17:07 pm
content: Without wishing to inflame things, I work on OSX, Linux and Windows, and they all deprecate stuff. However what I would say is that Linux will inevitably suffer much more from things breaking becuase it's essentially built by an enormous committee of people with unaligned aims.As a result the average half life of an online recipe document for achieving something in Linux can usually be measured in a few weeks before it breaks, and then you're into a maze of rabbit holes to try to fix it. It's been like that ever since I started using it in the mid 90s.OSX and Windows have their own rabbit holing to deal with, but your average recipe for those seem to have significantly better longevity.As a suggestion to the OP, consider building a virtual machine template for you build environment, at least you stand a fighting chance at being able to build your software again reasonably easily in the furure. But I feel your pain.

author: mikerj
author_rank: Super Contributor
timestamp: April 02, 2016, 07:27:32 pm
content: Quote from: linux-works on April 02, 2016, 04:32:08 pmThis is a very typical example of the sort of help you can expect if you have a problem with Linux and have to ask the "experts". You can sort of see why Linux is still an also ran against Windows and OSX on the desktop...

author: XynxNet
author_rank: Regular Contributor
timestamp: April 02, 2016, 07:29:22 pm
content: Well it is not linux specific. A few years back I had the dubious fun to fix some bugs in old VC6 code. It was a major hassle to get it to compile with an up to date version of Visual Studio.

author: Stray Electron
author_rank: Super Contributor
timestamp: April 02, 2016, 07:31:46 pm
content: Quote from: Kalvin on April 02, 2016, 04:30:47 pmFixed it for you.

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 07:39:43 pm
content: Quote from: Howardlong on April 02, 2016, 07:17:07 pmdone!I have- extracted myold 2008 stage4 from my old laptop(it's aPowerBook-G4, running gentoo linux)- created aQemu/PPCvirtual machine- installed the stage4, which comes with gcc v4.1.2, native compiling host=target=powerpcresultskernel-2.6.19-sandpoint3-G4:successkernel-2.6.22-sandpoint3-G4:successwith "success" I mean- it compiles- the final binary boots on the final targetin paralel I have also- downloadedVirtualPC- installed gentoo-stage3/x86 32bit- fixed up to 215 errors, most of them are the same error repeated several time(1)- made a regression from i686-pc-linux-gnu-5 to i686-pc-linux-gnu-4.9.3- cross-emerged gcc v4.1.2 and binutils 2.25.1-r1 forPowerPCCode:otaku sandpoint3 # gcc-config -l i686-pc-linux-gnu-4.9.3 * powerpc-unknown-linux-gnu-4.1.2 *resultskernel-2.6.19-sandpoint3-G4:successkernel-2.6.22-sandpoint3-G4:failure/it does not compile(1) those "silly" errors(2) are are lying along the whole treeincluding script folders and subfolders, and source foldersthere are also a lot of wrong things with "arch/powerpc" and "arch/ppc"I have also removed the "arch/ppc" folder, and forced things into "arch/powerpc"as I am invoking gcc with the followingCode:myccandclib="powerpc-unknown-linux-gnu-"make ARCH=powerpc CROSS_COMPILE=$myccandclibedit:(2) most of them appear as*** mixed implicit and normal rules*** deprecated syntaxand as "wrong path", due to the confusion between "ppc" and "powerpc"e.g. fatal error: "arch/ppc/kernel/head_32.S": No such file or directorywhile the file is "arch/powerpc/kernel/head_32.S"but there are also errors which are gcc-version dependentand I do not really want to fight with gcc >= v4.2

author: Howardlong
author_rank: Super Contributor
timestamp: April 02, 2016, 07:41:29 pm
content: Quote from: XynxNet on April 02, 2016, 07:29:22 pmI still use VC6.... and half a dozen versions after that, but it's getting harder to make it run on newer Windows versions, but I still occasionally use it as I have sh!t loads of boiler plate code I've written over the years in it. As for getting basic C stuff to compile in later versions of VS, I don't find it that hard as a general rule, but then much of my stuff still uses vanilla Win32 API.

author: hendorog
author_rank: Super Contributor
timestamp: April 02, 2016, 08:05:38 pm
content: Quote from: Stray Electron on April 02, 2016, 07:31:46 pmApril 1? Windows 10 on ppc

author: janoc
author_rank: Super Contributor
timestamp: April 02, 2016, 08:44:44 pm
content: Quote from: mikerj on April 02, 2016, 07:27:32 pmThe post you have quoted was not very mature nor helpful, indeed. However, your reaction with this non-sequitur only helps fuel such fanboys.That Linux is not widespread on desktop has all to do with immature kiddies on forums and certainly nothing at all with well documented anticompetitive behaviour of a certain company that pulled all stops whenever any PC vendor even mentioned they could offer preinstalled Linux ... Surprisingly, outside of PC space where that vendor doesn't have a near monopoly Linux is doing very well, despite all those kiddies. I do wonder why is that.And re OPs problem - good luck trying to get a piece of hw that was designed for Windows XP running in today's Windows 8/10 unless there is a specific support from the vendor. Or software that depends on old releases of Visual Studio/Delphi or something like that. I am battling these issues all the time at work.But right, software evolution/deprecation and not doing the common sense thing (aka complete backup of the development system - not necessarily a VM, which may not have been an option 8 years ago) is somehow Linux's problem ...Oh and nctnico's comment about breaking backward compatibility being a bad thing - I am really glad that you aren't in charge of this stuff or we would be still having only two gears in our cars like Model T and computers would come with punch card readers.Czechs have a nice saying I have learned when starting with software engineering many moons ago. It loosely translates as: "programmer that blames his tools has just cut his own suspenders" (implying his ass is naked now).Seriously guys ...

author: Howardlong
author_rank: Super Contributor
timestamp: April 02, 2016, 09:01:53 pm
content: Retaining backwards compatibility does not mean holding back progress.How would you feel if you got in a new car and found the brake and accelerator pedals swapped?

author: legacy
author_rank: Super Contributor
timestamp: April 02, 2016, 09:14:16 pm
content: my 2008 stage4 comes withCode:gcc-config -l powerpc-unknown-linux-gnu-3.4.6 powerpc-unknown-linux-gnu-4.1.1 powerpc-unknown-linux-gnu-4.1.2 *Code:binutils-config -l powerpc-unknown-linux-gnu-2.17 *Code:minerva ~ # as -vGNU assembler version 2.17 (powerpc-unknown-linux-gnu) using BFD version 2.17

author: hendorog
author_rank: Super Contributor
timestamp: April 02, 2016, 09:17:47 pm
content: Quote from: Howardlong on April 02, 2016, 09:01:53 pmRetaining backwards compatibility hinders progress.Retaining backwards compatibility is a noble goal. But the cost is additional complexity for every change which has to maintain it. Over time that complexity grows. There comes a time when a line must be drawn and the old code removed.It's easy to blame the programmers, but they are doing it for a good reason.Quote from: Howardlong on April 02, 2016, 09:01:53 pmI'm sure you have noticed that the number of pedals are different in an automatic cf a manual.

author: apelly
author_rank: Unknown
timestamp: April 02, 2016, 09:39:13 pm
content: Quote from: mikerj on April 02, 2016, 07:27:32 pmFTFYmikerj, nobody is forced to use linux. Please use whatever operating system you would like.The OP clearly has the wherewithal to deal with his situation and is sharing his frustration for our entertainment. Thanks mate. I feel your pain.

author: Howardlong
author_rank: Super Contributor
timestamp: April 02, 2016, 09:45:12 pm
content: Quote from: hendorog on April 02, 2016, 09:17:47 pmIndeed, however there is a balance. One problem is that there is a mentality in the industry to change things for the sake of it but not think about the ramifications.For example, recently the Raspberry Pi Linux build changed the way the IP address configuration is done. This rendered, and continues to render, thousands of helpful online documents to the gutter. I don't know why the change was made, and it took quite some time to find any documentation related to it. I am sure whoever was behind it was well meaning, but failed to understand the wider implications.Key is up to date documentation. As a further example, the Red Pitaya reworked their distro last Septempber rendering much their entire wiki useless. They have still not updated it.As I said before, the average half life of Linux documentation is barely a few weeks: compare that to similar applications in other OSes. It is particularly acute within Linux as there is little if any coordination between developers of disparate components and dependancies. It is left to the end user to figure it out when it breaks. That is THE key problem of adoption of Linux to the desktop: the end user still needs those "special Penguin skills" as Dave calls them so it remains largely a tinkerer's delight.QuoteIndeed, and they are backwards compatible.

author: janoc
author_rank: Super Contributor
timestamp: April 02, 2016, 10:00:35 pm
content: Quote from: Howardlong on April 02, 2016, 09:01:53 pmHoward, I do wonder how did people manage to drive beforehttp://www.modelt.ca/drive.html:QuoteAnd that was probably the most popular car in its time. By your logic we should still be using that scheme otherwise all those driving manuals and driving school textbook would need to be rewritten!Quote from: HowardlongYou are assuming that the change was done for the change's sake and not for some other reason (which you are ignorant about by your own admission). I am not sure what you are referring to, though. I was setting up a Raspberry Pi 3 with the latest Raspbian last week and the IP address is still set up in /etc/network/interfaces, as it always was in Debian.If every change had to consider the tons of books and documentation written on the subject that would become obsolete, we would never get anywhere. That's a ridiculous proposition. The right way is to press the vendors to actually update the documentation, not to forbid making changes!In the case of free products, like Debian Linux (which Raspbian on RasPi is derived from) - it is up to everyone to contribute. People are forgetting that many (not all) of these projects are running only thanks to unpaid labor of volunteers who keep the distributions going and write the documentation.Not everyone is a programmer, but most people can read and write. If you don't like some documentation being out of date, what prevents you from spending a few hours and updating the relevant bit? That will certainly not ruin you and others, who come after you, will be grateful for saving their time. If you don't want to do that, go to a commercial vendor like RedHat or SuSE, get a support contract and then you can unload on them should something be out of date or not working to your satisfaction - because you are paying for it. But whining about a free product that others prepared for you is really cheap.

author: Howardlong
author_rank: Super Contributor
timestamp: April 02, 2016, 10:25:49 pm
content: Quote from: janoc on April 02, 2016, 10:00:35 pmIndeed, I remember as a child reading the owner manual for a Hillman Imp about 45 years ago and thinking even then that if you need this information you probably shouldn't be driving a car.

author: elgonzo
author_rank: Unknown
timestamp: April 02, 2016, 10:33:43 pm
content: Lol, it is perhaps just me, but i feel not all talking here about backward compatibility arerealsoftware developers...Whether keeping a "thing" backwards compatible (doesn't matter if it is in the context of runtime environment or development framework) is useful and beneficial or counter-productive and costly depends entirely on the "thing" itself and the overall situation regarding this "thing" (including, but not limited to, how widely the "thing" is used, how many other "things" depend on that "thing", the severity of the disadvantages/problems exhibited by that "thing", the costs and pain of migrating away from that "thing", ...).Like many things, whether to keep something backwards compatible is a decision that, when chosen properly, more often than not falls somewhere in the gray area between the black and white of "backwards compatibility is bad" vs. "backwards compatibility is good".Backwards compatibility hinders progress as much as two magnets repel each other.Wait, two magnets attract each other.No, they repel each other.You have obviously no clue. All magnets i have are attracting each other. Idiot...Anyway, don't let yourself be distracted by my rambling. Keep arguing

author: nctnico
author_rank: Super Contributor
timestamp: April 02, 2016, 10:38:49 pm
content: @Elgonzo: spoken like a true programmer indeed and like most programmers also totally oblivious to the problems and costs something not-backwards compatible causes for the people who have to apply / maintain it in the field.

author: elgonzo
author_rank: Unknown
timestamp: April 02, 2016, 10:41:52 pm
content: Quote from: nctnico on April 02, 2016, 10:38:49 pmDidn't i mention something about "costs and pain", or was that just a dream?

author: hendorog
author_rank: Super Contributor
timestamp: April 02, 2016, 11:37:53 pm
content: Quote from: nctnico on April 02, 2016, 10:38:49 pmAnd sometimes the users are totally oblivious to the costs and problems maintaining backwards compatibility incurs on the project.Sometimes tough decisions have to be made in the name of progress. e.g. Microsoft abandoned support for XP despite it still having millions of users worldwide.Here is MS posting about removing 220000 lines of code and 300 API's - from your perspective is that a good thing or a bad thing??https://blogs.windows.com/msedgedev/2015/05/06/a-break-from-the-past-part-2-saying-goodbye-to-activex-vbscript-attachevent/Of course everyone knows ActiveX is a bad thing - but try telling that to the people who are depending upon it...

author: Howardlong
author_rank: Super Contributor
timestamp: April 03, 2016, 12:10:33 am
content: Quote from: janoc on April 02, 2016, 10:00:35 pmFirst, to be clear, I wasn't whining. I was making a statement of fact. The half life of Linux-based software documentation is small when compared to that of other OSes.If I make something for someone else to use then I document it for their use. Without that documentation, the job is not finished. If you think you are a programmer making stuff for others to use, and documentation does not apply to you, then you are not a programmer, paid or not. You may think you are shit hot at coding something up, but if you don't communicate what you've done or how to use it, then no, you are not a programmer, you are a bedroom tinkerer. If you don't want to document and justify your changes, then you should think very carefully about the impact of your actions before distributing your work and deprecating older works.Regarding the RPi's change of the way the network interface is used, I refer you to this.https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=111709Now, look up on google "static IP address Raspberry Pi" and practically everything points you to methods that no longer work, nine months after the new "feature" was added. I am giving this as an example of where you need those special Penguin skills, which include being very patient, accepting that things break unexpectedly, enjoy tinkering, and having plenty of time on your hands, and own industrial scale rabbit hole digging equipment.Yes, you need those skills with other OSes, but last time I checked, irritating as Windows is (and God do I hate the way that UI is continually messed with) some well meaning fairy godmother doesn't come over and mess about randomly with fundamental configuration files without making it very clear. After all, why would anyone want a dhcp client messing with an explictly defined static IP address setting exactly?So I am not complaining, I am simply stating that you don't really get something for nothing when you buy Linux, the cost is your time honing your Penguin skills. It's also one reason why Linux admins currently demand the highest salaries, because of their special Penguin skills. The OS might be cheap but the people managing them, not so much.

author: Nerull
author_rank: Frequent Contributor
timestamp: April 03, 2016, 12:17:58 am
content: As someone who has been using linux for 15 years, the best way to use linux is to ignore linux users.As a community, Linux is essentially a cargo cult. The loudest users are those who use it purely to be "cool". They don't know how it works, they don't understand it, but they love to brag about using it. These people will pour into any thread about linux and give lots of unhelpful condescending replies, to cover up the fact that they know even less about the problem than you do.The root of your problem is that, especially in the 2.x era, GCC and the kernel are very closely linked. If you tried to build with the wrong version, you would be lucky if it built at all, and if it did the chances of it not panicking were slim. It was common practice in those days for distros to include a "modern" build of GCC for normal compiling, and a special older version of GCC for building the kernel and modules. Add in several years of chances since then, and you've got a nightmare on your hands. Using a known-good toolchain from the time that kernel was released is really the only answer, unless you want to do a lot of porting.

author: Earendil
author_rank: Regular Contributor
timestamp: April 03, 2016, 01:12:38 am
content: Those who talk about backward compatibility doesn't realize that software is far more complex than electronics.Writing the Linux kernel for example would take far more than a lifetime for a single person. Any large software project is beyond the comprehension of any single engineer. Also software (including design requirements) changes far more often than electronics.Backward compatibility therefore is a huge effort that significantly slows down development. Most open source developers are simply not interested in spending huge efforts to support legacy software.You can always pay a commercial company huge sums of money for their supported commercial operating system; or you can buy support for open source software; no one stops you doing that. On other hand if you don't do that than please stop whining and consider that lot of the software that you criticize was written by someone in his/her free time for free. And besides in this specific case compatibility was broken to make it possible to develop new features for the software.

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 03, 2016, 02:39:15 am
content: Quote from: Nerull on April 03, 2016, 12:17:58 am+1, +10, +100...

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 03, 2016, 02:54:41 am
content: Quote from: Earendil on April 03, 2016, 01:12:38 amhe'll never understand his own code and probably he will never see the light of truth, ever. thats why lee nucks is still a no go for me even after its many many years of continual development. apart from other trivial and non-trivial reasons. one of the new reason i realized is that... lee nucks lovers are the "command line" lovers (keen programmer alike or in fact a programmer). i was that, until the present day provide me with more and more productive tools that "command line" is almost not necessary anymore. i dont understand the idea of "text readable" this and that, or "command line" this and that argument in lee nucks. as far as i understand it, all that can be done in Windows if one want to..ps: i'm not a Windows worshipper either, i will run what gave me the least problem, ie still... the older Windows. the most issues with newer Windows is performance of bloated Windows features that probably i'll never use. i'm not sure what technologies or features bloat lee nucks (PC) has to offer, i'm guessing it struggles to provide what others (leading edge) have published leaving the compatibility issue as is (or "as was"), or just maybe this is inherent to the lee nucks architecture from the beginning i dont know.

author: Howardlong
author_rank: Super Contributor
timestamp: April 03, 2016, 06:03:41 am
content: Quote from: Earendil on April 03, 2016, 01:12:38 amBeen doing both software and electronics since the 70s me old son! I fully realise how complex software is, and it isn't getting any better, and one of the reasons is that well-meaning individuals add "stuff" without sufficient justification. Just look at all the languages and derivatives coming out of the woodwork these days. They can't all survive, most will just create more and more entropy and noise, and die.QuoteYou see, we agree, nowadays it is not possible for an individual to be able to fully understand some systems on their own. But introducing yet more changes unnecessarily only makes that worse. Programmers love to change stuff, I know I do, things can always be done better in a programmer's utopian miniworld. But they also need to be mindful of the effect that has on the greater community.Design requirements may change but that doesn't mean you have to throw the baby out with the bath water.QuoteYou're over playing the amount of effort. How much effort do you think it is for your end users to adapt and re-build and fix their environments every few weeks because someone woke up one day and decided to deprecate something on a whim because they thought they could do it better? That costs a *lot* more.QuoteWhich is the problem. They want to be continually tinkering at the expense of the end user.QuoteAs I said, I wasn't whining, I was making a statement of fact which you've further confirmed, that there is a trend among open source deveopers to build what they think are bigger and brighter things at the expense of existing functionality, with little consideration on the impact to end users. My point is that the balance in the Linux world is skewed too far in this direction, and as such makes it a turn off for your average end user.

author: f1rmb
author_rank: Regular Contributor
timestamp: April 03, 2016, 06:13:17 am
content: Quote from: Howardlong on April 03, 2016, 06:03:41 amErrrrrr, excuse me, but is "end user" have to deal with software compilation? Do any Windows user recompile their Microsoft Office, LibreOffice, Windows kernel, whatever. The same apply to OS-X, and even Linux. End users install binaries, period.The starting point was "why in the hell I cannot use prehistoric code with today tools".Cheers---Daniel

author: Howardlong
author_rank: Super Contributor
timestamp: April 03, 2016, 06:17:15 am
content: I was referring to "end user" in the general sense. If I write a library for example, then the end user might be another programmer.

author: f1rmb
author_rank: Regular Contributor
timestamp: April 03, 2016, 06:27:44 am
content: Quote from: Howardlong on April 03, 2016, 06:17:15 amOkay.Well, and if you break the API of your library, for any reason (security, cleanup, nonsense, name it), it's up to the dev to update his code to comply with yours changes. If he don't want to, it's his problem, not yours.Backward compatibility is just utopia. You can maintain it for a while, but one day you can't anymore, because things evolves or new features should be added, or devs find a nicer and cleaner API. You cannot leave 2 or 3 (or more) pretty similar functions because of backward compatibility, at a given time it become totally unmaintainable, and will confuse the new devs who want to use your library.Cheers.---Daniel

author: Howardlong
author_rank: Super Contributor
timestamp: April 03, 2016, 06:39:42 am
content: Quote from: f1rmb on April 03, 2016, 06:27:44 amAnd what of your end users? How frequently do you want to change your "stuff" rendering it incompatible for others?There is absolutely nothing utopian about wanting to maintain backwards compatibility within reason, it's common sense.Doesn't it irritate you when you go into your supermarket and they switched the shelves around every few weeks? Some supermarkets have either reduced the frequency or stopped engaging in this practice because they found it was counter productive, pissing off and disenfranchising their customers.Again, my point is thatthe right balancebetween backwards compatibility and tinkerers deprecating things hasn't been struck in Linux.

author: f1rmb
author_rank: Regular Contributor
timestamp: April 03, 2016, 06:47:43 am
content: Quote from: Howardlong on April 03, 2016, 06:39:42 amSupermarket are commercial companies, GNU softwares, Linux and softwares I wrote aren't.And this happen also all the time with commercial softwares, one day a major version is released, and it's purely not compatible with the previous one.For API, when a breakage is planified, you start to release your API with some functions tagged as deprecated.This is how the dev world works, like it or not---Daniel

author: Howardlong
author_rank: Super Contributor
timestamp: April 03, 2016, 07:44:38 am
content: f1rmb:QuoteThat is not how the dev works works if you want to make a living out of it, I can assure you! There is nothing utopian about wanting a reasonable level of backwards compatibility, it's common sense.As I said, I've been at this since the 70s, I know exactly how it works, and the dev world you describe isn't mine.My point is and always has been thatthere is a balanceand Linux on the desktop is often too chaotic due to too many well meaning changes without regard to the effect on end users.If you don't care at all about backwards compatibility, as you've stated ("Backward compatibility is just utopia") then that's fine, but that isn't what real programmers, designers and architects do, all you're doing is tinkering.In the end, it sounds like you are actually arguing my case and we are agreeing that Linux tends to deprecate things and renders documentation out of date more rapidly than paid-for solutions, something else I've been saying all along.

author: f1rmb
author_rank: Regular Contributor
timestamp: April 03, 2016, 08:44:48 am
content: Quote from: Howardlong on April 03, 2016, 07:44:38 amFor me, it looks like you've never get involved in OSS dev at all.Software (software, libraries) versioning is used, you cannot break API between minor versions.If you introduce an API breakage, the major version should be increased.About the documentation, dev find that boring, I know. In OSS projects, it's quite rare to get people dedicated to documentation, and devs prefer to focus on the code itself. But there are solutions, like doxygen (I use it intensively, since it extracts and build the documention from sources).But you know, everything in this world evoles, and become backwards incompatible. Look, humans aren't backwards compatible themselves (can you imagine surviving in the prehistoric era ? Will you blame your ancestors for this ? I guess not).As software point of view, it's the same problem; if you design a software that supports some kind of existing hardware devices, one day a new device will be created and it will turns out that you cannot add its support without introducing huge changes in your software. The dilemna is, should I just ignore this device, (and let some other dev create a similar software than yours, supporting the new device and the next ones), or should I made the needed changes, even if it breaks the backwards compatibilty ?This is why I think backwards compatibility (at any price) is utopia. For sure, backwards compatibility breakage should be used ONLY when it's really necessary, but sometimes you have no other choice (and as a programmer point of view, it's always painful to change everything, rewriting working code, and so on). And for your information, I'm also living out the software I write.So, the evolution leaves two choices: be part of it (with its side effects), or die. The perfection doesn't exists.---Daniel

author: legacy
author_rank: Super Contributor
timestamp: April 03, 2016, 11:42:23 am
content: Quote from: Howardlong on April 03, 2016, 07:44:38 amI agree

author: Earendil
author_rank: Regular Contributor
timestamp: April 03, 2016, 12:56:00 pm
content: Quote from: Howardlong on April 03, 2016, 06:03:41 amActually I tend to find that the most bright and knowledgeable professional software engineers prefer Linux as a development environment over Windows. Those of us who actually make a living developing large-scale (multi-millions of lines) software systems understand the limitations and benefits of Linux. I agree that the average clueless occasional programmer ("end user" in this case) should use Windows and Visual Studio or other commercial IDE. It's not a loss for the open-source world. We instead prefer to focus on cutting edge new technology.It's a bit like those Windows based high-end oscilloscopes. They're designed to fulfill a specific need. They might not be pretty or very usable for day to day work but do serve a purpose in the hands of professionals.

author: legacy
author_rank: Super Contributor
timestamp: April 03, 2016, 01:20:16 pm
content: Quote from: Earendil on April 03, 2016, 12:56:00 pmumm, I think those products are good because of the software the can run, e.g. matlab, lab view, ...things that cannot run on linux

author: Howardlong
author_rank: Super Contributor
timestamp: April 03, 2016, 01:40:07 pm
content: Quote from: Earendil on April 03, 2016, 12:56:00 pmBetween yourself and f1rmb you've summed it up perfectly, but also added a further facet in that you don't care about your end users, and even hold them in contempt, which is rather at odds with your claim that you "make a living" from it.So in short, as I understand it, developing OSS is about:O tinkering with new stuff only because the old stuff has no value or interest to you;O changing stuff with little or no consideration for the implications;O no peer review;O not documenting changes appropriately for your end users;O breaking what worked before;O holding your end users and consumers in contempt.Thankfully, I think we're all pretty much in agreement then

author: f1rmb
author_rank: Regular Contributor
timestamp: April 03, 2016, 02:08:01 pm
content: Quote from: Howardlong on April 03, 2016, 01:40:07 pm"When the sage points at the moon, the fool looks at his finger."You just look really decided to not read (I don't even mention understand) explanations that people gave you...Sorry, I've no more free time for you, I'm busy tuning some APIs with my chainsaw ATM.---Daniel

author: legacy
author_rank: Super Contributor
timestamp: April 03, 2016, 03:36:07 pm
content: kernel 2.6.26: 219 mixed implicit and normal rules & deprecated syntaxinteresting

author: MT
author_rank: Super Contributor
timestamp: April 03, 2016, 03:40:00 pm
content: I use so old win software's and computer hardware i have problems being "forward" compatible! Microsoft tells me to upgrade everything all the time, i just turn that annoyance OFF!.

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 03, 2016, 03:46:15 pm
content: Quote from: Earendil on April 03, 2016, 12:56:00 pmi think you are correct there... as a "development environment". a big "built in OS" (with probably a big whole Visual Studio) IDE. maybe to avoid confusion, may we change the term from "Linux OS" to "Linux IDE"?http://www.extropia.com/tutorials/misc/opensourcebiz.html"generating profit from product's halos"linux server, linux smartphone etc etc... people are buying server space and a smartphone, not directly the "linux OS". just like a stink programmer profiting from a Software that run in Windows (people are buying software), the product halo of Ms Visual Studio. thats what i understand.Quote from: Earendil on April 03, 2016, 12:56:00 pmi just wonder is there a succesfull linux DSO? google says none.Quote from: Earendil on April 03, 2016, 12:56:00 pmmaybe you are a server or website engineer? or a smartphone designer? care to mention the "multi-millions of lines"? even though we are bunch of non-potential customers.Quote from: Earendil on April 03, 2016, 12:56:00 pmwhat cutting edge technology? i believe its not directly related to an OS or software development "topology", is it?. maybe you are NASA engineer working on a cutting edge space ship, but its just a linux's halo. but if the engineer switch to Windows next year, then the space ship will become instantaneously a Window's halo. is that what you mean "cutting edge"?otoh, Windows per se, is a family and individual's (incl software programmers that run directly in it) OS where they can enjoy directly or indirectly (indirectly just as in linux business model above). and for multi-billions lines of non-technical (OS-blind) profitiers, small private companies that dealt with services or products thats not requiring an OS in it, requiring many devices connected to the OS and be compatible and supported in many years to come without the hassle of recompiling drivers. one may not be a multi-millions business but... one doesnt have to be a programmer/system guru to make the small profit, directly or indirecly. "Backward compatibility is just utopia"? no its not, esp if one has spent multi thousands of equipments (peripherals connected to an OS). and a stink programmer may survive in Windows, i'm not sure in linux.

author: jancumps
author_rank: Unknown
timestamp: April 03, 2016, 04:00:16 pm
content: Quote from: Mechatrommer on April 03, 2016, 03:46:15 pmYou've got us all silenced there, with a very strong argument.

author: legacy
author_rank: Super Contributor
timestamp: April 03, 2016, 04:00:56 pm
content: Code:BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.%PHONY += $(BOOT_TARGETS)boot := arch/$(ARCH)/boot$(BOOT_TARGETS): vmlinux$(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@)the above was perfectly working with make.2008while make.2016 says that it's deprecatedand "$(BOOT_TARGETS)" is expanded into a LIST[]this un-evolving make: it really makes sense

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 03, 2016, 04:22:03 pm
content: Quote from: legacy on April 03, 2016, 04:00:56 pmactually what this thread is about? a linux hate? or a linux help me fix? you said in the title its fixed.Quote from: Earendil on April 03, 2016, 04:13:54 pmdont get us wrong, we do. google android is the biggest thing. and many more "delusive non-accessible" to mortal companies. but what makes linux being outnumbered is because many of these non-os-techies mortals, that is if, we are talking about PC. for smartphone for eg, its the other way around, i believe. thanks to Samsung.

author: Howardlong
author_rank: Super Contributor
timestamp: April 03, 2016, 04:48:48 pm
content: Quote from: Earendil on April 03, 2016, 04:13:54 pmIndeed, and I certainly don't disagree with you. What you may not know is I too work in enterprise level software and have done for over 25 years in the finance sector principally designing and troubleshooting trading systems based in London either in the City or out at Canary Wharf (if I have to!) You may well use some of my software, and interface with one of the numerous systems I've architected or fixed over the years, I don't know. I may well use some of yours.These days you pretty much have to have your toes in all waters. To blindly close your mind to technologies is not going to help you, you must be open minded. What this has shown me has confirmed in black and white what I was stating, I'm sorry you don't like the conclusion, but software where I come from is not design by tail-wagging-the-dog, it is business driven.I'll continue to remain using the main OSes as I have done for many years. In the enterprise where systems integration is everything, you simply can't have things being deprecated on a whim, everything is standards-based, even of some of those standards are proprietary, if you work in that field I am absolutely certain you'll agree.

author: legacy
author_rank: Super Contributor
timestamp: April 03, 2016, 05:09:47 pm
content: Quote from: Mechatrommer on April 03, 2016, 04:22:03 pmI am able to provide two solutions to my customer, in order to support this "sand point" boardboth of them are limited to kernel 2.6.19 and gcc v4.1.2everything else is NOT working and/or it needs more effort and timein short, I am fine, thanksI was just commenting how crazy are these tools by GNU (make? gcc?)and how chaotic are the linux sources

author: Karel
author_rank: Super Contributor
timestamp: April 03, 2016, 05:28:44 pm
content: Quote from: legacy on April 03, 2016, 05:09:47 pmThey are so chaotic that no manufacturer wants to use it, not in their smartphones, not in their televisions,not in their wifi-routers, not in their super computers, not in their navigation systems,not in their ...

author: Earendil
author_rank: Regular Contributor
timestamp: April 03, 2016, 05:47:37 pm
content: Quote from: Howardlong on April 03, 2016, 04:48:48 pmYou're stating the obvious.

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 03, 2016, 05:55:46 pm
content: Quote from: legacy on April 03, 2016, 05:09:47 pmso the solution is not to upgrade? thats understandable. i'm not saying linux specific, the rule hold with windows, want a stable platform? dont upgrade. specialty devices such as smartphones, televisions, wifi-routers, super computers, navigation systems are like that, not an OS-upgradable device without hassle. i guess my PC is a specialty device, but unlike the other specialty devices, my PC is subjected to OS-obsoletion-damnation. but i believe with an upgrade including the latest, i can still use most of my peripherals, if not all. as i beginning to get new peripherals that is Win10 approved but also still compatible with my current XP.

author: legacy
author_rank: Super Contributor
timestamp: April 03, 2016, 06:20:13 pm
content: Quote from: Mechatrommer on April 03, 2016, 05:55:46 pmI "might" upgrade to kernel 3.* or kernel 4.*, but it will require more time than the budget that my customer has allocated.time and effort is the problem I haveI mean I have adeadline, and I have tofix the hardware, I have to complete a PCI-FPGA board, there is mistake in the PSU sectionfix the VHDL code, because my customer wants a customizationfix the firmware, because DINK32 (made by Freescale) has a bug, which limits the amount of (soldered) ram to the halffix the rootfs, because my customer wants uclibc instead of glibcfix the kernel module, it creates a bridge between the userspace (/dev/fpga) and the hardwareadd a few examples to show my customer how he should use the fpgaprovide a working toolchain, able to cross compile everything for the target (including the linux-kernel)all of these steps MUST be completed for the end of the next week, thus I have no time to care about "linux" and "gcc"upgrading and supporting kernel > 2.6.19 requires TOO MUCH effortI can allocate such an activity ONLY if my customer will allocate a budget for that

author: Karel
author_rank: Super Contributor
timestamp: April 03, 2016, 06:34:14 pm
content: Quote from: legacy on April 03, 2016, 06:20:13 pmNot the fault of Linux. Blame yourself for accepting a job with such deadlines.

author: legacy
author_rank: Super Contributor
timestamp: April 03, 2016, 07:23:06 pm
content: Quote from: Mechatrommer on April 03, 2016, 05:55:46 pmyes, there is also another motivation, confirmed to me by the last build-up I have experimented 5 minutes agoUnfortunately everything > 2.6.23 has no support and comes into the problem of enabling the mmu.Thesandpointneeds a special BSP, otherwise, after the initial boot, part of the Linux finishes setting up BATs and enables the mmu the address translation is not done properly, thus, when the kernel jumps to 0xC0000000, it jumps to physical address 0xC0000000, and it crashes there.This special BoardSupportPackage (which depends on DINK32) is very hard to be forwarded from 2.4.* to 2.6, and from 2.6.19 to > 2.6.23I can fix it, but … I suspect it will take 4-5 working days (or 2 weeks), also my BDI2000 with Codewarrior does not support mmu.

author: nctnico
author_rank: Super Contributor
timestamp: April 03, 2016, 07:44:07 pm
content: Quote from: f1rmb on April 03, 2016, 06:27:44 amYou can always apply bugs-causing-crashes and security fixes to older versions. This is easy if you use a version control system where you can push changes between versions. WxWidgets for example can be compiled for supporting various versions (and buggyness levels) of the API so old code which relies on certain workarounds keeps working. As Legacy already wrote changing to a newer version of a library is likely to trigger upgrades in several other parts of the system which turns a small change into a huge project. You really can't sell it to a client that adding a simple extra feature needs a complete overhaul + re-testing of the software which costs them tens of thousands of dollars.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: April 03, 2016, 07:54:46 pm
content: Quote from: Karel on April 03, 2016, 06:34:14 pmYou are displacing the problem. If the customer were billed for doing all of the work and taking the time to do this it would be the customer complaining about the expense, and if the customer had an itemized bill they would be complaining about Linux.This dedication to obsolescence is unique to software and electronics. Even though it is a suboptimal design the edison base for light bulbs has survived transition through CFL and onto LED. Can't you just imagine the response of the world if they were told that all of their lamps and fixtures were deprecated. (It is certainly possible that such deprecation would have been desirable for technical reasons. Think of the possibilities. Heat sinking. Color temperature setting. Improved safety.....) That they were just whining when they complained about the cost of replacement.

author: janoc
author_rank: Super Contributor
timestamp: April 03, 2016, 08:17:29 pm
content: Quote from: legacy on April 03, 2016, 01:20:16 pmBoth Matlab and Labview run on Linux quite happily.

author: janoc
author_rank: Super Contributor
timestamp: April 03, 2016, 08:33:25 pm
content: Quote from: Howardlong on April 03, 2016, 01:40:07 pmHoward, that only shows that you have no clue whatsoever about the subject, only offensive prejudiced assumptions."tinkering with new stuff only because the old stuff has no value or interest to you;"I am contributing to the VRPN project, which keeps a lot of old virtual reality hardware usable and running, beyond the support of their commercial vendors. That thing is a 15 years old project. I am also occasionally contributing to OpenSceneGraph - this is a project that goes to huge pains to keep working even on ancient systems like SGI Irix, because there are still users who need that."changing stuff with little or no consideration for the implications;"This is has been discussed ad nauseam above."no peer review;"You are kidding, right? Many open source projects are infamous for their strict peer review and getting code accepted requires jumping some pretty high bars. Linux kernel is pretty well known for this - along with the development culture that makes newcomers often cry because people don't hesitate to point out to you that you are a moron if you do something dumb."not documenting changes appropriately for your end users;"That's just not true, even though in some cases the documentation could certainly be improved. Have you seen the changelogs for example on Mozilla Firefox or, again, each release of Linux kernel? Look here:http://kernelnewbies.org/LinuxChangesYou can even click through to the individual patches that have introduced those changes and see the corresponding code.Show me something even close in a commercial world - e.g. with Microsoft's patches we have to be happy with "KBXXXXX - Important security fix" or "Safety-critical update". Good luck figuring out what it will do when you install it."breaking what worked before;"That's just restating of what you wrote before."holding your end users and consumers in contempt."So by a few immature yahoos in a forum that are often not even associated with the project in question in any way (they are users at best) you smear the entire ecosystem. Lovely, isn't it?With all due respect to your experience and age, I think you are massively out of your field here.

author: janoc
author_rank: Super Contributor
timestamp: April 03, 2016, 08:36:12 pm
content: Quote from: CatalinaWOW on April 03, 2016, 07:54:46 pmKarel is a known troll, just look at the FTDI thread ...

author: janoc
author_rank: Super Contributor
timestamp: April 03, 2016, 08:39:40 pm
content: Quote from: legacy on April 03, 2016, 06:20:13 pmI would say that in such situation don't bother upgrading. Keep the version you have working and fix the other issues first. Upgrading to a newer kernel is a "nice-have" feature in this case, IMO. If the client wants newer kernel, they should pay for that work - or do it themselves.Porting drivers between major kernel releases is a huge effort if the driver wasn't maintained for a long time.

author: Howardlong
author_rank: Super Contributor
timestamp: April 03, 2016, 08:41:59 pm
content: Quote from: Earendil on April 03, 2016, 05:47:37 pmI thought so too, but I am not quite how that fits with the apparently accepted mantra demonstrated here of OSS developers where design is by lots of tail wagging and little if any concern for the business (ie, end users).Thing is I know not all developers of OSS are like that, and it would be unfair to tar all with that brush. I've just been more than a little surprised today that there seems to be a badge of honour to discount end users and deprecate so readily, I was expecting a robust defence but instead received a confirmation of what I already suspected!

author: Howardlong
author_rank: Super Contributor
timestamp: April 03, 2016, 08:53:03 pm
content: Quote from: janoc on April 03, 2016, 08:33:25 pmActually, you are right, I think I have been unfair to the greater population, I have just been a bit mindblown by the admittedly limited sample response on this thread. So I apologise to the greater OSS developer population forthwith because I know this is not true across the board. You are right, I have been prejudiced by the responses of a couple of users on this thread, and that should not be, and isn't representative.My original premises remain that the half life of your average bit of Linux documentation is of the order of a few weeks, and that there is a problem of balance in backwards compatibility that is more acute in Linux compared to other mainstream OSes.But I repeat that I was unnecessarily unfair to the general OSS developer community here, it's just that the responses I saw here, such as a balanced approach towards backwards compatibilty being deemed "utopian" rather shocked me. I hope you understand.Edit: typos due to rubbish tablet keyboard

author: Koen
author_rank: Frequent Contributor
timestamp: April 03, 2016, 08:57:35 pm
content: If you don't like the way it's done, if you have better solutions, if you wish to maintain old software, get involved and contribute. Nobody's stopping you from stamping your print in the projects you use.

author: Howardlong
author_rank: Super Contributor
timestamp: April 03, 2016, 09:01:35 pm
content: Quote from: Koen on April 03, 2016, 08:57:35 pmActually, you may not be aware, but I do.

author: Koen
author_rank: Frequent Contributor
timestamp: April 03, 2016, 09:03:45 pm
content: It wasn't directed to you, more of a general conclusion after reading the whole thread.

author: hendorog
author_rank: Super Contributor
timestamp: April 03, 2016, 09:11:07 pm
content: Quote from: Howardlong on April 03, 2016, 08:41:59 pmIt seems to me that the discussion has discounted the role of the distribution vs the role of the developer.My understanding was that the distributions shoulder some of the responsibility for choosing and integrating the tools and maintaining compatibility.The other consideration is that where backwards compatibility is needed badly enough in OSS, it _is_ maintained. For example I recall there was a 2.2 kernel maintained for a long time. You of course also have the option of maintaining it yourself, or paying someone else to do it.I think legacy's criticisms are around the code quality sound quite valid - I wonder if the ppc code gets much love these days?The backward compatibility arguments for an esoteric platform over nearly 10 years, not so much.

author: nctnico
author_rank: Super Contributor
timestamp: April 03, 2016, 09:23:33 pm
content: I have to agree with Howardlong that using Linux or developing & maintaining a software product for Linux is very hard due to ever changing APIs and broken backward compatibility. I have over 15 years of experience with developing with/for Linux. Actually the Linux kernel itself is one of the worse offenders. It is no wonder very few hardware manufacturers bother to offer driver support for Linux because it is just too much work to keep up with the changes in the kernel and Xorg.Lack of documentation is a severe problem too. Most parts of the Linux kernel have no comments at all and it is totally unclear how and why things are the way they are. A nice example: at some point the kernel developers removed the reset hook from the kernel shutdown code. However this reset hook is important to set the power management back to default so it can support the default CPU frequency after a reset. This caused problems on several platforms and it is a prime example of why it is so important to document (comment) WHY things are implemented in software. Many seem to think a changelog or some doxygen created crap serves fine as documentation but it is not. Not by a long shot. The most important information for a piece of code is WHY it is there.You also see it when manufacturers of SoCs try and create kernel support for their chips. They never get it quite right because the underlying API is not documented properly. When doing a project based on a SoC I have not used before I usually reserve around 150 hours for ironing out Linux kernel bugs.

author: Earendil
author_rank: Regular Contributor
timestamp: April 03, 2016, 09:49:57 pm
content: Quote from: nctnico on April 03, 2016, 09:23:33 pmAnd have you considered that there's a reason to this? Like developing a tons of features? Or multiplying the number of users by orders of magnitude?

author: legacy
author_rank: Super Contributor
timestamp: April 03, 2016, 10:19:44 pm
content: Quote from: hendorog on April 03, 2016, 09:11:07 pmumm, as far as i see, it seems that the x86 & arm code get much more love these days

author: nctnico
author_rank: Super Contributor
timestamp: April 03, 2016, 10:21:17 pm
content: Quote from: Earendil on April 03, 2016, 09:49:57 pmI call it lack of looking forward & planning ahead. One of the things I encountered a long time ago was the enumeration of the PCI slots or cards (I forgot) changing from an integer to a string between a minor release in a stable kernel. Ofcourse that broke something else! IOW: everything will be an afterthought without planning and defining APIs first.

author: janoc
author_rank: Super Contributor
timestamp: April 03, 2016, 10:30:13 pm
content: Quote from: Howardlong on April 03, 2016, 08:53:03 pmThe problem is that you are comparing things that just aren't comparable and projecting your erroneous assumptions there. Windows XP was on the market for almost 10 years. That is a single Windows version being around for more than the total time of existence of many projects! It took Microsoft almost 10 years to actually produce a sensible next version which got adopted by the users - Windows 7. So this isn't so much about the mainstream OSes intentionally staying compatible but the inability of Microsoft to move faster (and not for lack of trying!). In contrast to that, Linux kernel has a major release about once a year, most Linux distributions have a new version once or twice a year (I assume you know that there isn't a single "Linux" but many which differ in certain things). Windows XP was pretty much an anomaly in this regard.Actually Microsoft has now moved to a rolling release system with Windows 10 which is even less stable than the 2 major releases/year that many Linux distributions use. So you have several versions of Windows 10 around which differ quite significantly depending on which patches have been or have not been installed, even though they all share the same version number. Talk about chaos!If you take Mac OS X, you will discover that there is a major release about once a year and every release breaks some things for developers (and to lesser degree users). The same for Android or iOS, which are major players among the mobile systems. So this supposed longevity in mainstream software that is supposedly lacking in open source projects just isn't really there.You are quoting one single anecdotal piece of evidence because you got unlucky and managed to find that single piece that has apparently changed between versions. Try to find how to fix e.g. screensaver not starting correctly in Windows 10 - a problem I was trying to solve recently after upgrading from Windows 7 at work, because Win10 is completely happy to keep the screen unlocked for anyone to do anything with the machine if you forget to hit WIN+L to lock it manually. When you filter out the "helpful" responses that on modern systems you are not supposed to use a screensaver because the screen burn-in is not a problem and you should rather suspend the screen to save energy (i.e. totally missing the point), you will find that the 3/4 of the info is for Windows 7-8 (i.e. not relevant) and the rest that actually concerns Windows 10 talks about using group policy editor and similar tools - which are not available in all Windows 10 versions. And that is a commercial software that one pays quite a bit of money for. I could give you many other such examples.Basically, if you are relying on finding info from 3rdparty sources - websites, forums, mailing lists, you can't assume it is accurate - and that is the same story regardless of which system you are using.

author: janoc
author_rank: Super Contributor
timestamp: April 03, 2016, 10:39:54 pm
content: Quote from: nctnico on April 03, 2016, 10:21:17 pmThat's a bit unfair, though. Yes, it is great to say this when you have 20/20 hindsight, but Linux kernel isn't developed by a closed team of engineers working around a single platform where you have the luxury that everything can be planned ahead because you know exactly what you will have to support in the future.That said, I certainly agree that they could manage some things better and breakages like what you described are not fun. Especially the more obscure/less used platforms are in danger of bit rot and breakage, simply by the virtue of too few people maintaining the support for them.On the other hand, if you have workable ideas how to plan for and manage a team of a 1000+ developers working on a single release, from different companies and with different commercial interests, I am sure Linus would want to hear from you. It is a super hard problem and I am surprised that he has got as far with it as he did.

author: legacy
author_rank: Super Contributor
timestamp: April 03, 2016, 10:52:58 pm
content: Quote from: janoc on April 03, 2016, 08:39:40 pmprecisely what I am going to doQuote from: janoc on April 03, 2016, 08:39:40 pmthat is the case: after the kernel version 2.6.24, Motorola removed the supportsince they declared "obsolete" the Sandpoint-x3 74xx line

author: Howardlong
author_rank: Super Contributor
timestamp: April 03, 2016, 11:18:54 pm
content: Janoc: with respect, pretty much every single time I go to something with Linux with a view to figuring out how to integrate something, which is pretty much on a weekly basis, it's the same story I'm afraid. It's just not an isolated case. I gave that one about the RPi as an example people could relate to easily. I could just as easily have told you about the ten days elapsed I spent trying to get a Red Pitaya development environment up and running, or even a blinky on it, but that is such an extreme case it's hardly representative of the normal trials and tribulations I encounter. Most examples are rather more esoteric, I could go into the one about the USB driver in the MIPS version of the kernel that fails to enumerate in certain cases where it incorrectly calculates aggregate bandwidth that I fixed, or the HID API library that broke between distributions that I also fixed. The list is pretty long.While you are right, and I most certainly agree, that Windows (and OSX) are hardly without fault, my point remains that installation and deployment instructions and recipes tend to break more rapidly and become deprecated due to loss of backwards compatibility more in Linux than they do in Windows or OSX. Every deployment seems to be "special" in one form or another, the goal posts are moving about all the time. Not only does every set of instructions you carefully make and test have to specify precise versions of every component that you have, I've learned the hard way over the years that you also need to include a sandboxed way of building those components as before you know it they're lost, nowhere to be seen in the repositories or anywhere else.That is all, it's just an observation I've made again and again, please take it as a piece of constructive criticism that it's meant to be, it's not a personal affront, there is no need for anyone to get defensive about it. I am not saying it's easy, just that this is an observation that is a key reason why Linux has difficulty in gaining traction on the desktop.If it's any consolation, I spent many hours fixing a broken Windows 10 profile a week or so ago on my main development desktop where none of the Tile apps (that I almost never use) worked. Microsoft's recommendation after following half a dozen other useless tips is to reinstall Windows. You can imagine what my response was. In the end I figured it out myself without the reinstall but it took a long time to get there.

author: mikerj
author_rank: Super Contributor
timestamp: April 04, 2016, 12:52:55 am
content: Quote from: janoc on April 03, 2016, 10:30:13 pmYou're saying that like it was a bad thing. I'm no great fan of Microsoft or Apple but neither of them would be in the position they are now if they brought out new releases that broke stuff at the same rate that Linux does. Sure, stuff gets broken occasionally, but fixes are generally easy to find and continue to work years later.As I said before, it's disappointing but hardly surprising that Linux has completely failed to become a mainstream desktop operating system. Sadly it will never be a realistic possibility unless this kind of stupidity is resolved.

author: hendorog
author_rank: Super Contributor
timestamp: April 04, 2016, 04:19:30 am
content: Here is an example of OSX changing like the wind:https://support.apple.com/en-nz/HT202516Interestingly they purchased some emulation software which allowed PPC apps to run on Intel for a while - then they removed that feature, sold the product to IBM who killed it quickly IIRC.

author: f1rmb
author_rank: Regular Contributor
timestamp: April 04, 2016, 06:06:16 am
content: Quote from: nctnico on April 03, 2016, 07:44:07 pmNo enterly true, wxWidgets (aka wxWindows) has already introduced few API breakages by the past.Adding a "simple" needed feature won't necessary introduce an API breakage, where did I wrote that ?"You really can't sell it to a client that adding a simple extra feature needs a complete overhaul + re-testing of the software which costs them tens of thousands of dollars."Really ? Well, let me tell you a secret, Microsoft is doing this for more than 30 years.Well, I think this is my last comment in this thread, many persons are open-minded (and know what they are talking about), but few others are irrecoverable.Cheers.---Daniel

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 04, 2016, 06:21:11 am
content: If ms did it.why were clients buying? Why they didnt other oses?

author: Karel
author_rank: Super Contributor
timestamp: April 04, 2016, 06:34:39 am
content: Quote from: Mechatrommer on April 04, 2016, 06:21:11 amAbuse of monopoly (they are convicted for that) and vendor-lockin.

author: legacy
author_rank: Super Contributor
timestamp: April 04, 2016, 06:45:14 am
content: Quotein my job experience, it sounds like avionics, software product there, make the difference between using loooooonixxxxx or .... rejecting because ... supporting its "wind of change" costs too muche.g. linux costs a lot of human power in order to pass the DO178B level D (I did, and it was the most frustrating experience ever), thus you can't stay in tree

author: legacy
author_rank: Super Contributor
timestamp: April 04, 2016, 06:47:54 am
content: p.s.I like products made byWindRiver, e.g.VxWorkssources andWorkbench(even if … it's Eclipse based)

author: Howardlong
author_rank: Super Contributor
timestamp: April 04, 2016, 07:46:50 am
content: Not wishing to sidetrack the thread from the OP's predicament, this OSS incident happened last weekhttp://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/What's almost as shocking is the quality of the code itself in terms of efficiency at the centre of the storm, pretty much shows how little care some self-proclaimed programmers take!Code:module.exports = leftpad;function leftpad (str, len, ch) {str = String(str);var i = -1;if (!ch && ch !== 0) ch = ' ';len = len - str.length;while (++i < len) {str = ch + str;}return str;}

author: hamster_nz
author_rank: Super Contributor
timestamp: April 04, 2016, 09:49:26 am
content: Quote from: Howardlong on April 04, 2016, 07:46:50 amI don't know Javascript (well, I assume that it is Javascript...) What is so terribly bad about it? Or more to the point, how would it be done better?It seems to do what is asked of it, and unless 'len' is stupidly long it seems to have OK performance. I can see that repeatedly adding a character to the front of the string most likely isn't the most efficient way, but it is Javascript after all, but 5 or 6 passes of the loop isn't going to kill you. It might be more efficient than building a separate string to use to pad the front and then having all the allocation and garbage collection associated with that.(or maybe I can hear a whooshing sound...)

author: hamster_nz
author_rank: Super Contributor
timestamp: April 04, 2016, 10:08:45 am
content: Quote from: wilfred on April 04, 2016, 09:55:22 amOh, yeah, you're right! Maybe I should head back to twitter and see what @nibblerpoop has been up to...

author: tszaboo
author_rank: Super Contributor
timestamp: April 04, 2016, 10:22:22 am
content: I recently also have some new experience with embedded linux. So here it is.The way you do things is just horrid. I have to fish together information from 100 sources, where files are located, how to build something, what to access, dependencies.Bear in mind, we are talking about embedded stuff.The scripts to have the thing working accesses several http locations, downloading the latest and shiniest code.Areyoukiddingme?I downloaded a piece of python code, which was a dependency to the code to run, which accessed the network and downloaded some new code. How is this going to work 5 minutes from now? If any of these links stops working, then I never can make this work again? Are linux people full retard, or they just love the fact that they have to go into the deep shit of error logs and google search it, every time someone breaks something? Real house of cards, that is.When I was developing embedded code, it was easy. Take the libraries you need, commit it on the version control, together with the project and the C code.Linux? Never ending list of commands, where any of those might pop up questions, ask for password, or interrupt any other way, and of course dump some useless information into the terminal, encoded in robot language.Hopefully I can convince them to dump the entire thing into the ocean, and redesign the stuff with some RTOS, where the hardware and software cost is the fraction.

author: nctnico
author_rank: Super Contributor
timestamp: April 04, 2016, 10:28:09 am
content: I think you are referring to one of the embedded build eco-systems like openembedded, buildroot, etc. At least buildroot (and probably all of them) keep a local cache with the downloaded files. So if you backup that you'll always have the exact versions you build your system with. Downloading all the files is just an initial step to pull a complete software package together.

author: Karel
author_rank: Super Contributor
timestamp: April 04, 2016, 10:51:08 am
content: Quote from: Howardlong on April 04, 2016, 07:46:50 amCoverity, a company specializing in software quality and security testing solutions, finds that open source programs tend to have fewer errors than proprietary programs.http://www.zdnet.com/article/coverity-finds-open-source-software-quality-better-than-proprietary-code/

author: legacy
author_rank: Super Contributor
timestamp: April 04, 2016, 11:03:51 am
content: Quote from: NANDBlog on April 04, 2016, 10:22:22 amexactly the feel I have when I say I HATE it

author: legacy
author_rank: Super Contributor
timestamp: April 04, 2016, 11:31:13 am
content: Quote from: legacy on April 04, 2016, 11:03:51 amCode:sakura # mydev all list2. 6 /idp.do/mysrc/lib/lib_basen2_v31. 1 /idp.do/mysrc/lib/lib_bit_set_v14. 5 /idp.do/mysrc/lib/lib_bitmap_v24. 2 /idp.do/mysrc/lib/lib_bitmap_v35. 8 /idp.do/mysrc/lib/lib_cal_stamp_v11. 6 /idp.do/mysrc/lib/lib_debug_v11. 0 /idp.do/mysrc/lib/lib_endian_v212. 1 /idp.do/mysrc/lib/lib_env_collector_mini_v12. 3 /idp.do/mysrc/lib/lib_env_disk_io_v14. 8 /idp.do/mysrc/lib/lib_env_pool_label_v14. 9 /idp.do/mysrc/lib/lib_env_pool_string_v13. 8 /idp.do/mysrc/lib/lib_env_shell_cmd_v11. 3 /idp.do/mysrc/lib/lib_env_toy_v1658. 0 /idp.do/mysrc/lib/lib_env_wrapper_v11. 2 /idp.do/mysrc/lib/lib_fileIO_unix_v12. 0 /idp.do/mysrc/lib/lib_file_utils_v12. 0 /idp.do/mysrc/lib/lib_file_utils_v23. 3 /idp.do/mysrc/lib/lib_filename_filter_v32. 6 /idp.do/mysrc/lib/lib_filename_utils_v82. 2 /idp.do/mysrc/lib/lib_fs_folder_level_v11. 3 /idp.do/mysrc/lib/lib_fs_folder_level_v25. 9 /idp.do/mysrc/lib/lib_lexer_reserved_word_language_l1_show_v7b5. 3 /idp.do/mysrc/lib/lib_lexer_reserved_word_language_l1_v7b1. 8 /idp.do/mysrc/lib/lib_lexer_reserved_word_v7b1. 9 /idp.do/mysrc/lib/lib_lexer_tokenize_v7b8. 5 /idp.do/mysrc/lib/lib_lexer_v7b1. 6 /idp.do/mysrc/lib/lib_linea_v25. 9 /idp.do/mysrc/lib/lib_list_handler_v110. 3 /idp.do/mysrc/lib/lib_mystring_v110. 0 /idp.do/mysrc/lib/lib_mystring_v22. 8 /idp.do/mysrc/lib/lib_net_udp_ip_v11. 0 /idp.do/mysrc/lib/lib_pico_shell_slush_addon_v46. 8 /idp.do/mysrc/lib/lib_pico_shell_slush_v4952. 0 /idp.do/mysrc/lib/lib_pico_shell_toy_v41. 3 /idp.do/mysrc/lib/lib_progress_bar_v2.213. 0 /idp.do/mysrc/lib/lib_queue_gp_v38. 6 /idp.do/mysrc/lib/lib_safestring_v23. 2 /idp.do/mysrc/lib/lib_serial_unix_v33. 5 /idp.do/mysrc/lib/lib_serial_unix_v42. 0 /idp.do/mysrc/lib/lib_string_fuzzy_match_v110. 9 /idp.do/mysrc/lib/lib_tokener_fast_v810. 9 /idp.do/mysrc/lib/lib_tokener_fast_v8b7. 1 /idp.do/mysrc/lib/lib_tokener_fussy_v86. 0 /idp.do/mysrc/lib/lib_tokener_language_show_v15. 2 /idp.do/mysrc/lib/lib_tokener_language_v18. 7 /idp.do/mysrc/lib/lib_tokener_v86. 1 /idp.do/mysrc/lib/lib_uart_unix_v52. 1 /idp.do/mysrc/lib/lib_udpip_v21. 9 /idp.do/mysrc/lib/lib_unix_termio_kb_v24. 4 /idp.do/mysrc/lib/lib_unix_termio_kb_v4Code:sakura # mydev lib_progress_barlast version: v2.2already committed: yes, 2015/12/10, by root@sakuralast access: 2015/12/10test bench: passedstatus: quality compliance untestedsakura # mydev lib_progress_bar_v2.2 list4. 3 Kbyte Makefile4. 1 Kbyte lib_progress_bar.c384. 0 byte lib_progress_bar.h375. 0 byte lib_progress_bar.interface25. 0 byte lib_progress_bar.private4. 0 Kbyte obj4. 0 Kbyte test3. 7 Kbyte test_lib_progress_bar.c204. 0 byte test_lib_progress_bar.interface113. 0 byte test_lib_progress_bar.privateCode:sakura # mylib mk lib_progress_bar_v2.3sakura lib_progress_bar_v2.3 # mylib import from lib_progress_bar_v2.2calling build-project-makefile-v4.2MYINCLUDE={ -I/idp.do/mysrc/lib -I./ }.----------------------------------------------------------------------all_src[]={ lib_progress_bar.c test_lib_progress_bar.c }----------------------------------------------------------------------all_obj[]={ lib_progress_bar.o test_lib_progress_bar.o }----------------------------------------------------------------------all_obx[]={ obj }----------------------------------------------------------------------all_slb[]={ ./lib_progress_bar.c }----------------------------------------------------------------------Code:sakura lib_progress_bar_v2.3 # make clean_all- cleaning interfaces .- cleaning allCode:sakura lib_progress_bar_v2.3 # make interfaces- touching interface private- touching interface public- generating interface private for lib_progress_bar- generating interface private for test_lib_progress_bar- generating interface public for lib_progress_bar- generating interface public for test_lib_progress_barCode:sakura lib_progress_bar_v2.3 # make- compiling lib_progress_bar ... done- compiling test_lib_progress_bar ... done- linking to myCode:sakura lib_progress_bar_v2.3 # make commit- committing ...… doneCode:sakura # mydev lib_progress_barlast version: v2.3already committed: yes, 2016/04/04, by root@sakuralast access: 2016/04/04test bench: untestedstatus: quality compliance untestedI can do it, only for hobby

author: nctnico
author_rank: Super Contributor
timestamp: April 04, 2016, 11:33:24 am
content: I see you build as root? I suppose this is in a sandbox because running cross compilations as root can cause serious damage to your build system if one of the autoconfig files does not behave properly and starts overwriting system files.

author: legacy
author_rank: Super Contributor
timestamp: April 04, 2016, 11:36:53 am
content: Quote from: nctnico on April 04, 2016, 11:33:24 amyes, in a sandbox

author: legacy
author_rank: Super Contributor
timestamp: April 04, 2016, 11:40:08 am
content: (the trick comes from gentoomeanemergeusessandboxesand I have recycled that code)

author: legacy
author_rank: Super Contributor
timestamp: April 04, 2016, 11:55:52 am
content: used in a real complex applicationCode:sakura otaku_v1 # obj/testOtakuhAllo!# helpnew parser kind3 1:1 token_StrictAlphaNum, type21command (2)cmd_help()cmd_list, 50 itemsexit................ - byebye?................... - cmd listhelp................ - show specific cmd helpver................. - versionmy.................. - proof, provided by shell_initidevice............. - swi tap seticlass.............. - swi tap setireg................ - swi tap setget................. - swi tap reg getput................. - swi tap reg putid.................. - swi tap identifyping................ - swi tap pingresync.............. - swi tap resyncopen................ - swi tap openclose............... - swi tap closecon................. - swi tap connecttapS................ - swi tap serverscan................ - swi tap client scanmode................ - swi tap modegrid................ - swi tap gripregs................ - swi tap reg showcv.................. - code viewd1.................. - ncurses demo1d2.................. - ncurses demo2d3.................. - ncurses demo3oo.................. - rom emulator initoc.................. - rom emulator initow.................. - rom emulator writeor.................. - rom emulator readsrec................ - srec to binsl.................. - srec loadans=True# exitbyebyeCode:sakura otaku_v1 # mydev projectinfo: Arise-v2 debug processorclass: appCode:sakura otaku_v1 # mydev project hierarchythe project is composed by the following local sub modules:app_my_dbg_swilib_app_my_dbg_swilib_my_dbg_swi_v5lib_my_dbg_swi_v5/taplib_my_dbg_swi_v5/tap/fsmlib_my_dbg_swi_v5/tap/l1lib_my_dbg_swi_v5/tap/gridlib_my_dbg_swi_v5/tap/protocollib_my_dbg_swi_v5/device/handlerlib_my_dbg_swi_v5/device/lib_net_tcp_ip_v0.2_mylib_my_dbg_swi_v5/device/lib_net_udp_ip_v0.2_mylib_my_dbg_swi_v5/device/lib_net_v2lib_my_dbg_swi_v5/device/lib_uart_obj_v0.2lib_my_dbg_swi_v5/device/tap_devicelib_debugger_code_view_v1lib_debugger_code_view_v1/demolib_debugger_code_view_v1/demo2lib_unix_termio_kb_v4lib_rom_emulator_ostrich2_v1lib_progress_bar_v3lib_srec_to_bin_light_v3Code:sakura otaku_v1 # mydev project libthe project depends on the following committed libraries:lib_pico_shell_slush_v4.olib_pico_shell_slush_addon_v4.olib_pico_shell_toy_v4.olib_tokener_v8.olib_tokener_fast_v8b.olib_tokener_language_Z_v1.olib_tokener_language_Z_show_v1.olib_bitmap_v3.olib_bit_set_v1.olib_basen2_v3.olib_safestring_v2.olib_debug_v1.olib_linea_v2.olib_fileIO_unix_v1.olib_net_udp_ip_v1.oCode:sakura otaku_v1 # mydev project ilibthe project depends on the following OS librariesncursesformpthread

author: legacy
author_rank: Super Contributor
timestamp: April 04, 2016, 02:12:50 pm
content: Quotewhat obsolete part resellers are still offering in business: v2.4.21

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 04, 2016, 02:53:07 pm
content: Quote from: Karel on April 04, 2016, 10:51:08 amsynopsis should also compare open source programs "documentation" and proprietary programs "documentation".

author: nctnico
author_rank: Super Contributor
timestamp: April 04, 2016, 04:52:15 pm
content: Quote from: Mechatrommer on April 04, 2016, 02:53:07 pmBoth will be just as bad. A while ago Microsoft hired they guy behind the sysinternals tools because he is the only one who actually understands how Windows works under the hood.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: April 04, 2016, 05:29:47 pm
content: It is notorious that all programmers suck on documentation. It is interesting that all of the worldwide peer review on open source software does not result in software that is unquestionably better documented than other softwares. The point is not whether it is better or not, just the fact that is debatable speaks volumes.

author: nctnico
author_rank: Super Contributor
timestamp: April 04, 2016, 05:44:49 pm
content: Quote from: CatalinaWOW on April 04, 2016, 05:29:47 pmI think the reason is easy: documenting is boring to many people and it takes time. So it doesn't happen when doing programming for fun and it doesn't happen when on a payroll.

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 04, 2016, 07:42:38 pm
content: Quote from: nctnico on April 04, 2016, 04:52:15 pmi was not talking about code's documentation. i was talking about the documentation of the end product, to the users, not the programmers. and my reply was not about OS documentation, but the gazzillions of "programs" (softwares) out there, since the synopsis survey was on the "programs".

author: hendorog
author_rank: Super Contributor
timestamp: April 04, 2016, 07:48:53 pm
content: Quote from: Mechatrommer on April 04, 2016, 07:42:38 pmMaybe go and have a browse through the gentoo website (The OP's linux distro). You might be surprised.It is stupid to comment on OSS having good or bad documentation. Individual projects will have better or worse docs which has nothing to do with OSS.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: April 05, 2016, 03:41:52 am
content: Quote from: nctnico on April 04, 2016, 05:44:49 pmOf course it isn't fun. Hasn't been fun since my coding course in university when punch cards were the way to enter code. But in open source where hundreds of different people are maintaining code, where people come and go as time and motivation wax and wane you would think that documentation, particularly in the code, would be more important than just about any place else. The usual defense against poorly documented code is to throw it out and start over. That would totally end any argument about the maturity and deep peer review of OS code, including the OS.

author: ade
author_rank: Unknown
timestamp: April 05, 2016, 04:49:16 am
content: Linux is big (big!) business and today its core parts are primarily maintained by professional developers employed by large companies as part of their jobs.E.g., if you look at the kernel, only about 10% of the contributions come from individual developers. 90% from the likes of IBM, Google, Samsung, Texas Instruments, Renesas, etc.Even Microsoft has been embracing Linux and open source (recently they announced SQL Server support for Linux).Similar stats can be derived from other major OSS projects. E.g., Microsoft is now a major contributor to Apache, along with IBM, HP and ARM. Eclipse was developed by IBM and continues to be heavily supported by IBM. They are also a big force behind Node.js with Intel. clang/LLVM gets major funding from Apple. mysql is now Oracle. Etc., etc.

author: Bud
author_rank: Super Contributor
timestamp: April 05, 2016, 05:22:06 am
content: Then how come they caused me major pain in the rear installing OpenCV on a Ubuntu machine.

author: ade
author_rank: Unknown
timestamp: April 05, 2016, 06:25:29 am
content: OpenCV is almost trivial to install on Ubuntu.

author: Karel
author_rank: Super Contributor
timestamp: April 05, 2016, 06:27:27 am
content: Quote from: Bud on April 05, 2016, 05:22:06 amHave you thought about a computer course?

author: hendorog
author_rank: Super Contributor
timestamp: April 05, 2016, 06:32:36 am
content: I was going to install it on osx until I read this:http://www.pyimagesearch.com/2015/06/15/install-opencv-3-0-and-python-2-7-on-osx/Yeah, nah. Can't be bothered.At least linux distro's have standards and policies for how this stuff should be done. OSX doesn't. Windows doesn't.Maybe it doesn't always work perfectly, but its better than the alternatives.

author: ade
author_rank: Unknown
timestamp: April 05, 2016, 06:43:02 am
content: Coincidentally I just did an install of OpenCV 3 with Python 3 bindings for OSX last week. Lots of experimentation and cmake option changes required. My write up here:http://peekay.org/2016/03/24/opencv-osx-python-3-bindings/Ubuntu is a cinch in comparison.

author: senso
author_rank: Frequent Contributor
timestamp: April 05, 2016, 12:04:07 pm
content: Quote from: Karel on April 05, 2016, 06:27:27 amIf you happened to need openCv 2.2 some years ago, ubuntu repos only had 2.0, and to put 2.2 was a "fun" experience..findOpenCv was bugged/not cooperating and having it all work was a nightmare.And it wouldnt astonish me that Ubuntu is still using old old versions of almost anything and to use up to date packages there is always the put this random ppa and it will work or recompile..

author: CatalinaWOW
author_rank: Super Contributor
timestamp: April 05, 2016, 02:11:05 pm
content: Quote from: ade on April 05, 2016, 04:49:16 amSo you don't think documentation is critical when coordinating the efforts of a dozen or so major organizations? Many of the organizations you name have the same properties I described. Waxing and waning support. Turnover in the people assigned. Any OS is a multi-decade process for both users and developers. Long term success is likely to benefit from actions that make it easier for both groups to do their jobs. The problem I see from many here is recognizing that for most users the OS is not their job. Ideally it should be something that makes their real job easier. At worst it shouldn't make it harder. Apple has made a successful business out of their recognition of who their users are and making their job easier. Linux has done pretty well when their user group is server operators. Not so well expanding into the desktop. Windows tries to serve everyone, and as a result has many flaws for most, particularly as they chase new markets like smartphones and tablets.

author: ade
author_rank: Unknown
timestamp: April 05, 2016, 04:25:15 pm
content: QuoteWhen & where did I say that? Please provide reference.Sure individuals come and go, but that's true for OSS as well as closed-source projects.Many years ago I was a core team member of another major open-source project (FreeBSD) and at that time I put in a ton of effort in ensuring up to date documentation. I inherited the job from someone else and another person took over from me. And today FreeBSD remains highly documented, with a dedicated team (Docs team) vigilantly maintaining it.I've found that the documentation for major open source projects tend to be as good as closed-source offerings. I include all of the examples cited previously: Linux kernel (and FreeBSD kernel of course), Apache, Eclipse, Node.js, etc., -- as well as open source end-user applications like Mozilla Firefox, LibreOffice, GIMP, KiCad, etc.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 05, 2016, 05:44:56 pm
content: Quote from: nctnico on April 04, 2016, 04:52:15 pmNice joke... Or were you attempting to be serious?

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 05, 2016, 05:49:28 pm
content: Quote from: ade on April 05, 2016, 04:25:15 pmThat's because most of it has evolved over decades. Early documentation for most of your examples really sucked and it's only after years of effort that it's become passable.My latest pet peeve is the declining quality of vendor documentation for microcontrollers and other ICs. Datasheets and user guides for these used to be quite good--accurate, thorough, and well-written. Recently it looks like the vendors are outsourcing this work by using writers for whom English is a second or third language to write their documentation, and it shows.

author: ade
author_rank: Unknown
timestamp: April 05, 2016, 06:21:01 pm
content: QuoteAgain, that's no different than many closed-source commercial offerings.E.g., I remember working on my first iPhone app (2008) and major aspects of iOS were not well documented at the time. One often had to browse private APIs to understand how the public APIs work. Today the iOS framework documentation is generally superb.Dr. Dobb's Journal had a regular column on poorly or undocumented features of major software/hardware from Microsoft, Intel, etc.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 05, 2016, 08:00:47 pm
content: Quote from: ade on April 05, 2016, 06:21:01 pmThere are undoubtedly examples of that, but in my experience, commercial products are usually documented better.All of the examples you mentioned are large, well-known projects (Linux, Apache, etc.) There are thousands of other open source projects are are not as well known, and these are the ones that tend to have no documentation at all, or scant documentation written as an afterthought by someone who'd rather be coding.

author: Koen
author_rank: Frequent Contributor
timestamp: April 05, 2016, 09:06:43 pm
content: Well duh, the commercial option has to offer something more than the free option. If you need thorough documentation, direct support and hand-holding, you pay for it. If you expect the same from free software, get real.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 05, 2016, 09:24:48 pm
content: Quote from: Koen on April 05, 2016, 09:06:43 pmThat's exactly why I don't use free software, because "free" software usually ends up costing me more than software that I actually pay for.

author: legacy
author_rank: Super Contributor
timestamp: April 05, 2016, 09:28:47 pm
content: Quote from: Sal Ammoniac on April 05, 2016, 09:24:48 pmprecisely my point

author: ade
author_rank: Unknown
timestamp: April 05, 2016, 10:02:40 pm
content: Free vs. non-free has nothing to do with Linux or open-source.RedHat Enterprise Linux (RHEL) is open-source, commercial, but NOT free. You can download its source code and make your own derivative version (a la CentOS) but you can't get RHEL for free.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: April 06, 2016, 01:10:48 am
content: Quote from: ade on April 05, 2016, 10:02:40 pmThat's part of the problem. Free versus non-free. Free as in speech. Free as in beer. Yada yada yada. Confuses the hell out of people.

author: Mechatrommer
author_rank: Super Contributor
timestamp: April 06, 2016, 03:48:13 am
content: Quote from: Koen on April 05, 2016, 09:06:43 pmthe reality is that. some people choose to pay exactly just because of this reason (documentation). the reality is that, "free" will not go boom if this kind of archaic mentality is still intact. M$ and the ecosystem surrounding it will survive, good thing for them. most will think and figured out that, profitability in reality is not measured by revenue/tco (total cost of ownership), but |revenue| (absolute magnitude) = revenue - tco. having less time tinkering with program's code compile, more time to do real productive tasks means more |revenue|, ymmv.

author: mongo
author_rank: Contributor
timestamp: April 07, 2016, 11:21:56 pm
content: Note that this change was documented, and it is the error of the programer and not the toolset. If you upgrade make to something past 4.1 it is a non-fatal error again.Here is where the change was documented...the fact that all programers seem to ignore compiler warning is the issue. For some reason this is a human thing, ignore that you are doing it wrong until it actually won't compile.https://lists.gnu.org/archive/html/info-gnu/2010-07/msg00023.htmlQuoteAnd GNU changing it back because people still refused to fix their code over those 4 years.https://lists.gnu.org/archive/html/info-gnu/2014-10/msg00000.htmlQuoteLike any system out there GNU as issues...but they are pretty good about warning people for years before enforcing good behavior.

author: nctnico
author_rank: Super Contributor
timestamp: April 08, 2016, 09:41:54 am
content: Quote from: mongo on April 07, 2016, 11:21:56 pmThis is where your thinking is backwards. Even though it was 'wrong' it worked as expected so it isn't wrong after all. So what the author of the software did from a functional point of view was remove a useful feature.

author: Marco
author_rank: Super Contributor
timestamp: April 08, 2016, 10:01:11 am
content: Quote from: senso on April 05, 2016, 12:04:07 pmThis is just a fact of life on Ubuntu, if you want to be on the bleeding edge with Ubuntu with something you either need someone to maintain PPA for it or you are almost certainly better off on Debian testing/unstable.Or you get to build it from source yourself.

author: legacy
author_rank: Super Contributor
timestamp: April 08, 2016, 10:29:22 am
content: and … there is something strange ingentoowith the last autobuildstage3/x86-2016-Aprilwhat hell is happening ?!?!?!? why the "mount" is not working as it should ?!?!?!? are you fooling me ?!?!?!?things changed TOO much in just 2 yearsI need alife-extensionto follow all these "rolling approach", I can't support all the effort that loooooooooooniiiiiixxxxxx and open source requires(not mentioning that I am not payed enough, e.g. the "software" task is payed 400 euro per week,thus no doubt my business would make more per year in profit with ice cream …&& with less frustration and stress)

author: legacy
author_rank: Super Contributor
timestamp: April 08, 2016, 10:34:22 am
content: I have emerged and installed 4 toolchainsthus one can choose what he/she needs/wants (1)Code:uc-builder # gcc-config -l i686-pc-linux-gnu-4.1.2 * i686-pc-linux-gnu-4.9.3 powerpc-unknown-linux-gnu-4.1.2 * powerpc-unknown-linux-gnu-5.3.0(1) that is kind way to say that ...gcc-v4.9won't compilekernel 2.6.39on x86as good asgcc-v5.3won't compile kernel2.6.19/23onPowerPCthus you need to switch togcc-v4.1.2in both cases …… I haveNO timeto fix all of that crap

author: Marco
author_rank: Super Contributor
timestamp: April 08, 2016, 11:25:28 am
content: Quote from: legacy on April 08, 2016, 10:29:22 amLets get real here for a moment and look at this from a customer point of view. With what other solution could a customer get this major a software upgrade on a hardware platform which hadn't seen active software support for this long for this cheap?Your pain is his gain

author: legacy
author_rank: Super Contributor
timestamp: April 08, 2016, 11:44:43 am
content: Quote from: Marco on April 08, 2016, 11:25:28 amemmm ….. (cough … cough) … Bob(who?) charges 50 euro per hour, his customer pays him for "software development"which means … that he never fixes legacy things, he always "develops" new things (which breaks old things)a week is composed by 5 working days of 8 hours each, it means he charges 400 euro in 1 dayand oh my goodness my pocket calculator is saying that 50x8x5 is 2000 euro per weekwhich sounds "unbelievable" for my wallet, since It gets loaded by 2200 euro per monththus the science might have a good explanation for the British way of saying "Middling to average!"

author: legacy
author_rank: Super Contributor
timestamp: April 08, 2016, 12:08:20 pm
content: according to theEinstein's Theory of General Relativity, Bob (a true developer) lives in another planetone month of Life in Hell is equal to one week of Life on Earth (he also lives in Palm Springs California)at least, paid the same money, thus, I believe I will get my devil horns and tailHey ho? Dandy forHalloween(my dry humor)

author: Kilrah
author_rank: Unknown
timestamp: April 08, 2016, 12:20:27 pm
content: Quote from: legacy on April 08, 2016, 10:29:22 amThat is entirely your problem! These things are known and expected, updates WILL cost... they must be factored in and if the customer isn't happy he can stay with his existing solution.The problem is simple - the devs working on those things do that daily. They will naturally start by doing things easier for themselves and for whatever their own goals are and others who will see an updated dependency and care for it the same day in 5 minutes, then for new users, and only as a last priority try not to break it too much for existing users - and if you were in that position you'd likely do the same.The open source game is simple - you get to benefit from decades of engineering work done by others for free, but it's your responsibility to glue the parts together to make it work. Nothing forces you to use it, if you're not happy you can go roll your own () or pay up for a commercial solution.You apparently offered the choice to your customer to go with a commercial solution that was deemed too expensive, and improperly budgeted the alternative open source solution, which obviously even if the code itself is free does have costs - that might actually be higher than the commercial solution!Linux/open systems are a rolling ball, as mentioned when you're working on it daily you'll see small things break due to updated dependencies etc as they come so it's a minor task to fix at this point as only one thing is likely to get broken at a time making the source of the issue obvious, and the creator of that dependency will likely have limited and documented the impact of the incremental update as much as possible. Now the longer something stays unattended the more things will break and the harder each of the fixes will be, so it gets exponentially more complex to get up to speed with. At some point it's actually better to start the actual project over with the currently available tools than trying to get the old thing to work again.But that's something that can easily be modeled and turned into a budget estimation for a client. Count a rough amount of time you would have to spend to keep the project up to date on a weekly basis, and turn that into some amount per week the codebase has stayed unmaintained, and add that up. It should pretty much average out the simplifying factors like "lib X was already mature" and the more difficult ones like "platform was completely dropped from support so current versions can't be used and old ones have to be dug out". After 8 years that number should become so huge that it will be obvious it's not a viable option, in which case you have to evealuate others, like redeveloping the whole thing from scratch or going for a completely different solution, whether software, hardware or both.But as mentioned if you keep an entire build setup as is in the state it was at the time of the last build so you can reuse that then you're bypassing all that. It has a cost too, so must be billed accordingly with proper explanations.So yeah, the TL;DR is that you're somehow surprised about the obvious, have offered yourself for a job for way too cheap, but are trying to put that responsibility on people who gave you their work for free instead of admitting your mistakes

author: legacy
author_rank: Super Contributor
timestamp: April 08, 2016, 01:04:19 pm
content: Quote from: Kilrah on April 08, 2016, 12:20:27 pmdo you want it with lemon and coffee ? do you prefer "stracciatella" ?it's an Italian soup containing eggs and cheese, plus chocolatetwo ice cream flavors, two dollars(kidding, I understand your points, and I still HATE loooooniiiixxxx and GNU)

author: Kilrah
author_rank: Unknown
timestamp: April 08, 2016, 01:06:10 pm
content: Theeeeen save yourself the hassle and don't use them, many other options

author: legacy
author_rank: Super Contributor
timestamp: April 08, 2016, 01:10:49 pm
content: Quote from: Kilrah on April 08, 2016, 12:20:27 pmI am dealing with gentoo, and this "rolling ball" always takes a looooooooooooooooooooot of efforteven if I am behind the Catalyst firewall, I happen to rebuild everything from the scratchbut hey? in 2004 that task took 1 week to prepare a FULL working stage3nowadays it takes 2-3 weeks …. and you always have to check it double the double due the increased complexitythings keep getting …… better in their being like rolling ball

author: legacy
author_rank: Super Contributor
timestamp: April 08, 2016, 01:12:42 pm
content: Quote from: Kilrah on April 08, 2016, 01:06:10 pmyep, I will have to sell my penguin hat and t-shirt(but … don't touch my BDI1000 !!! never for sale!)

author: Monkeh
author_rank: Super Contributor
timestamp: April 08, 2016, 02:21:20 pm
content: 2-3 weeks for a stage3? ... more like an afternoon.How exactly is mount broken? Would you care to elaborate rather than inarticulately whinge?

author: legacy
author_rank: Super Contributor
timestamp: April 08, 2016, 02:42:50 pm
content: Quote from: Monkeh on April 08, 2016, 02:21:20 pmyeah, thehardenedandendurancetake 2-3 weeksplus more 4 days for the stage4, we are speaking about things for productionhave you ever tried to build an-uclibc-stage3 for mips4 (which is not MIPS32)?OpenWRT and his friend are simply IGNORING mips4, so you will have funIn my opinionthiswas funnyby the end of the last year I was able to complete an uclibc stage3 in 2 weeks, by ONLY using very ugly tricks(hybridizing old things, which is very bad, but hey? I am limited) whileCatalystis still (after 4 mounts) defectivehobby purpose in this case, so we schedule the activity in our part timesince there is no valid reason (except the intellect challenge) to run linux on Octane(1)however, the interesting things is that during the switching from 2.6.17 (2006) to3.1v4.3.0 (2015) everythingeverything went broken X___________X* * * everything that could have been broken was really broken * * *and it feel that it was theMurphy law, applied to everything, kernel, tools, rootfs … everything ...… like a spell on you, like voodoo, and I have learnt that I'd better avoid to underestimate it(1) it's an old workstation made by SGI, deprecated since 2004

author: legacy
author_rank: Super Contributor
timestamp: April 08, 2016, 03:06:54 pm
content: Quote from: Monkeh on April 08, 2016, 02:21:20 pmdon't worry, I am not here to ask help, I am here to have a beeror a tea, if you prefer to be Britishcrossdev claimed it can't complete its job because it doesn't like the overlay (due to bugs)uuuuu, really? I wiped it out, and I switched to Angstrom by OE which completed the jobOh,Angstrominstalled on gentoo to crosscompile gentoo tools, it makes senseandmounthas a strange behavior now, before updating (emerge --sync, and update) it worked as expectedonce updated … well, in first place "mount -o remount,rw /" stopped to workclaiming a lot of strange (not able to be understood, not intelligible) errorswhich practically were solved by invoking it as "mount -o remount,rw /dev/sdb1 /"ironically it claimed that "/dev/mtab was impossible to read/write"are you fooling me? really? enjoy my 2 seconds workaroundthus I replaced the whole /etc/init.d with customized scriptswhich are under control, and do their jobI have really no time to investigate, I am tired and lateall the software steps are completed, tested, and working, I am burning a couple of DVDs as "Virtual Box image"inside my customer will find a working builder, which is able to build his old linux kernel and the whole powerpc rootfsthat is the only way I can afford the linux stress: "don't care, go on"

author: Monkeh
author_rank: Super Contributor
timestamp: April 08, 2016, 03:37:25 pm
content: You might want to look into how your root filesystem is actually mounted..

author: legacy
author_rank: Super Contributor
timestamp: April 08, 2016, 04:52:06 pm
content: before emerge-upgrade(when mount was working)linux booted, and it invoked "mount -o remount,rw /"after upgrade(before my ugly trick)linux booted, it invoked "mount -o remount,rw /"and … it failed, claiming that /etc/mtab was not accessible, and blablablacurrentlylinux boots, it invokes "mount -o remount,rw /dev/sdb1/"and … it works againI do not want to know WHY/WHAT/WHOit's fine, I am fine, don't touch it, that's all

author: Muxr
author_rank: Super Contributor
timestamp: April 09, 2016, 01:14:33 am
content: As a long time Linux user, I do get annoyed with Linux distributions as well. I think Linux on the Desktop has long ways to go still. Also frequent reinvent the wheel of some of the core system components does get really annoying. It's still way less annoying than Windows though.On server however, it is lightyears ahead of anything else.

author: legacy
author_rank: Super Contributor
timestamp: April 10, 2016, 02:57:25 pm
content: * H * A * T * E *I was thinking thatkmod-5andkmod-4were fine, and …."depmod -a <kernel_version>" is broken, oh shit!"make modules_install" gets no all files created, oh shit!and … once again the problem is added fromkmod-5because they "improved" (what?!?!?!?!?)thus, I regressedkmod-5back tokmod-4andmake modules_installis feeling fineedit: including their funny comment, can I still have a Pumpkin?!?!?Quote

author: Monkeh
author_rank: Super Contributor
timestamp: April 10, 2016, 02:59:11 pm
content: Who would've expected ancient software to break when you start bolting newer pieces onto it? Not you, clearly..

author: legacy
author_rank: Super Contributor
timestamp: April 10, 2016, 03:03:38 pm
content: Quote from: Monkeh on April 10, 2016, 02:59:11 pmto be honestNO!it's like expecting that "mount" has to changewhen there are NO reasons to changeunless supporting the theory thatthe purpose is making people to waste timewith silly thingsI wasted 45 minutes on that bullshit, shit!

author: Monkeh
author_rank: Super Contributor
timestamp: April 10, 2016, 03:09:11 pm
content: Plenty of reasons to change. You just can't see them because you're not looking.

author: legacy
author_rank: Super Contributor
timestamp: April 10, 2016, 03:09:27 pm
content: DVDs are still hot, they smell ready to be shippedeverything is freezed onto write once devicethus nobody (including G-BOYs) can changeand thanks God, the story endsI am going to the swimming poolthank you for your support, guyshave a nice Sunday

author: mongo
author_rank: Contributor
timestamp: April 11, 2016, 04:52:41 pm
content: Quote from: legacy on April 08, 2016, 04:52:06 pmIf you look in 'man mount' you will see that they probably moved to UUID definitions within /etc/fstab. UNIX has always been an expert system, and it does provide some useful shortcuts but the change does have a reason. I can understand the frustration you are feeling and this is not intended as an insult but there is a huge difference between knowing the steps behind something and knowing why you are doing those steps. There are very good reasons that they moved to UUID's in fstab including making it less painful for users when they changed the order that their hard drives were plugged in. It may be that linux offers free upgrades between fairly major versions but IMHO this is more akin no not having mouse support when you add "LH MOUSE.COM /Y" to AUTOEXEC.BAT in windows 7.QuoteThere are critical data safety and security reasons why any OS cannot "guess" what is the right drive to re-mount. But I would much rather have a more stable, more secure system with modern capabilities than be tied to convenience features of commands for decades because users may not have read the manual.This relates to the original complaint in this post, where an illegal behavior that had caused lots of issues finally had been enforced. You do not get away from this issue even in systems which error towards the non-expert user like OS X, this is an intrinsic problem with complex systems. Moving forward will result in changes, and changes that result from behaviors where programers and users explicitly ignore documentation will be low priority to protect.

author: botcrusher
author_rank: Regular Contributor
timestamp: April 11, 2016, 05:16:53 pm
content: 'Nix is not for the faint of heart. not paying for an os has it's ups and downs, and most everything mentioned in this thread relates to the things an advanced power user has to do.My current thought relates to a distro i have a relationship akin to your dear old cousin. I don't see him often, but when i do, it's a grand old time.This distro is slitaz, and is an extreme example of just how awesome linux can be in the right hands. it can use modern software, but the base system can operate comfortably on minuscule amounts of ram. storage? on a 700 meg cd, it can store 20 copies of itself.bypassing my drooling for a second, it may not be the easiest thing to fully get working, but i have managed to make pentium 4s and Ds look like speed demons. It's incredible how zippy this thing is when running modern software, it chews through chrome with similar speed to my desktop (once you get chrome running...) i've gotten both nvidia drivers and wine to run on it, but never have in the same install, so I really think I should do that.Anyways, goes to show that in the right hands, it's incredibly useful. You pay a price in terms of the work spent, but at least to me it's quite worth it when i have to work with given hardware.On a different note, I find it hilarious that wine can be faster at windows than windowsTyping this on an underpowered ARM chromebook (they do run linux) that still tears through fairly intensive windows like they're nothing.

author: legacy
author_rank: Super Contributor
timestamp: April 11, 2016, 05:32:34 pm
content: Quote from: mongo on April 11, 2016, 04:52:41 pmblablablabla you get the point:It worked before upgraded

author: legacy
author_rank: Super Contributor
timestamp: April 11, 2016, 05:33:56 pm
content: Quote from: mongo on April 11, 2016, 04:52:41 pmlinux is not UNIX, never had such silly problems with IRIXeven if I upgraded from 6.5.8 to 6.5.30, so ...

author: Monkeh
author_rank: Super Contributor
timestamp: April 11, 2016, 05:42:17 pm
content: Quote from: legacy on April 11, 2016, 05:32:34 pmIt worked before you changed it without thinking

author: legacy
author_rank: Super Contributor
timestamp: April 11, 2016, 05:45:19 pm
content: Quote from: mongo on April 11, 2016, 04:52:41 pmyes, Sherlock, the problem was related toglibcI do not want to know what/where/who/how, it's crap codewhat I know is: I recompiled the newgnu-libcmanuallythen I re-compiled (by emerge)dev-libs/klibcsys-apps/util-linuxand since then "mount" has been working as expected(with no error accessing /etc/mtab /etc/fstab etc)

author: Monkeh
author_rank: Super Contributor
timestamp: April 11, 2016, 05:51:31 pm
content: No wonder your system is such a broken mess.

author: legacy
author_rank: Super Contributor
timestamp: April 11, 2016, 05:52:03 pm
content: Quote from: Monkeh on April 11, 2016, 05:42:17 pmare you retarded? or just here to troll?easy steps, so you can understand bettermount was workingI invoked emerge --sync and upgradethe whole system was upgraded as described in the gentoo-documentation, and things (including mount and glibc) were recompiled from the scratchI rebooted the machinebrokenthus, I fixed, in order to complete my task since I was late

author: legacy
author_rank: Super Contributor
timestamp: April 11, 2016, 06:05:56 pm
content: more specifically the following comes form gentoo, /etc/init.d/rootCode:ebegin "Remounting root filesystem read/write"case "$RC_UNAME" inLinux)mount -n -o remount,rw /;;*)mount -u -o rw /;;

author: mongo
author_rank: Contributor
timestamp: April 11, 2016, 06:24:24 pm
content: Quote from: legacy on April 11, 2016, 05:52:03 pmWell the fact that you chose to call me offensive names proves the problem is with you....but best of luck, hope that attitude works out for you.

author: legacy
author_rank: Super Contributor
timestamp: April 11, 2016, 06:50:49 pm
content: Quote from: legacy on April 08, 2016, 04:52:06 pmQuote from: legacy on April 08, 2016, 04:52:06 pm

author: legacy
author_rank: Super Contributor
timestamp: April 14, 2016, 10:28:57 am
content: since it's the second time that someone reports the "question" to me, asking about "my attitude":yes, the above made me pissed off, a lot, especially the mount-man bullshit: I perfectly know what to do with linux, I have more than 15 years of experience and I hate to hear bullshit like the above, and in fist place I fixed the problem without asking help to anyone, this topic is pure entertainmentoh, now I have problems (and a lot of people in gentoo have the same issues) with ncurses, which is breaking the bash shell, and catalyst is doomedbut I will avoid to waste your and my time, I prefer to open a blogregards

author: mongo
author_rank: Contributor
timestamp: April 14, 2016, 03:44:44 pm
content: As the person whom made the "man mount" comment, and as a person whom didn't report you the I need to make the point that Gentoo being "versionless" and thus open to millions of non-tested upgrade interactions you should expect working through issues. Gentoo requires more involvement from the user, and while you make have taken offence to my comment it was very valid. As someone whom has been running linux professionally for 20 years I revel in my ignorance and learn something new every day.As an honest question, which may come across as an insult but is not intended as so, if you are bothered by odd distro bugs and problems why run a distro that is explicitly targeted at individuals whom want to run the latest and greatest despite the pain? I have no issues with Gentoo, but due to it's relative obscurity and model is almost a guarantee you will need to dig through release notes and man pages. As a person whom is paid to architect build systems at a software company this happens even with much smaller code bases and dependency levels. I am sure you have valid reasons for running the distro but I will take issues with your rant against gnu and the linux kernel due to this choice. Debian GNU/Linux is very stable if crusty but it is crusty because of the time they spend on integration testing.