Re:If OO is so great, why is bulk of GNU/Linux in
on
Object Oriented Perl
·
· Score: 1
rewriting an application in C++ bring few benefits.
You mean few immediate benefits. C++'s most winsome feature in practice is its excellent support for C, making it in some cases a no-op and always a quick job to convert a C program to C++-compilable form. (NO MORE VARIABLES NAMED "new" AND "class", PLEASE! STOP THE MADNESS!!!!!!) The drawbacks I find in using C++ features are minor losses of portability and GDB support.
The presence or absence of XS code (i.e. code that can segfault) in a PerlFS filesystem won't affect whether the kernel goes kaboom. The Perl code that executes, and any XS it calls, is in user mode, protected space. PerlFS defines a protocol for the userland fs code to return syscall results. It can't crash the kernel unless PerlFS (the kernel module) is buggy.
What?!! PerlOS, PerlWM and PerlSH... no PerlPERL? You gotta be kidding!
PerlPERL (a Perl interpreter written in Perl) would actually be a great way to implement a better debugger than the current perl -d. It's not so farfetched. After all, Lisp in Lisp has been around a long time. Perl now has the necessary introspective ability, it's just a lot of work because the interpreter is so complex.
For several years the GNU project has touted its Guile Scheme interpreter as the future configuration/scripting language for GNU applications. To date, none of the major GNU programs (GCC, GDB, Emacs, Make) embed Guile. Do you expect this to change soon? Have you considered replacing Scheme with Java in this plan?
It has nothing to do with the implementation, which he admits is fairly trivial to duplicate,
Waitaminute. The implementation is the only NON-trivial piece of this puzzle. The concept described in the patent is trivial, Jeff is claiming it's not, and Tim is letting him get away with it.
Re:FLT (offtopic)... JOKING?
on
SSH v. SRP
·
· Score: 1
"Java isn't platform independent; it is a platform. Like Windows, it is a proprietary commercial platform. That is, you can write programs for Windows/Intel or Java/JVM, and in each case you are writing code for a platform owned by a single corporation and tweaked for the commercial benefit of that corporation. It has been pointed out that you can write programs in any language for the JVM and associated operating systems facilities. However, the JVM, etc., are heavily biased in favor of Java. It is nowhere near being a general reasonably language-neutral VM/OS. " -- Bjarne Stroustrup's FAQ
Well, Sun seems to have got the better of Microsoft on this issue, but there is a GPLed Java language implementation for the rest of us. From my (rather brief) experience with it, Kaffe seems to do pretty well even with Sun's class files, though from what I've read performance may still need improvement.
... for use in place of the standard Explorer shell.
Bash is a program that lets you run other programs by typing their names. Explorer lets you run other programs by clicking with a mouse. Since they basically do the same thing (run programs), people refer to the Windows interface as a "shell" too. It took me a little effort to get my mind around this when I first heard it.:-)
So, let me get this right. Somebody is going to pay Chaney x dollars, where x >= 5000. Chaney is going to donate x + 2500 to a charity. Chaney deducts at least 7500 from his taxable income. Depending on his bracket, this guy could make out quite well.
If the comparison is Red Hat versus Microsoft security, you're right. But the tone of the article suggests that they are comparing open source versus closed source, and the fact that open source systems tend to use software from one distributor is relevant.
What I found interesting is that Microsoft has more bugs to be fixed.
They made it easy on MSFT. Windows systems tend to run more 3rd party software, in which Microsoft would not be expected to fix bugs. Whereas RedHat packages and distributes as many open source programs as it can. The comparison would have been fairer if they had included bugs in popular Windows programs from companies other than Microsoft (as well as stuff like Oracle for Linux, which would not be as much).
Also, they could consider that Debian systems can be configured to apply fixes automatically through cron and apt-get.
Besides, it'd probably be hard to keep straight all the various C keywords without speaking english, I bet.
Nope, there are only 30 or so keywords in C. Of course, the libraries have more functions, but how much does a knowledge of English really help you remember what malloc or ioctl means?
Oh yes, and does anyone know whether gcc is capable of handling chinese variable names and function names, regardless of which encoding scheme used?
I doubt it, but Perl supports this.
Re:The natural power of a programming language
on
RMS The Coder
·
· Score: 1
Nice paper (well, the 1/3 of it that I skimmed). The goal of a universal config file language is worthwhile, but it will not work if the language looks like Scheme. Quick and dirty languages succeed because they are quick. They are designed (using the word loosely) to require as little programmer time as possible, both to perceive the meaning of a script and to pound out something useful.
In other words, Scheme/Lisp is optimized for being read and written by the machine, while Shell, Perl, etc. are optimized for humans, and humans generally decide which language to use. Sure, if time were never an issue, we should all write beautiful code in a beautiful language like Lisp, but for small and ad-hoc jobs, it is unsuitable.
The ideal thing IMO would be an easy way to create little languages on top of a language with rich semantics, providing them with a way to "escape" into the full language to handle complex cases. Here I think Scheme could excel, but I don't know of any concrete examples where this is done.
IANAL, but I don't see how. If company X distributes a proprietary.so that can be loaded by a GPL program, who is violating copyright? Not the makers of the.so, as it is in no way derived from the GPL program.
Like you I am skeptical, but this is what RMS has told me:
...
our position is that writing a module designed to dynamically link with Emacs, and in any way specific to use in Emacs, is equivalent to linking statically: the module and Emacs form a combined program, and it must be possible to distribute the whole combined program under the GNU GPL.
The GPL makes (section 3) a special exception for "system" components, even (as I read it) if they have the form of a statically linked library. Also, the Linux kernel specifically exempts userspace programs.
It would have disastruous consequences.
That all depends on how you make the distinction between a software system and an external application. In the case of RCS, I'd say ci/co/rcsdiff etc. form a unified system, but a well-defined, commoditized library interface such as the Unix libc is logically separable even when linked statically.
I just think that the generally accepted interpretation (if there is one) of "work based on the Program" is too arbitrary.
You can't do this without restricting bundling in general, which would prohibit putting, say, netscape 4.x and linux on the same CD. Even then, they could distribute their enhancements independently, and nothing you put in your license can stop them, as their product is not a derivative work of yours, but simply something that works with it.
I agree that this touches on the issue of bundling. (Doesn't Aladdin Ghostscript have this kind of license?) But I'm not convinced that it wouldn't work. RMS claims that the GPL applies to enhancements in the form of dynamically loaded libraries, which may be distributed independently of a program. If he is right, I see no reason not to extend it to executable files that use a GPLed programs interfaces, be they command line or dynamic linker-based.
Well my flavor of ethics is not the same as yours. Please tell me: Would you sue me if I put your AL-only code and someone else's GPL-only code in the same program and distributed it (under GPL as the GPL would require)? Would the AL-only author be likely to win such a case?
I agree, and there is a lot of confusion among Slashdot readers because of the dual meaning of "Linux" as kernel and operating system. As far as the desktop is concerned, the OS and distribution as a whole are much more important than the kernel, and the GNU GPL does little to protect them from commercial attempts at subversion. A majority of the code on most Linux boxes is not covered by GPL, and the GPL limits its own application to code that is ``linked'' with GPL-covered code. Apparently linking means not involving a context switch or system call.
This is one of my pet peeves about the GPL: that the definition of modifications is too strict. If I write a set of programs and scripts that form a system when used together (for example, RCS), I'd like to be able to use the GPL to ensure that no company can enhance the system by adding more programs to my collection, and then release the enhancements as proprietary.
Perhaps such (inevitable) disputes should have their own section on the site. Developers and users would be motivated to go there out of boredom and morbid interest. Once there, they would be encouraged to look at the facts and send opinions about what remains to be done, if anything.
Slashdot Mirror
You mean few immediate benefits. C++'s most winsome feature in practice is its excellent support for C, making it in some cases a no-op and always a quick job to convert a C program to C++-compilable form. (NO MORE VARIABLES NAMED "new" AND "class", PLEASE! STOP THE MADNESS!!!!!!) The drawbacks I find in using C++ features are minor losses of portability and GDB support.
The presence or absence of XS code (i.e. code that can segfault) in a PerlFS filesystem won't affect whether the kernel goes kaboom. The Perl code that executes, and any XS it calls, is in user mode, protected space. PerlFS defines a protocol for the userland fs code to return syscall results. It can't crash the kernel unless PerlFS (the kernel module) is buggy.
PerlPERL (a Perl interpreter written in Perl) would actually be a great way to implement a better debugger than the current perl -d. It's not so farfetched. After all, Lisp in Lisp has been around a long time. Perl now has the necessary introspective ability, it's just a lot of work because the interpreter is so complex.
For several years the GNU project has touted its Guile Scheme interpreter as the future configuration/scripting language for GNU applications. To date, none of the major GNU programs (GCC, GDB, Emacs, Make) embed Guile. Do you expect this to change soon? Have you considered replacing Scheme with Java in this plan?
Thanks
-John
See Godel's Incompleteness Theorem.
You're right, though, from what I've heard, FLT was proved.
Does that make Corel's version a fork?
Bash is a program that lets you run other programs by typing their names. Explorer lets you run other programs by clicking with a mouse. Since they basically do the same thing (run programs), people refer to the Windows interface as a "shell" too. It took me a little effort to get my mind around this when I first heard it. :-)
Bash for Windows is cool, however.
24314
This is for kernel 2.2.14pre16.
Have a nice day!
You fail to note the influence of big money.
Somebody call a tax accountant, please. :-)
Oy, that reminds me I need to start doing mine. *moan*
So, let me get this right. Somebody is going to pay Chaney x dollars, where x >= 5000. Chaney is going to donate x + 2500 to a charity. Chaney deducts at least 7500 from his taxable income. Depending on his bracket, this guy could make out quite well.
Cool.
If the comparison is Red Hat versus Microsoft security, you're right. But the tone of the article suggests that they are comparing open source versus closed source, and the fact that open source systems tend to use software from one distributor is relevant.
They made it easy on MSFT. Windows systems tend to run more 3rd party software, in which Microsoft would not be expected to fix bugs. Whereas RedHat packages and distributes as many open source programs as it can. The comparison would have been fairer if they had included bugs in popular Windows programs from companies other than Microsoft (as well as stuff like Oracle for Linux, which would not be as much).
Also, they could consider that Debian systems can be configured to apply fixes automatically through cron and apt-get.
Nope, there are only 30 or so keywords in C. Of course, the libraries have more functions, but how much does a knowledge of English really help you remember what malloc or ioctl means?
I doubt it, but Perl supports this.
Nice paper (well, the 1/3 of it that I skimmed). The goal of a universal config file language is worthwhile, but it will not work if the language looks like Scheme. Quick and dirty languages succeed because they are quick. They are designed (using the word loosely) to require as little programmer time as possible, both to perceive the meaning of a script and to pound out something useful.
In other words, Scheme/Lisp is optimized for being read and written by the machine, while Shell, Perl, etc. are optimized for humans, and humans generally decide which language to use. Sure, if time were never an issue, we should all write beautiful code in a beautiful language like Lisp, but for small and ad-hoc jobs, it is unsuitable.
The ideal thing IMO would be an easy way to create little languages on top of a language with rich semantics, providing them with a way to "escape" into the full language to handle complex cases. Here I think Scheme could excel, but I don't know of any concrete examples where this is done.
Like you I am skeptical, but this is what RMS has told me:
The GPL makes (section 3) a special exception for "system" components, even (as I read it) if they have the form of a statically linked library. Also, the Linux kernel specifically exempts userspace programs.
That all depends on how you make the distinction between a software system and an external application. In the case of RCS, I'd say ci/co/rcsdiff etc. form a unified system, but a well-defined, commoditized library interface such as the Unix libc is logically separable even when linked statically.
I just think that the generally accepted interpretation (if there is one) of "work based on the Program" is too arbitrary.
I agree that this touches on the issue of bundling. (Doesn't Aladdin Ghostscript have this kind of license?) But I'm not convinced that it wouldn't work. RMS claims that the GPL applies to enhancements in the form of dynamically loaded libraries, which may be distributed independently of a program. If he is right, I see no reason not to extend it to executable files that use a GPLed programs interfaces, be they command line or dynamic linker-based.
Well my flavor of ethics is not the same as yours. Please tell me: Would you sue me if I put your AL-only code and someone else's GPL-only code in the same program and distributed it (under GPL as the GPL would require)? Would the AL-only author be likely to win such a case?
Thanks
-John
I agree, and there is a lot of confusion among Slashdot readers because of the dual meaning of "Linux" as kernel and operating system. As far as the desktop is concerned, the OS and distribution as a whole are much more important than the kernel, and the GNU GPL does little to protect them from commercial attempts at subversion. A majority of the code on most Linux boxes is not covered by GPL, and the GPL limits its own application to code that is ``linked'' with GPL-covered code. Apparently linking means not involving a context switch or system call.
This is one of my pet peeves about the GPL: that the definition of modifications is too strict. If I write a set of programs and scripts that form a system when used together (for example, RCS), I'd like to be able to use the GPL to ensure that no company can enhance the system by adding more programs to my collection, and then release the enhancements as proprietary.
but I took it as "Correct Me If I'm Wrong".
Minor correction. G++ has C++ extensions but of course neither they nor any part of G++ is "proprietary".
Perhaps such (inevitable) disputes should have their own section on the site. Developers and users would be motivated to go there out of boredom and morbid interest. Once there, they would be encouraged to look at the facts and send opinions about what remains to be done, if anything.
... I think.