EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: legacy on April 02, 2016, 03:10:38 pm
-
a customer needs to support sandpoint-x3/kernel-2.6.22
make-ppc
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 syntax
make[1]: *** No rule to make target 'silentoldconfig'. Stop.
make: *** No rule to make target 'include/config/auto.conf', needed by 'include/config/kernel.release'. Stop.
ota
make-ppc -d
and the above command tells a lot of crap: how to solve?
deprecated syntax, crap scripts, and once again …
… it looks like a mission impossible :palm: :palm: :palm: :palm: :palm:
(where the FSCK is my personal jesus ?)
-
the above was perfectly working in 2008
thus WHY ?!?
they want to change things
with the result of making them broken ???
my pants :palm: :palm: :palm:
-
the above was perfectly working in 2008
You 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.
-
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 (http://osdir.com/ml/bug-make-gnu/2011-04/msg00011.html)
(googling <30s BTW)
Cheers.
---
Daniel
-
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... :scared:
-
As someone already pointed out; it is not the fault of Linux...
-
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.
-
my effort to fix the jam, practically it will take the whole weekend |O
(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)
-
human readable, at least in principle
there 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)
-
GNU make was tolerant in the past with some rules, but that was cleaned out:
A 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.
-
...the above command tells a lot of crap: how to solve?
Not 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. :-DD
Unless this is actually April 1st and I'm missing the joke here? :)
-
make-ppc -d
(-d, forcing debug)
[step2] compiling
GNU Make 4.1
Built for i686-pc-linux-gnu
Copyright (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 syntax
Updating 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 3422
GNU Make 4.1
Built for i686-pc-linux-gnu
Copyright (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 syntax
Updating 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[1]: *** No rule to make target 'silentoldconfig'. Stop.
Reaping losing child 0x9e83290 PID 3422
Removing 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 3455
Reaping winning child 0x9e82858 PID 3455
Live child 0x9e82858 (checkbin) PID 3456
Reaping winning child 0x9e82858 PID 3456
Removing 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.
done
is it clear? do you understand something?
-
Just switch to Windows and you will be happy again ;)
-
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.
-
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
long life and prosper, looooooniiiiiiix, the following was "easy" to be fixed
config %config: scripts_basic outputmakefile FORCE
$(Q)mkdir -p include/linux include/config
$(Q)$(MAKE) $(build)=scripts/kconfig $@
#
# 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 fixed :-DD :-DD :-DD
not mention that I have also a lot of hardware problems waiting to be solved
I 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 QEMU
since it was and it's still perfectly able to recompile the old linux kernel 2.6.22
this 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 kernel
then I really would suggest that career in ice cream sales you were mentioning. :-DD
absolutely ;D ;D ;D ;D
-
human readable, at least in principle
there 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)
GNU make was tolerant in the past with some rules, but that was cleaned out:
A 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.
How 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
-
A change -however technically justified- which makes things backwards incompatible is a no-go.
precisely!
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.
exactly what I am going to do
-
… I am telling you what I am going to do: I am going to put my old (2008) laptop's stage4 into QEMU
since it was and it's still perfectly able to recompile the old linux kernel 2.6.22
this 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 kernel
Probably 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.
-
I realise it's frustrating
precisely, I hope you can appreciate my dry humor in this topic
used to hide the sad Truth: linux is a very frustrating experience!
especially during the weekend (I have to respect a deadline)
the client insists
I 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 customization
and here we are :D
Anyway, best of luck.
thank you
-
here (http://stackoverflow.com/questions/9356735/makefile-rule-error-mixed-implicit-and-normal-rules) a few lines about "makefile-rule-error-mixed-implicit-and-normal-rules"
-
the above was perfectly working in 2008
thus WHY ?!?
they want to change things
with the result of making them broken ???
my pants :palm: :palm: :palm:
Next time you backup a project don't forget to include the whole toolset.
-
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 version
interesting :D
gcc-config -l | grep powerpc
[2] powerpc-unknown-linux-gnu-5.3.0 *
-
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.
-
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.
This 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...
-
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.
-
Just switch to Windows 10 and you will be happy again ;)
Fixed it for you. :palm:
-
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.
done!
I have
- extracted my old 2008 stage4 from my old laptop (it's a PowerBook-G4, running gentoo linux)
- created a Qemu/PPC virtual machine
- installed the stage4, which comes with gcc v4.1.2, native compiling host=target=powerpc
results
- kernel-2.6.19-sandpoint3-G4: success :-+
- kernel-2.6.22-sandpoint3-G4: success :-+
with "success" I mean
- it compiles
- the final binary boots on the final target
in paralel I have also
- downloaded VirtualPC
- 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 for PowerPC
otaku sandpoint3 # gcc-config -l
[1] i686-pc-linux-gnu-4.9.3 *
[2] powerpc-unknown-linux-gnu-4.1.2 *
results
- kernel-2.6.19-sandpoint3-G4: success :-+
- kernel-2.6.22-sandpoint3-G4: failure/it does not compile :--
(1) those "silly" errors(2) are are lying along the whole tree
including script folders and subfolders, and source folders
there 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 following
myccandclib="powerpc-unknown-linux-gnu-"
make ARCH=powerpc CROSS_COMPILE=$myccandclib
edit:
(2) most of them appear as
*** mixed implicit and normal rules
*** deprecated syntax
and 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 directory
while the file is "arch/powerpc/kernel/head_32.S"
but there are also errors which are gcc-version dependent
and I do not really want to fight with gcc >= v4.2
-
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.
I 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.
-
Just switch to Windows 10 and you will be happy again ;)
Fixed it for you. :palm:
April 1? Windows 10 on ppc :-DD
-
Quote from: linux-works on Today at 02:32:08 AM (https://www.eevblog.com/forum/index.php?topic=65795.msg910067#msg910067)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.
This 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...
The 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 ... :palm:
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 ...
-
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?
-
my 2008 stage4 comes with
gcc-config -l
[1] powerpc-unknown-linux-gnu-3.4.6
[2] powerpc-unknown-linux-gnu-4.1.1
[3] powerpc-unknown-linux-gnu-4.1.2 *
binutils-config -l
[1] powerpc-unknown-linux-gnu-2.17 *
minerva ~ # as -v
GNU assembler version 2.17 (powerpc-unknown-linux-gnu) using BFD version 2.17
-
Retaining backwards compatibility is not the same as making progress.
Retaining 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.
How would you feel if you got in a new car and found the brake and accelerator pedals swapped?
I'm sure you have noticed that the number of pedals are different in an automatic cf a manual. :)
-
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.
This is a very typical example of the sort of help you can expect for free, on an ee forum, while you're ranting, 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...
FTFY
mikerj, 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.
-
Retaining backwards compatibility is not the same as making progress.
Retaining 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.
Indeed, 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.
How would you feel if you got in a new car and found the brake and accelerator pedals swapped?
I'm sure you have noticed that the number of pedals are different in an automatic cf a manual. :)
Indeed, and they are backwards compatible. ;)
-
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?
Howard, I do wonder how did people manage to drive before http://www.modelt.ca/drive.html (http://www.modelt.ca/drive.html):
There are three pedals on the floor marked from left to right when sitting in the driver's seat: C (clutch), R (reverse) and B (break). There are two levers on the steering column, spark advance and throttle, and one floor lever to the left of the driver. The floor lever is neutral while in the upright position, second gear when in the forward position while the leftmost pedal (C) is not depressed, and emergency brake when all the way back.
The leftmost pedal (C) is first gear while depressed, second gear if the floor lever is forward when released. The middle pedal is reverse gear when depressed and the rightmost pedal is the brake. The right lever on the steering column is the gas, and the other lever is the spark advance. Confused? Once you drive for a month or so, it gets easy, but the controls are far from orthogonal. If you get into trouble, you can just stomp on all three pedals and that will stop you pretty quick. Doing this causes the bands in the transmission to lock up the drive train. The best thing to remember while driving is to plan ahead.
And 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!
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.
You 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.
-
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?
Howard, I do wonder how did people manage to drive before:
There are three pedals on the floor marked from left to right when sitting in the driver's seat: C (clutch), R (reverse) and B (break). There are two levers on the steering column, spark advance and throttle, and one floor lever to the left of the driver. The floor lever is neutral while in the upright position, second gear when in the forward position while the leftmost pedal (C) is not depressed, and emergency brake when all the way back.
The leftmost pedal (C) is first gear while depressed, second gear if the floor lever is forward when released. The middle pedal is reverse gear when depressed and the rightmost pedal is the brake. The right lever on the steering column is the gas, and the other lever is the spark advance. Confused? Once you drive for a month or so, it gets easy, but the controls are far from orthogonal. If you get into trouble, you can just stomp on all three pedals and that will stop you pretty quick. Doing this causes the bands in the transmission to lock up the drive train. The best thing to remember while driving is to plan ahead.
From: http://www.modelt.ca/drive.html (http://www.modelt.ca/drive.html)
Indeed, 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.
-
Lol, it is perhaps just me, but i feel not all talking here about backward compatibility are real software 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 :popcorn: ;)
-
@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.
-
@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.
Didn't i mention something about "costs and pain", or was that just a dream? ;)
-
@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.
And 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...
-
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.
You 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.
First, 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=111709 (https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=111709)
Now, 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.
-
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.
-
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.
-
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.
+1, +10, +100...
-
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.
he'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.
-
Those who talk about backward compatibility doesn't realize that software is far more complex than electronics.
Been 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.
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.
You 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.
Backward compatibility therefore is a huge effort that significantly slows down development.
You'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.
Most open source developers are simply not interested in spending huge efforts to support legacy software.
Which is the problem. They want to be continually tinkering at the expense of the end user.
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.
As 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.
-
Those who talk about backward compatibility doesn't realize that software is far more complex than electronics.
Been 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.
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.
You 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.
Backward compatibility therefore is a huge effort that significantly slows down development.
You'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.
Most open source developers are simply not interested in spending huge efforts to support legacy software.
Which is the problem. They want to be continually tinkering at the expense of the end user.
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.
As 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.
Errrrrr, 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
-
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.
-
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.
Okay.
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
-
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.
Okay.
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
And 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 that the right balance between backwards compatibility and tinkerers deprecating things hasn't been struck in Linux.
-
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.
Okay.
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
And 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 that the right balance between backwards compatibility and tinkerers deprecating things hasn't been struck in Linux.
Supermarket 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
-
f1rmb:
That is how the dev world works, like it or not
That 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 that there is a balance and 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.
-
f1rmb:
That is how the dev world works, like it or not
That 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 that there is a balance and 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.
For 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
-
My point is and always has been that there is a balance and Linux on the desktop is often too chaotic due to too many well meaning changes without regard to the effect on end users.
I agree
-
As 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.
Actually 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.
-
It's a bit like those Windows based high-end oscilloscopes
umm, I think those products are good because of the software the can run, e.g. matlab, lab view, ...
things that cannot run on linux
-
As 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.
Actually 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.
Between 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 :)
-
As 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.
Actually 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.
Between 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 :)
"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
-
kernel 2.6.26: 219 mixed implicit and normal rules & deprecated syntax
interesting :D :D :D
-
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!. :)
-
Actually I tend to find that the most bright and knowledgeable professional software engineers prefer Linux as a development environment over Windows.
i 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 (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.
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.
i just wonder is there a succesfull linux DSO? google says none.
Those of us who actually make a living developing large-scale (multi-millions of lines) software systems understand the limitations and benefits of Linux
maybe 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.
We instead prefer to focus on cutting edge new technology.
what 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.
-
...
i just wonder is there a succesfull linux DSO? google says none.
...
You've got us all silenced there, with a very strong argument.
-
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.2008
while make.2016 says that it's deprecated
and "$(BOOT_TARGETS)" is expanded into a LIST[]
this un-evolving make: it really makes sense :D
-
this un-evolving make: it really makes sense :D
actually what this thread is about? a linux hate? or a linux help me fix? you said in the title its fixed.
But if you don't believe someone who does large scale software engineering professionally then it's your problem.
dont 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.
-
I work with people in (and I often work from) Canary Wharf in London. I won't say more and I don't need to say more because this is not about me. As I stated before I do know what I'm talking about, it's my job. I've no reason not to tell the truth. But if you don't believe someone who does large scale software engineering professionally then it's your problem. And as I said before no one stops you buying Windows and commercial IDEs so you don't need to use Linux.
I don't see the point discussing this topic further.
Indeed, 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.
-
actually what this thread is about? a linux hate? or a linux help me fix? you said in the title its fixed.
I am able to provide two solutions to my customer, in order to support this "sand point" board
both of them are limited to kernel 2.6.19 and gcc v4.1.2
everything else is NOT working and/or it needs more effort and time
in short, I am fine, thanks :D
I was just commenting how crazy are these tools by GNU (make? gcc?)
and how chaotic are the linux sources
-
I was just commenting how crazy are these tools by GNU (make? gcc?)
and how chaotic are the linux sources
They 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 ...
-
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.
You're stating the obvious.
-
both of them are limited to kernel 2.6.19 and gcc v4.1.2
so 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.
-
so the solution is not to upgrade? thats understandable.
I "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 have
I mean I have a deadline, and I have to
- fix the hardware, I have to complete a PCI-FPGA board, there is mistake in the PSU section
- fix the VHDL code, because my customer wants a customization
- fix the firmware, because DINK32 (made by Freescale) has a bug, which limits the amount of (soldered) ram to the half
- fix the rootfs, because my customer wants uclibc instead of glibc
- fix the kernel module, it creates a bridge between the userspace (/dev/fpga) and the hardware
- add a few examples to show my customer how he should use the fpga
- provide 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 effort
I can allocate such an activity ONLY if my customer will allocate a budget for that
-
I mean I have a deadline, and I have to
blahblahblah...
all of these steps MUST be completed for the end of the next week,
Not the fault of Linux. Blame yourself for accepting a job with such deadlines.
-
want a stable platform? dont upgrade.
yes, there is also another motivation, confirmed to me by the last build-up I have experimented 5 minutes ago
Unfortunately everything > 2.6.23 has no support and comes into the problem of enabling the mmu.
The sandpoint needs 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.23 :palm: :palm: :palm:
I 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.
-
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.
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.
You 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.
-
I mean I have a deadline, and I have to
blahblahblah...
all of these steps MUST be completed for the end of the next week,
Not the fault of Linux. Blame yourself for accepting a job with such deadlines.
You 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.
-
It's a bit like those Windows based high-end oscilloscopes
umm, I think those products are good because of the software the can run, e.g. matlab, lab view, ...
things that cannot run on linux
Both Matlab and Labview run on Linux quite happily.
-
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 :)
Howard, 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/LinuxChanges (http://kernelnewbies.org/LinuxChanges)
You 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.
-
I mean I have a deadline, and I have to
blahblahblah...
all of these steps MUST be completed for the end of the next week,
Not the fault of Linux. Blame yourself for accepting a job with such deadlines.
You 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.
Karel is a known troll, just look at the FTDI thread ...
-
so the solution is not to upgrade? thats understandable.
I "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 have
I mean I have a deadline, and I have to
- fix the hardware, I have to complete a PCI-FPGA board, there is mistake in the PSU section
- fix the VHDL code, because my customer wants a customization
- fix the firmware, because DINK32 (made by Freescale) has a bug, which limits the amount of (soldered) ram to the half
- fix the rootfs, because my customer wants uclibc instead of glibc
- fix the kernel module, it creates a bridge between the userspace (/dev/fpga) and the hardware
- add a few examples to show my customer how he should use the fpga
- provide 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 effort
I can allocate such an activity ONLY if my customer will allocate a budget for that
I 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.
-
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.
You're stating the obvious.
I 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!
-
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 :)
Howard, 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/LinuxChanges (http://kernelnewbies.org/LinuxChanges)
You 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.
Actually, 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
-
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.
-
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.
Actually, you may not be aware, but I do.
-
It wasn't directed to you, more of a general conclusion after reading the whole thread.
-
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.
You're stating the obvious.
I 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!
It 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.
-
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.
-
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.
And 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?
-
I wonder if the ppc code gets much love these days?
umm, as far as i see, it seems that the x86 & arm code get much more love these days :-//
-
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.
And 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?
I 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.
-
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.
The 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.
-
I 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.
That'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.
-
I 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.
precisely what I am going to do :D
Porting drivers between major kernel releases is a huge effort if the driver wasn't maintained for a long time.
that is the case: after the kernel version 2.6.24, Motorola removed the support
since they declared "obsolete" the Sandpoint-x3 74xx line
-
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.
-
The 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.
You'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.
-
Here is an example of OSX changing like the wind:
https://support.apple.com/en-nz/HT202516
Interestingly 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.
-
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.
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.
You 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.
No 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
-
If ms did it.why were clients buying? Why they didnt other oses?
-
If ms did it.why were clients buying? Why they didnt other oses?
Abuse of monopoly (they are convicted for that) and vendor-lockin.
-
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
in 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 much
e.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 :-//
-
p.s.
I like products made by WindRiver, e.g. VxWorks sources and Workbench (even if … it's Eclipse based :palm: )
-
Not wishing to sidetrack the thread from the OP's predicament, this OSS incident happened last week http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ (http://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!
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;
}
-
Not wishing to sidetrack the thread from the OP's predicament, this OSS incident happened last week http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ (http://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!
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;
}
I 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...)
-
Just hold the phone. I'm not having it!
Where do you think you are? This is not the place for sensible rational debate. If we start expecting people to explain their positions we might start resolving things.
Oh, yeah, you're right! Maybe I should head back to twitter and see what @nibblerpoop has been up to...
-
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.
Are
you
kidding
me
?
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.
-
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.
-
... this OSS incident happened last week ...
Coverity, 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/ (http://www.zdnet.com/article/coverity-finds-open-source-software-quality-better-than-proprietary-code/)
-
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.
Are
you
kidding
me
?
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.
exactly the feel I have when I say I HATE it :D
-
Take the libraries you need, commit it on the version control, together with the project and the C code
sakura # mydev all list
2. 6 /idp.do/mysrc/lib/lib_basen2_v3
1. 1 /idp.do/mysrc/lib/lib_bit_set_v1
4. 5 /idp.do/mysrc/lib/lib_bitmap_v2
4. 2 /idp.do/mysrc/lib/lib_bitmap_v3
5. 8 /idp.do/mysrc/lib/lib_cal_stamp_v1
1. 6 /idp.do/mysrc/lib/lib_debug_v1
1. 0 /idp.do/mysrc/lib/lib_endian_v2
12. 1 /idp.do/mysrc/lib/lib_env_collector_mini_v1
2. 3 /idp.do/mysrc/lib/lib_env_disk_io_v1
4. 8 /idp.do/mysrc/lib/lib_env_pool_label_v1
4. 9 /idp.do/mysrc/lib/lib_env_pool_string_v1
3. 8 /idp.do/mysrc/lib/lib_env_shell_cmd_v1
1. 3 /idp.do/mysrc/lib/lib_env_toy_v1
658. 0 /idp.do/mysrc/lib/lib_env_wrapper_v1
1. 2 /idp.do/mysrc/lib/lib_fileIO_unix_v1
2. 0 /idp.do/mysrc/lib/lib_file_utils_v1
2. 0 /idp.do/mysrc/lib/lib_file_utils_v2
3. 3 /idp.do/mysrc/lib/lib_filename_filter_v3
2. 6 /idp.do/mysrc/lib/lib_filename_utils_v8
2. 2 /idp.do/mysrc/lib/lib_fs_folder_level_v1
1. 3 /idp.do/mysrc/lib/lib_fs_folder_level_v2
5. 9 /idp.do/mysrc/lib/lib_lexer_reserved_word_language_l1_show_v7b
5. 3 /idp.do/mysrc/lib/lib_lexer_reserved_word_language_l1_v7b
1. 8 /idp.do/mysrc/lib/lib_lexer_reserved_word_v7b
1. 9 /idp.do/mysrc/lib/lib_lexer_tokenize_v7b
8. 5 /idp.do/mysrc/lib/lib_lexer_v7b
1. 6 /idp.do/mysrc/lib/lib_linea_v2
5. 9 /idp.do/mysrc/lib/lib_list_handler_v1
10. 3 /idp.do/mysrc/lib/lib_mystring_v1
10. 0 /idp.do/mysrc/lib/lib_mystring_v2
2. 8 /idp.do/mysrc/lib/lib_net_udp_ip_v1
1. 0 /idp.do/mysrc/lib/lib_pico_shell_slush_addon_v4
6. 8 /idp.do/mysrc/lib/lib_pico_shell_slush_v4
952. 0 /idp.do/mysrc/lib/lib_pico_shell_toy_v4
1. 3 /idp.do/mysrc/lib/lib_progress_bar_v2.2
13. 0 /idp.do/mysrc/lib/lib_queue_gp_v3
8. 6 /idp.do/mysrc/lib/lib_safestring_v2
3. 2 /idp.do/mysrc/lib/lib_serial_unix_v3
3. 5 /idp.do/mysrc/lib/lib_serial_unix_v4
2. 0 /idp.do/mysrc/lib/lib_string_fuzzy_match_v1
10. 9 /idp.do/mysrc/lib/lib_tokener_fast_v8
10. 9 /idp.do/mysrc/lib/lib_tokener_fast_v8b
7. 1 /idp.do/mysrc/lib/lib_tokener_fussy_v8
6. 0 /idp.do/mysrc/lib/lib_tokener_language_show_v1
5. 2 /idp.do/mysrc/lib/lib_tokener_language_v1
8. 7 /idp.do/mysrc/lib/lib_tokener_v8
6. 1 /idp.do/mysrc/lib/lib_uart_unix_v5
2. 1 /idp.do/mysrc/lib/lib_udpip_v2
1. 9 /idp.do/mysrc/lib/lib_unix_termio_kb_v2
4. 4 /idp.do/mysrc/lib/lib_unix_termio_kb_v4
sakura # mydev lib_progress_bar
last version: v2.2
already committed: yes, 2015/12/10, by root@sakura
last access: 2015/12/10
test bench: passed
status: quality compliance untested
sakura # mydev lib_progress_bar_v2.2 list
4. 3 Kbyte Makefile
4. 1 Kbyte lib_progress_bar.c
384. 0 byte lib_progress_bar.h
375. 0 byte lib_progress_bar.interface
25. 0 byte lib_progress_bar.private
4. 0 Kbyte obj
4. 0 Kbyte test
3. 7 Kbyte test_lib_progress_bar.c
204. 0 byte test_lib_progress_bar.interface
113. 0 byte test_lib_progress_bar.private
sakura # mylib mk lib_progress_bar_v2.3
sakura lib_progress_bar_v2.3 # mylib import from lib_progress_bar_v2.2
calling build-project-makefile-v4.2
MYINCLUDE={ -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 }
----------------------------------------------------------------------
sakura lib_progress_bar_v2.3 # make clean_all
- cleaning interfaces .
- cleaning all
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_bar
sakura lib_progress_bar_v2.3 # make
- compiling lib_progress_bar ... done
- compiling test_lib_progress_bar ... done
- linking to my
sakura lib_progress_bar_v2.3 # make commit
- committing ...… done
sakura # mydev lib_progress_bar
last version: v2.3
already committed: yes, 2016/04/04, by root@sakura
last access: 2016/04/04
test bench: untested
status: quality compliance untested
I can do it, only for hobby ;D ;D ;D
-
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.
-
I see you build as root? I suppose this is in a sandbox
yes, in a sandbox
-
(the trick comes from gentoo
mean emerge uses sandboxes
and I have recycled that code)
-
used in a real complex application :D
sakura otaku_v1 # obj/test
Otaku
hAllo!
# help
new parser
[help] kind3 1:1 token_StrictAlphaNum, type21
command (2)
cmd_help()
cmd_list, 50 items
exit................ - byebye
?................... - cmd list
help................ - show specific cmd help
ver................. - version
my.................. - proof, provided by shell_init
idevice............. - swi tap set
iclass.............. - swi tap set
ireg................ - swi tap set
get................. - swi tap reg get
put................. - swi tap reg put
id.................. - swi tap identify
ping................ - swi tap ping
resync.............. - swi tap resync
open................ - swi tap open
close............... - swi tap close
con................. - swi tap connect
tapS................ - swi tap server
scan................ - swi tap client scan
mode................ - swi tap mode
grid................ - swi tap grip
regs................ - swi tap reg show
cv.................. - code view
d1.................. - ncurses demo1
d2.................. - ncurses demo2
d3.................. - ncurses demo3
oo.................. - rom emulator init
oc.................. - rom emulator init
ow.................. - rom emulator write
or.................. - rom emulator read
srec................ - srec to bin
sl.................. - srec load
ans=True
# exit
byebye
sakura otaku_v1 # mydev project
info: Arise-v2 debug processor
class: app
sakura otaku_v1 # mydev project hierarchy
the project is composed by the following local sub modules:
app_my_dbg_swi
lib_app_my_dbg_swi
lib_my_dbg_swi_v5
lib_my_dbg_swi_v5/tap
lib_my_dbg_swi_v5/tap/fsm
lib_my_dbg_swi_v5/tap/l1
lib_my_dbg_swi_v5/tap/grid
lib_my_dbg_swi_v5/tap/protocol
lib_my_dbg_swi_v5/device/handler
lib_my_dbg_swi_v5/device/lib_net_tcp_ip_v0.2_my
lib_my_dbg_swi_v5/device/lib_net_udp_ip_v0.2_my
lib_my_dbg_swi_v5/device/lib_net_v2
lib_my_dbg_swi_v5/device/lib_uart_obj_v0.2
lib_my_dbg_swi_v5/device/tap_device
lib_debugger_code_view_v1
lib_debugger_code_view_v1/demo
lib_debugger_code_view_v1/demo2
lib_unix_termio_kb_v4
lib_rom_emulator_ostrich2_v1
lib_progress_bar_v3
lib_srec_to_bin_light_v3
sakura otaku_v1 # mydev project lib
the project depends on the following committed libraries:
lib_pico_shell_slush_v4.o
lib_pico_shell_slush_addon_v4.o
lib_pico_shell_toy_v4.o
lib_tokener_v8.o
lib_tokener_fast_v8b.o
lib_tokener_language_Z_v1.o
lib_tokener_language_Z_show_v1.o
lib_bitmap_v3.o
lib_bit_set_v1.o
lib_basen2_v3.o
lib_safestring_v2.o
lib_debug_v1.o
lib_linea_v2.o
lib_fileIO_unix_v1.o
lib_net_udp_ip_v1.o
sakura otaku_v1 # mydev project ilib
the project depends on the following OS libraries
ncurses
form
pthread
-
PPCDEV-SP3-7457: Pre-Configured Linux Sandpoint X3 Motherboard with Valis X3 MPC7457 PMC Module
Features
MPC7457 host processor @ 1.3 GHz
Tundra Tsi107 bridge chip
JTAG connector on PMC module
One PMC slot on Sandpoint motherboard to accept processor PMC modules
Switch-selectable modes
Four 5V 32-bit PCI slots at 33 MHz
Two standard 16650-compatible serial ports
IEEE 1284 parallel port
NVRAM and real-time clock (RTC)
Two IDE ports
LED monitors critical functions
Advanced Power Controller ("soft on/off")
Standard System Configuration
MPC7457 host processor @ 1.3 GHz
Tundra Tsi107 bridge chip
64 or 128MByte of SDRAM memory and a 2MByte DDRSRAM L3 cache
ATX mini-tower case
DINK32 debug monitor ROM
Yellow Dog Linux kernel 2.4.21-rcl (pre-installed, CDs included)
Network card
40GB hard drive
IDE cable
what obsolete part resellers are still offering in business: v2.4.21 :-DD :-DD :-DD
-
Coverity, a company specializing in software quality and security testing solutions, finds that open source programs tend to have fewer errors than proprietary programs.
synopsis should also compare open source programs "documentation" and proprietary programs "documentation".
-
Coverity, a company specializing in software quality and security testing solutions, finds that open source programs tend to have fewer errors than proprietary programs.
synopsis should also compare open source programs "documentation" and proprietary programs "documentation".
Both 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.
-
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.
-
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.
I 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.
-
Both 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.
i 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".
-
Both 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.
i was not talking about code's documentation. i was talking about the documentation of the end product, to the users, not the programmers.
Maybe 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.
-
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.
I 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.
Of 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.
-
>Of 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.
You are assuming that in a commercial environment these factors are not an issue. Except, the onus shifts from the programmer to the project manager. What if the manager in question has neither the motivation nor the time to get documentation done by his team. Or worse still, is not fully aware of the importance of documentation. After all, being a commercial outfit, their priority is first to survive by selling a product/service, documentation is a second priority.
-
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.
-
Then how come they caused me major pain in the rear installing OpenCV on a Ubuntu machine.
-
OpenCV is almost trivial to install on Ubuntu.
-
Then how come they caused me major pain in the rear installing OpenCV on a Ubuntu machine.
Have you thought about a computer course?
-
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/ (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.
-
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/ (http://peekay.org/2016/03/24/opencv-osx-python-3-bindings/)
Ubuntu is a cinch in comparison.
-
Then how come they caused me major pain in the rear installing OpenCV on a Ubuntu machine.
Have you thought about a computer course?
If 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..
-
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.
So 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.
-
So you don't think documentation is critical when coordinating the efforts of a dozen or so major organizations?
When & 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.
-
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.
Nice joke... Or were you attempting to be serious?
-
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.
That'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.
-
That'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.
Again, 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.
-
That'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.
Again, that's no different than many closed-source commercial offerings.
There 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.
-
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.
-
If you need thorough documentation, direct support and hand-holding, you pay for it. If you expect the same from free software, get real.
That'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.
-
That'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.
precisely my point
-
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.
-
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.
That'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.
-
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.
the 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.
-
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.html
* WARNING: Backward-incompatibility!
As a result of parser enhancements, three backward-compatibility issues
exist: first, a prerequisite containing an "=" cannot be escaped with a
backslash any longer. You must create a variable containing an "=" and
use that variable in the prerequisite. Second, variable names can no
longer contain whitespace, unless you put the whitespace in a variable and
use the variable. Third, in previous versions of make it was sometimes
not flagged as an error for explicit and pattern targets to appear in the
same rule. Now this is always reported as an error.
And 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.html
* Change the fatal error for mixed explicit and implicit rules, that was
introduced in GNU make 3.82, to a non-fatal error. However, this syntax is
still deprecated and may return to being illegal in a future version of GNU
make. Makefiles that rely on this syntax should be fixed.
See https://savannah.gnu.org/bugs/?33034
Like any system out there GNU as issues...but they are pretty good about warning people for years before enforcing good behavior.
-
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.
This 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.
-
If 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.
This 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.
-
and … there is something strange in gentoo with the last autobuild stage3/x86-2016-April :o :o :o :o :o :o :o
what hell is happening ?!?!?!? why the "mount" is not working as it should ?!?!?!? are you fooling me ?!?!?!?
things changed TOO much in just 2 years :palm: :palm: :palm: :palm:
I need a life-extension to 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 :-DD :-DD :-DD )
-
I have emerged and installed 4 toolchains
thus one can choose what he/she needs/wants (1)
uc-builder # gcc-config -l
[1] i686-pc-linux-gnu-4.1.2 *
[2] i686-pc-linux-gnu-4.9.3
[3] powerpc-unknown-linux-gnu-4.1.2 *
[4] powerpc-unknown-linux-gnu-5.3.0
(1) that is kind way to say that ... gcc-v4.9 won't compile kernel 2.6.39 on x86
as good as gcc-v5.3 won't compile kernel 2.6.19/23 on PowerPC
thus you need to switch to gcc-v4.1.2 in both cases …
… I have NO time to fix all of that crap :-//
-
not mentioning that I am not payed enough, e.g. the "software" task is payed 400 euro per week
Lets 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 :)
-
Your pain is his gain :)
emmm ….. (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) :palm: :palm: :palm: :palm:
a week is composed by 5 working days of 8 hours each, it means he charges 400 euro in 1 day
and oh my goodness my pocket calculator is saying that 50x8x5 is 2000 euro per week
which sounds "unbelievable" for my wallet, since It gets loaded by 2200 euro per month
thus the science might have a good explanation for the British way of saying "Middling to average!" :-DD :-DD :-DD :-DD
-
according to the Einstein's Theory of General Relativity, Bob (a true developer) lives in another planet
one 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 tail
Hey ho? Dandy for Halloween :-DD :-DD :-DD
(my dry humor)
-
(not mentioning that I am not payed enough, e.g. the "software" task is payed 400 euro per week
That 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 ( :-DD ) 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 ::)
-
if you're not happy you can
do you want it with lemon and coffee ? do you prefer "stracciatella" ?
it's an Italian soup containing eggs and cheese, plus chocolate
two ice cream flavors, two dollars :D :D :D :D
(kidding, I understand your points, and I still HATE loooooniiiixxxx and GNU)
-
Theeeeen save yourself the hassle and don't use them, many other options :-+
-
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
I am dealing with gentoo, and this "rolling ball" always takes a looooooooooooooooooooot of effort
even if I am behind the Catalyst firewall, I happen to rebuild everything from the scratch
but hey? in 2004 that task took 1 week to prepare a FULL working stage3
nowadays it takes 2-3 weeks …. and you always have to check it double the double due the increased complexity
things keep getting …… better in their being like rolling ball :-DD :-DD :-DD
-
Theeeeen save yourself the hassle and don't use them, many other options :-+
yep, I will have to sell my penguin hat and t-shirt :D :D :D
(but … don't touch my BDI1000 !!! never for sale!)
-
2-3 weeks for a stage3? ... more like an afternoon.
How exactly is mount broken? Would you care to elaborate rather than inarticulately whinge?
-
2-3 weeks for a stage3? ... more like an afternoon
yeah, the hardened and endurance take 2-3 weeks
plus more 4 days for the stage4, we are speaking about things for production
have you ever tried to build an-uclibc-stage3 for mips4 (which is not MIPS32) :D ?
OpenWRT and his friend are simply IGNORING mips4, so you will have fun :D
In my opinion this (https://bugs.gentoo.org/show_bug.cgi?id=568912) was funny
by 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) while Catalyst is still (after 4 mounts) defective :o :o :o
hobby purpose in this case, so we schedule the activity in our part time
since 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) to 3.1 v4.3.0 (2015) everything
everything went broken X___________X
* * * everything that could have been broken was really broken * * *
and it feel that it was the Murphy 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 :o :o :o
(1) it's an old workstation made by SGI, deprecated since 2004
-
How exactly is mount broken? Would you care to elaborate rather than inarticulately whinge?
don't worry, I am not here to ask help, I am here to have a beer
or a tea, if you prefer to be British
crossdev 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 job
Oh, Angstrom installed on gentoo to crosscompile gentoo tools, it makes sense :-DD
and mount has a strange behavior now, before updating (emerge --sync, and update) it worked as expected
once updated … well, in first place "mount -o remount,rw /" stopped to work
claiming a lot of strange (not able to be understood, not intelligible) errors
which 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 workaround
thus I replaced the whole /etc/init.d with customized scripts
which are under control, and do their job
I have really no time to investigate, I am tired and late
all 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 rootfs
that is the only way I can afford the linux stress: "don't care, go on"
-
You might want to look into how your root filesystem is actually mounted..
-
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 blablabla
currently
linux boots, it invokes "mount -o remount,rw /dev/sdb1/"
and … it works again
I do not want to know WHY/WHAT/WHO
it's fine, I am fine, don't touch it, that's all :D
-
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.
-
* H * A * T * E *
I was thinking that kmod-5 and kmod-4 were 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 from kmod-5
because they "improved" (what?!?!?!?!?)
thus, I regressed kmod-5 back to kmod-4
and make modules_install is feeling fine |O
edit: including their funny comment, can I still have a Pumpkin?!?!?
Warning: you may need to install module-init-tools
See http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt (http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt)
-
Who would've expected ancient software to break when you start bolting newer pieces onto it? Not you, clearly..
-
Who would've expected ancient software to break when you start bolting newer pieces onto it? Not you, clearly..
to be honest NO!
it's like expecting that "mount" has to change
when there are NO reasons to change
unless supporting the theory that
the purpose is making people to waste time
with silly things
I wasted 45 minutes on that bullshit, shit!
-
Plenty of reasons to change. You just can't see them because you're not looking.
-
DVDs are still hot, they smell ready to be shipped
everything is freezed onto write once device
thus nobody (including G-BOYs) can change
and thanks God, the story ends
I am going to the swimming pool
thank you for your support, guys
have a nice Sunday :D :D :D
-
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 blablabla
currently
linux boots, it invokes "mount -o remount,rw /dev/sdb1/"
and … it works again
I do not want to know WHY/WHAT/WHO
it's fine, I am fine, don't touch it, that's all :D
If 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.
remount
Attempt to remount an already-mounted filesystem. This is commonly used to change the mount flags for a filesystem, especially to make a readonly filesystem writeable. It does not change device or mount point.
The remount functionality follows the standard way how the mount command works with options from fstab. It means the mount command doesn't read fstab (or mtab) only when a device and dir are fully specified.
mount -o remount,rw /dev/foo /dir
After this call all old mount options are replaced and arbitrary stuff from fstab is ignored, except the loop= option which is internally generated and maintained by the mount command.
mount -o remount,rw /dir
After this call mount reads fstab (or mtab) and merges these options with options from command line ( -o ).
There 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.
-
'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 windows :-DD
Typing this on an underpowered ARM chromebook (they do run linux) that still tears through fairly intensive windows like they're nothing.
-
If you look in 'man mount' you will see that they probably moved to UUID definitions within /etc/fstab.
blablablabla you get the point: It worked before upgraded
-
UNIX has always been an expert system
linux is not UNIX, never had such silly problems with IRIX
even if I upgraded from 6.5.8 to 6.5.30, so ...
-
If you look in 'man mount' you will see that they probably moved to UUID definitions within /etc/fstab.
blablablabla you get the point: It worked before upgraded
It worked before you changed it without thinking
-
but there is a huge difference between knowing the steps behind something and knowing why you are doing those steps
yes, Sherlock, the problem was related to glibc
I do not want to know what/where/who/how, it's crap code
what I know is: I recompiled the new gnu-libc manually
then I re-compiled (by emerge)
- dev-libs/klibc
- sys-apps/util-linux
and since then "mount" has been working as expected
(with no error accessing /etc/mtab /etc/fstab etc)
-
No wonder your system is such a broken mess.
-
It worked before you changed it without thinking
are you retarded? or just here to troll?
easy steps, so you can understand better
- mount was working
- I invoked emerge --sync and upgrade
- the whole system was upgraded as described in the gentoo-documentation, and things (including mount and glibc) were recompiled from the scratch
- I rebooted the machine
- broken
thus, I fixed, in order to complete my task since I was late
-
more specifically the following comes form gentoo, /etc/init.d/root
ebegin "Remounting root filesystem read/write"
case "$RC_UNAME" in
Linux)
mount -n -o remount,rw /
;;
*)
mount -u -o rw /
;;
-
It worked before you changed it without thinking
are you retarded? or just here to troll?
easy steps, so you can understand better
- mount was working
- I invoked emerge --sync and upgrade
- the whole system was upgraded as described in the gentoo-documentation, and things (including mount and glibc) were recompiled from the scratch
- I rebooted the machine
- broken
thus, I fixed, in order to complete my task since I was late
Well 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.
-
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 blablabla
currently
linux boots, it invokes "mount -o remount,rw /dev/sdb1/"
and … it works again
more specifically the following comes form gentoo, /etc/init.d/root
ebegin "Remounting root filesystem read/write"
case "$RC_UNAME" in
Linux)
mount -n -o remount,rw /
;;
*)
mount -u -o rw /
;;
-
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 entertainment
oh, 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 doomed :palm: :palm: :palm:
but I will avoid to waste your and my time, I prefer to open a blog
regards
-
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.