The GPL says that there can't be a requirement that you give credit to the author of the program.......The GPL also says that you can't put a limitation on sublicensing IP rights.
which are restrictions on requirements and restrictions on limitations.
and then later:
I know for a lot of people the GPL is sort of synonymous with "open source.".... I really don't agree with that point of view. I think it is way too restrictive.
So something that has limits of the limitations that can be enforced is too restrictive? I think he has it backwards!
sed and perl are not 'broken' but the need to hand-create a parser for every different configuration file is a fundamentally broken concept and can only cause confusion and problems. Do they properly handle '\' ? does '$' need to be double escaped? etc. I am reminded of my old suse system which on every boot up grepped my XF86Config file for a specific line and modified it with sed. Every time. After a month I am wondering why there is a line in my config file that has 30 '#' in the beginning of it.
The problem is that there is no clear specification on these comments. Is it case sensitive? Do they break if someone put a space before the ':' or is that okay? What about if there is an accidental space after the $ in $network? At what point do I get notified if there is an error? How do I validate the comments? How do I know what specification these comments are supposed to adhere to? My Redhat 9 box uses different format; man chkconfig says '# chkconfig: 2345 20 80' as an example of the appropriate comment.
I first saw 'specially formatted comments' in visual c++ with MFC autogenerated code and for ever more, I will always oppose them as they are a source of problems.
I personally don't care if people chose XML. Just choose SOMETHING that does all we need it to do and stick with it! XML is as good as anything else that is a standard.
My current favourite is the init scripts in Suse. Is this LSB?
from the/etc/init.d/mysql script:
### BEGIN INIT INFO
# Provides: mysql
# Required-Start: $network $remote_fs
# Required-Stop:
# Default-Start: 2 3 5
# Default-Stop:
# Description: Start the MySQL database server
### END INIT INFO
Gotta love those specially formatted comments! Need to generate or parse this code which is embedded after initial comments and before shell script code? Or need to make a programmatic way of modifying it? Get out sed or perl and re-invent the broken wheel yet again.
It makes me want to rip out this stuff and just use launchd. At least it is not a hack. And guess what format the config files for launchd are in?
XML is not the greatest thing. But at least it has the ability to replace the current mish-mash of configuration file formats and symbolic links and heavy dependancies which are a nightmare! Why does every executable need to employ it's own special ascii parsing function? How many of these configuration file formats work with unicode?
People who complain about run-time type checking errors are obviously not running unit tests! They think that if their statically typed code compiles, it must be correct!
I gather that RTL is mainly beneficial for servers, etc. But would this low latency also benefit desktop users and the responsiveness of the UI? I mean, are clicks, etc. also of the type of interrupt that would be handled more quickly???
Please re-read your parent post...
Real Time is all about guaranteed times from interrupt to processing.
It doesn't really help servers - servers have different issues that are bigger bottlenecks.
In addition RTLinux does not let your normal user tasks have 'real time' priority - there are special real time tasks that get loaded into the kernel, and only those special tasks with limited capabilities are allowed to have real time constraints.
RTLinux would definitely help properly written media programs achieve lower input to output latency without having the worry that a screensaver would cause an audio glitch.
It is a bad name because the 'XML' is not even necessary. A few popular sites that are said to use AJAX are really using JSON, not XML. The concept is the same though.
What I envision is that I can express my DSP algorithm in the high level lazy evaluation functional language, and then it would get compiled down to C or ASM, taking into account the multiple execution units and software pipelining - basically re-order the math steps so it is most efficient on the specific DSP or Altivec.
The DSP's I'm thinking of are the Texas Instruments TMS6701 family, and maybe even altivec code.
I'd like to see a functional programming language that has a compiler which generates C code, ideally with customizable pipeline hints. (the assembly language for these dsp's are insane)
Typically DSP algorithms come down to pure math. The hard trick is to make representation of that math in C code that pipelines/optimizes well.
C and C++ really limit the compiler's ability to optimize well for non-Von Neumann architecture processors. Perhaps having the algorithm's code in a FP would allow the auto-generation of the C code that matches the architecture better.
I prefer 'functional' languages over the 'dysfunctional' ones.
What I _want_ is a functional language that I can use to generate real-time code for an embedded dsp. What functional languages are options for me? I would think that dsp and functional languages would be a match made in heaven... but I cannot find the path...
How many times do we have to re-invent the wheel? How many languages promised re-usability? How many object oriented class libraries were written that couldn't be effectively re-used?
Slashdot Mirror
What specifically?
The GPL is all about not allowing anyone to restrict the source code.
--jeffk++
from TFA:
which are restrictions on requirements and restrictions on limitations.and then later:
So something that has limits of the limitations that can be enforced is too restrictive? I think he has it backwards!
--jeff++
sed and perl are not 'broken' but the need to hand-create a parser for every different configuration file is a fundamentally broken concept and can only cause confusion and problems. Do they properly handle '\' ? does '$' need to be double escaped? etc. I am reminded of my old suse system which on every boot up grepped my XF86Config file for a specific line and modified it with sed. Every time. After a month I am wondering why there is a line in my config file that has 30 '#' in the beginning of it.
The problem is that there is no clear specification on these comments. Is it case sensitive? Do they break if someone put a space before the ':' or is that okay? What about if there is an accidental space after the $ in $network? At what point do I get notified if there is an error? How do I validate the comments? How do I know what specification these comments are supposed to adhere to? My Redhat 9 box uses different format; man chkconfig says '# chkconfig: 2345 20 80' as an example of the appropriate comment.
I first saw 'specially formatted comments' in visual c++ with MFC autogenerated code and for ever more, I will always oppose them as they are a source of problems.
I personally don't care if people chose XML. Just choose SOMETHING that does all we need it to do and stick with it! XML is as good as anything else that is a standard.
--jeff++
In addition, the kernel has had a nice, consistent ABI for quite some time. Why can't glibc and libstdc++ have one too?
--jeff++
Gotta love those specially formatted comments! Need to generate or parse this code which is embedded after initial comments and before shell script code? Or need to make a programmatic way of modifying it? Get out sed or perl and re-invent the broken wheel yet again.
It makes me want to rip out this stuff and just use launchd. At least it is not a hack. And guess what format the config files for launchd are in?
XML is not the greatest thing. But at least it has the ability to replace the current mish-mash of configuration file formats and symbolic links and heavy dependancies which are a nightmare! Why does every executable need to employ it's own special ascii parsing function? How many of these configuration file formats work with unicode?
--jeff++
Yes.
People who complain about run-time type checking errors are obviously not running unit tests! They think that if their statically typed code compiles, it must be correct!
--jeff++
Please re-read your parent post...
Real Time is all about guaranteed times from interrupt to processing.
It doesn't really help servers - servers have different issues that are bigger bottlenecks.
In addition RTLinux does not let your normal user tasks have 'real time' priority - there are special real time tasks that get loaded into the kernel, and only those special tasks with limited capabilities are allowed to have real time constraints.
RTLinux would definitely help properly written media programs achieve lower input to output latency without having the worry that a screensaver would cause an audio glitch.
--jeff++
I used to feel like that, until I tried to run Xen. nvidia's drivers do not work... what a hassle.
--jeff++
If they aren't doing anything wrong, then what does the government have to hide?
--jeff++
I'm CERTAIN that I have seen a Far Side comic that dealt with this exact situation.
--jeff++
Cost-benefit analysis shows that in that area, human life worth only during gestation, and therefore emergency infrastructure is not cost effective.
Wow! That's crazy! It shouldn't be that hard for rosetta to emulate altivec! Sure it would be slow but it could be made so apps don't break!
jeff
The great thing about not having books anymore is that book burnings become a thing of the past.
You don't need to convince anyone anymore.
With the combination of DRM and digital books, any undesirable content can just have their DRM keys revoked.
It makes it much easier to manipulate history, facts, and science.
--jeff++
It is a bad name because the 'XML' is not even necessary. A few popular sites that are said to use AJAX are really using JSON, not XML. The concept is the same though.
jeff
Some questions I had about this:
* Why bother with punk buster at all? I found it only really gets rid of the 'punks' for at most a couple weeks after a PB update.
* On the flip side, how would one/how could one write an open source program like punkbuster?
--jeff++
LISP is already being used for videogames on the ps2 very successfully, in very well written, fun games:
Naughty Dog and LISP
--jeff++
Wow! Anyone else see the irony in trying to configure linux to play the animation which makes fun of installing things on linux?
--jeff++
--jeff++
That looks great. But where can I d/l it?
What I envision is that I can express my DSP algorithm in the high level lazy evaluation functional language, and then it would get compiled down to C or ASM, taking into account the multiple execution units and software pipelining - basically re-order the math steps so it is most efficient on the specific DSP or Altivec.
--jeff++
I believe Urban Terror is one, and for me, the only one game that I still play!
--jeff++
The DSP's I'm thinking of are the Texas Instruments TMS6701 family, and maybe even altivec code.
I'd like to see a functional programming language that has a compiler which generates C code, ideally with customizable pipeline hints. (the assembly language for these dsp's are insane)
Typically DSP algorithms come down to pure math. The hard trick is to make representation of that math in C code that pipelines/optimizes well.
C and C++ really limit the compiler's ability to optimize well for non-Von Neumann architecture processors. Perhaps having the algorithm's code in a FP would allow the auto-generation of the C code that matches the architecture better.
--jeff++
I prefer 'functional' languages over the 'dysfunctional' ones.
What I _want_ is a functional language that I can use to generate real-time code for an embedded dsp. What functional languages are options for me? I would think that dsp and functional languages would be a match made in heaven... but I cannot find the path...
--jeff++
This is more than just a little insightful.
How many times do we have to re-invent the wheel? How many languages promised re-usability? How many object oriented class libraries were written that couldn't be effectively re-used?
--jeff++
--jeff++
Depends how you define 'work'. I'm trying to collect the whole set!!
--jeff++