I have always thought that the prinicpal practical reason for the GPL (aside from the philosophical reasons of freedom) is that without the safeguards of having to release modified code, a company can use the vast library of GPL software to short-cut their development process and then make profits without having to financially recognise the contribution from the legions of people who have contributed. Like patents and copyright, the GPL is a bargain between contributors in addition to those provided by usual copyright protection - sure you can use this code, but contribute the results back into the pool, if you don't like it fine but develop your own.
This is why the Tivoisation problem is so difficult, in principal you have the software but you would also require to build new hardware for it run on - the new GPL is an attempt to deal with this but is in my opinion slightly misguided as GPL deals with software abstractions and it would be very difficult to make restrictions restriction on the hardware that abstraction executes on. Hardware is covered by different legislation anyway and no software developer can insist that the designs for the hardware are also released. However, the flipside is that Tivo other projects have gained enormously from the use of GNU/Linux code and should have an obligation back to the contibutors for that commercial advantage.
I am a complete self-confessed kitchen gadget freak, and from the review it seems that you are not averse to souping up (pardon the pun) some of the more mundane cooking items. So, what are your money-no-object-must-have-for-the-shear-cheek-of it-never-persuade-the-loved-one-it-is-vital kitchen gadgets ?
The big problem with this discussion is that the second is the accepted unit time. Once that is fixed there will be so many seconds per day (assuming we want to stay in sync with the sun!) then its just a matter of finding nice division units.
Hair pulling pulling out date bug ...
on
Pet Bugs?
·
· Score: 1
Way back when I was working on a simple database on the Commodore Pet (how long ago ?...) when I noticed that a lot of people in the database had birthdays on 29th of february - don't even ask how I spotted this.
After many weeks of stuggling it turned out that the database held dates internally as julian day counts and converted them to day/month/year for display. However, if the year was a leapyear then every access to that persons record actually subtracted 1 day from the record until, yes you guessed it, it hit Feb 29th at which point it stopped. Thank goodness we had the source code but nonetheless, all the dates in leap years were corrupted.
version fatigue and package management
on
Version Fatigue
·
· Score: 1
There is also the opposite issue - when developers use latest and greatest versions of shared libraries and package management tools won't let an earlier version of library suffice - even if the api and/or functionality hasn't changed of the library routine used. This problem becomes acute if GNU/linux is going to become mainstream. If developers insist on using the largest version number (because its current) rather than the lowest that does the job, users have to upgrade key elements of their more frequently. (Maybe individual functions should be version numbered, hmm... just a thought)
Don Knuth (the author of TeX) once made a comment in one of his books that if I were an engineer it would be very easy for me to go out and study great buildings but it is very difficult to find "great code" which we can hold up as an example to budding programmers. There is an interesting exchange in one of Knuth's books (the literate programming one I think) where he creates a program for a task using his self documenting and logically ordered language. Another leading computer scientist was then asked to respond. he called it a "Faberge egg" of a programme. Exquisitely structured, beautiful to look at, but the same result could have been achieved using 3 unix commands and two pipes!
For me, as a a teacher of programming, I would love to see a resource of great code I could refer to which had been peer judged as worthy of imitation.
Slashdot Mirror
I have always thought that the prinicpal practical reason for the GPL (aside from the philosophical reasons of freedom) is that without the safeguards of having to release modified code, a company can use the vast library of GPL software to short-cut their development process and then make profits without having to financially recognise the contribution from the legions of people who have contributed. Like patents and copyright, the GPL is a bargain between contributors in addition to those provided by usual copyright protection - sure you can use this code, but contribute the results back into the pool, if you don't like it fine but develop your own.
This is why the Tivoisation problem is so difficult, in principal you have the software but you would also require to build new hardware for it run on - the new GPL is an attempt to deal with this but is in my opinion slightly misguided as GPL deals with software abstractions and it would be very difficult to make restrictions restriction on the hardware that abstraction executes on. Hardware is covered by different legislation anyway and no software developer can insist that the designs for the hardware are also released. However, the flipside is that Tivo other projects have gained enormously from the use of GNU/Linux code and should have an obligation back to the contibutors for that commercial advantage.
I am a complete self-confessed kitchen gadget freak, and from the review it seems that you are not averse to souping up (pardon the pun) some of the more mundane cooking items. So, what are your money-no-object-must-have-for-the-shear-cheek-of it-never-persuade-the-loved-one-it-is-vital kitchen gadgets ?
The big problem with this discussion is that the second is the accepted unit time. Once that is fixed there will be so many seconds per day (assuming we want to stay in sync with the sun!) then its just a matter of finding nice division units.
Way back when I was working on a simple database ...) when I noticed that a lot of people in the database had birthdays on 29th of february - don't even ask how I spotted this.
on the Commodore Pet (how long ago ?
After many weeks of stuggling it turned out that the database held dates internally as julian day counts and converted them to day/month/year for
display. However, if the year was a leapyear then every access to that persons record actually subtracted 1 day from the record until, yes you guessed it, it hit Feb 29th at which point it stopped. Thank goodness we had the source code but nonetheless, all the dates in leap years were corrupted.
There is also the opposite issue - when developers use latest and greatest versions of shared libraries and package management tools won't let an earlier version of library suffice - even if the api and/or functionality hasn't changed of the library routine used. This problem becomes acute if GNU/linux is going to become mainstream. If developers insist on using the largest version number (because its current) rather than the lowest that does the job, users have to upgrade
key elements of their more frequently. (Maybe individual functions should be version numbered, hmm... just a thought)
Don Knuth (the author of TeX) once made a comment in one of his books that if I were an engineer it would be very easy for me to go out and study great buildings but it is very difficult to find "great code" which we can hold up as an example to budding programmers. There is an interesting exchange in one of Knuth's books (the literate programming one I think) where he creates a program for a task using his self documenting and logically ordered language. Another leading computer scientist was then asked to respond. he called it a "Faberge egg" of a programme. Exquisitely structured, beautiful to look at, but the same result could have been achieved using 3 unix commands and two pipes! For me, as a a teacher of programming, I would love to see a resource of great code I could refer to which had been peer judged as worthy of imitation.