With respect to Microsofts CLR-based Win32API, all I can say is that they are welcome to try. I do not think they will be successful though, particularly when their performance falls behind their competitors.
Under no circumstances can JIT-compiled code outperform a tightly-optimized C implementation. When you've squeezed the last drop of performance out of your CLR code, there will still be plenty of room left to squeeze in C. Likewise, when both are as tight as they can go, there will still be room left to optimize in assembly.
Java and C# provide language features that require more assembly instructions to complete. Bounds checking alone will do this, particularly in a tight loop. This is not a problem that needs to be resolved; Java was not designed to compete with C in speed. Tight loops that are performance sensitive should be optimizable at a level finer than what Java can provide, regardless of what the JIT compiler is doing. If you are not absolutely certain of this, compare the assembly for this C code and any JIT-compiled assembly code in Java:
int i,b=0,a[100]; void initialize(int*); void print(int); int main(void) { initialize(a); for (i=0; i<100; ++i) b += a[i]; print(b); return 0; }
You will find that no matter how tight your Java code is, the generated assembly will never reach this:
24 operations. That's compiled with gcc with -O2 optimization. Unroll the loop, and you'll go even faster. Discard the stack frame and use a char instead of an int for the index, and the code will be even shorter.
The byte code necessary to represent it may be smaller, but the assembly code will be much larger, may even involve more function calls, and even if completely inlined, would require at least one additional comparison and branch operation. Depending on how exceptions are implemented, it may also require setting up and tearing down an exception handler. It can't win, because at the very least it will be two operations longer than the equivalent C assembly.
I am happy that Java is finding a home in these devices, but these devices are just the same applets that I described previously. What is the underlying operating system written in? What is the underlying Java implementation implemented in? Again, how well will Java address the problem of the next decade?
I didn't call them "passing languages;" I would however refer to them as niche languages. Like Lisp, Ada, and FORTRAN, they cover certain problem spaces. Just about any programming problem can be implemented in these languages with the associated penalties for specific language features.
FORTRAN rocks for computation, but you can still beat it in assembly. The point is, you don't want to; it does a good enough job. More importantly, FORTRAN will not outperform C in non-computational implementations. At the best, it can achieve equivalent speeds. Per the example above, FORTRAN would probably unroll the entire loop, reorder the operations to keep the pipelines full, and employ multiple registers so the pipelines can work in parallel. There may even be a single operation that will perform the whole summation in a shot. FORTRAN likes that stuff. C won't go that extra mile for you because optimizing numeric computation is not what C was designed for.
All the reasons you dislike C++ are the reasons that I'm a fan. I use many languages, but C++ in particular gives me more leverage overall.
1. Operator overloading - mandatory for best use of templated functions and algorithms. If people make poor decisions with respect to what they overload, that's hardly a problem with the language. I would consider not being able to overload an operator a problem with the language.
2. References are required for any function that returns a "left-hand value." If that phrase does not mean anything to you, then you are not actually discussing C++ references at all, merely glorified pointers. Since left-hand values cannot be NULL by definition, your misunderstanding with regard to their purpose seems likely.
3. Memory mangement is identical to that of C. The addition of the new and delete operators is nothing remarkable - they just call malloc and free. They are also overrideable on a per-class basis if that is not good enough for you. If by "memory management" you mean "takes complete control of object lifetime" than no, C++ thankfully let's you do whatever you want with your objects.
4. Templates are very powerful. They allow with a single declaration the ability to generate code optimized for a given problem. If you are complaining that the mechanism is too powerful, well, some of us like the extra capacity.
5. As for multiple inheritence, I use it frequently. Some types of inheritence are unfeasible, some are unimplementable without substantial performance penalties, and most are simply doable. If you're having trouble, and your inheritance tree is sound, then file a bug report for your C++ compiler.
Genuinely, most of your complaints misrepresent C++ as something it's not, namely a high level language. If C is one step from assembly, then C++ is maybe a step and a half. That's by design.
If I want rapid prototyping, I'll use PHP or Python. I'm not sure what Java gets me other than a sandbox and some friendly exceptions when things go wrong. That's nice, but I don't write weak code, so all that padded insulation does me no good at all.
High-level languages come and go because they are written to solve the problem of the decade. For COBOL it was record management and batch computation. For Java and C#, it's applets, serverlets, processlets, and sandboxed code. What will tomorrow bring?
By contrast, C is still solving the problem of the century -- how to write portable assembly, and assembly is still solving the general problem of computing -- how to get the most processing for the least memory and time. Java and C# can't touch this, nor was this the purpose for which they were designed.
Only the state of Maryland and possibly Virginia has a law (UCITA) that allow EULA's to have any legal standing. Whether the aforementioned "contract" constitutes a EULA is a whole different issue. In my opinion, it does not. Purchasing software and discovering that it will not install afterwards without a click-thru agreement is non-binding due to Doctrine of First Sale. However, agreeing to a contract before downloading music may well be binding.
I realize that you are trying to be funny, but you appear to be confused on one important point. OSS hackers are not overly concerned with the cost of the aforementioned text. They are concerned with the freedom to use it without constraints. It's a human rights issue, not a money issue.
This is the exact same comment he posted to the last article about IPv6. That comment was modded 0, Troll. Check his post history at January 11th. Also notice that in the last 15 posts, three of them are sitting at -1 and another two are moderated troll.
If you want a decent rebuttal of his silly argument, just go back to his previous post.
I see where you're coming from. All I'm saying is that you cannot have a privilege separated system without the hardware-level protection regardless of what language you're working in. If it's possible to have unsafe code running, you need the MMU. With the following exception, I'm in agreement with everything you just said.
Establishing code validity through code signing is much more complicated than you imply. Since that's the subject of some of my research, I'm really not going to hash it out here, but basically you can sign something to guarantee it has not changed, but you cannot sign something to guarantee that it is valid code without establishing a trust relationship with the compiler author. That's a long way to go to avoid using an MMU.
As a completely incidental aside, my account name HopeOS refers to an operating system that does have signed binaries and checked code can run in the same process space provided that it is signed by the same key. All other processes must use formal IPC (usually page-level hyperqueues) to transfer data. This is still a work in progress, but the idea is to allow foreign binaries to execute on a machine with the privilege level of the author, not the current user.
I didn't write the paper, so I can't really expound on the subject, but my own experience with network issues suggests that your statement is true if your OC-3 is normally under-utilized, but in heavy congestion, would not be as responsive to changes in the congestion pattern.
This is to say that if your window sizes are already set to large values you can mitigate the long ramp time, but when congestion occurs, you'll still encounter the reduction in bandwidth, and unless your implementation is specifically tweaked to return to the large window sizes immediately, you'll have to wait it out. The BIC-TCP algorithm just takes larger steps and reacts more quickly.
I think you're proving my points for me. The statement was that the kernel/user space boundary is required for security reasons. The effectiveness of any specific implementation is moot.
Code signing is not a valid solution since you are assuming the signer is not malicious.
Finally, if your implementation of lisp allows you to break out to assembly, then you're already out of the sandbox, meaning that is possible to run unsafe code. If that's the case, then your argument is defeated. Either the code is all safe and there is a performance barrier or the code is unsafe and there is not.
I was specifically objecting to this statement: If you use a safe language, you don't need memory protection, or even a kernel/userspace boundry for that matter. You get completely fine-grained protection for all objects. It may be correct in theory but in practice it is not true. Sandboxes can be circumvented. Compiled code, whether from lisp source or C, can be modified such that it compromises the system. This is the distinction between an academic problem and a real-world engineering problem. Bad things happen, even when best efforts are made to ensure against. Type-safety is certainly a Good Thing, but it's not the salvation of the software industry you implied in the previous post.
Yes, lisp can be compiled pretty tightly. It can also do wonderful things, including optimizing the implementation of algorithms, even under different runtime conditions. C++ template classes provide similar optimization at compile time, but that's neither here nor there. When putting C and lisp head to head, C will always win because it is always possible to take C to the next level - ultimately to assembly itself - if necessary. With lisp, the point of diminishing returns is reached sooner and is unbreachable. That alone makes it unsuitable for certain classes of problems.
Lisp is, like many other academic languages, very capable at handling specific sets of problems given unfettered resources in ideal conditions. When the conditions get dicey, many of the benefits like uniform memory management, the ability to defer execution of code until absolutely necessary, etc. become impediments when the memory manager enters a worst-case mode of operation or the given execution order begins to cause problems.
On a final note, although I do not program in Ada, I am of the opinion that a useful compiler should be able to generate raw assembly with the efficiency of C and optionally validate code at compile-time to ensure that it is strictly mathematically sound. Obviously, C does not do this at present.
First, the actual paper is more informative. The crux of the argument is as follows.
If you have a fat pipe, say 1 to 10GB/s, standard TCP will not fully utilize the bandwidth because the congestion control algorithm throttles the rate. As packets move and there are no errors, the rate increases, but not nearly fast enough. In particular, it takes 1.5 hours of error-free data transfer to reach full capacity, and a single error will cut the connection's bandwidth in half.
BIC-TCP uses a different algorithm for congestion control that is more effective at these speeds.
This is precisely the kind of thing that separates computer science, that division of mathematics that deals with algorithms and computational theory, from engineering which deals with real-world solutions to real-world implementation problems.
If you think that implementing a program in lisp is going to be so inherently secure that there is no need for hardware-level page protection, you are sorely mistaken. Malicious code exists, even in Lisp.
Outside of C and assembly, nothing is comparable for speed. If you're seeing similar execution times from lisp and Java, then you're doing something so trivial as to be uninteresting or something is wrong with your C implementation.
One of the big interview questions that I ask involves the difference between virtual and member functions. Maybe one in ten applicants comes even close to answering the question correctly. Of those, less than half know what a vtable is. We use this question as a disqualifier, but we have hired some of these people as junior programmers from time to time. Interestingly enough, many of those who answered correctly still could not program in C++ to save their lives. Having a thorough understanding of the compiler generated implementation is not the same as having a good background of algorithms or experience with cost-performance balances in implementation. For every sin I've witnessed in C++, I can recall at least as many in C.
The commands are for the computer to interpret, not the user. If my English scripts cannot call Japanese programs, that would be a real problem.
As for the user, if I sit down at a computer that is localized in French, I can still use it because we all agree on what the command names are, regardless of what language we speak. "cd" is not "change directory," it's the mnemonic for the command that changes the directory. I don't care if it's zk or zmienkatalog, so long as it's the same. If I want something else I can alias it. By way of example, I logged into my normal account using Croatian as the localization context. Everything works as expected, but I can't read the error messages.
$ ls -V ls: nedozvoljena opcija -- V
OK. Let's see what languages are supported on this machine.
No problem. English, Japanese, and Croatian. My Japanese is not much better than my Croatian, so let's try English.
$ LANG=en ls -V ls: invalid option -- V
Oh... that wasn't too bad. Let's just set the language for English from here on out though.
$ export LANG=en
By ensuring that all the commands and protocols are the same, Japanese, Croatian, and English users of this machine can all use the same programs, and most importantly, their programs can interact as well.
Your statements remind me of those made by people who rally behind their first amendment rights and then decry other people's exercise of free speech.
If you stand for copyrights and the rights of the author then you should honor the GPL as a statement of the author's intent. If you challenge the legitimacy of that exercise, then you are challenging the legitimacy of copyright law itself. A reasonable man cannot do both at the same time. Your position appears to be that the world must honor your copyrights, but the exercise of their copyrights should be limited to that which conveniences you. That is not a defensible position.
I have yet to see any situation in which an author was coerced into releasing their software for free. Nor have I seen any situation in which 12 year olds trading Britney Spears MP3's have invoked the GPL as the basis for renewed discussion on the legitimacy of copyright. If anything, it's brought up the inefficiencies of the distribution system, both for the dissemination of content and for the artist's remuneration.
Your only point of evidence appears to be that a culture of content sharing is growing. If that content is shared legally and according to the author's intent, where exactly is your complaint?
Naturely, this must be so since you say it is so, but forgive me for being skeptical, particularly since you offer no evidence. The artificial scarcity of information is coming to an ignoble end. I hope that your fortunes are not tied to the wrong side of history. You can no more prevent the people from sharing than you can prevent them from talking to one another or peacefully assembling. If you try to stop them, they will revolt.
You appear to be confused as for what it is precisely that you charge people money.
No one is saying that you should not be able to charge for your service as a software developer. My livelihood, as yours, depends on the ability to charge for the time that I spend solving other people's software problems.
More to the point, if we cannot make a living because all the algorithms and best-practices necessary for our work are restricted by patents, then we have only a few choices. We can starve. We can throw in the towel and become house slaves to some multi-national corporation. We can find another line of business. Finally, and most assuredly, we can stand up and defend our rights.
When Eben Moglin talks about "guys with little paste-it labels", he is talking about the people that threaten our livelihood as independent software developers, small companies, and individuals. He's talking about preserving your Civil Rights.
Given the number of Windows machines in my office that have required complete reinstallation after a bad Windows Update, I'd say we've spent many thousands of dollars in lost development time. Think developers not working * average wage * hours twiddling thumbs waiting for reinstallation for the bigger picture.
My desktop XP is on its fifth install. I have compressed images of the XP partitions saved on the network so I can restore the entire system state rather than reinstall from scratch.
This may come off as overly aggressive, and for that I apologize in advance, but people who haven't adminstrated *nix boxes in large-scale deployments often fail to recognize that there's a delibrate method behind the file system.
Each one of those directories has a very distinct purpose; it didn't happen that way by accident. The difference between/bin,/usr/bin, and/usr/local/bin may seem trivial to you as a user, but from an administrative vantage point, they are very important.
In single user mode with an ailing system, the most you may successfully get booted is the root partition. You have at your disposal only/bin,/sbin, and/lib. That means that all tools necessary for fixing the system must be there including all kernel modules and shared libraries. It must also be possible for this device to be completely read-only, possibly even residing in firmware. Installing an application in/bin while its companion libraries are on/usr/lib would be folly since the/usr partition may be completely inaccessible. You may notice that some distributions install a stripped-down, statically-linked version of vi in/bin and a full-featured, shared-library version in/usr/bin. Now you know why.
Once booted and all the necessary kernel modules are loaded from/lib, the remaining partitions can be mounted. On a single-user machine, the/usr directory may be on the same partition as root. Often times it has its own partition. But for large-scale deployments, the entire/usr partition may be on a network share. It may also be on a CDROM. Installing software to/usr may be impossible or require a site-wide change. Secondly, it won't do to have software trying to write data to this partition, so programs and data are always separated. All data goes to/var which is normally a machine-specific mount. Also, a diskless machine may mount/var on a ram disk.
To address software installed on individual machines, we use the/usr/local directory. If/usr is read-only,/usr/local is mounted to a separate writeable volume. All software not packaged by the distributor or site administrator belongs in/usr/local if it's machine-wide and in the user's home directory if not. Other conventions exist, including the use of/opt, but that's a site policy issue.
So that's that. Given any package, it is a simple matter to determine if its executables go to/bin,/usr/bin, or/usr/local/bin. Libraries go to the equivalent lib directory. Header files to the equivalent include directory. Manual pages to man. Cross-application data to share. All application data goes to/var including log files and databases. All temporary files go to/tmp. If you follow these rules, there's no end to the configurations you can create. Violate any single rule and you have a machine that cannot be recovered, applications that cannot be shared site-wide, machine-wide, or between users, and data that cannot be conveniently backed up. Sorta like Windows.
You specifically address the issue of plug-ins, but even having an application located at/usr/software/netscape won't help if the installer is looking for/usr/software/mozilla. This class of problem has been solved many times over with package configuration files and scripts. The responsibility is mainly that of the distribution maintainers to facilitate this. If it's not happening for your distro, get satisfaction, or move to a distro that cares.
That said, the browser plug-in issue annoys me, too.
Slashdot Mirror
Under no circumstances can JIT-compiled code outperform a tightly-optimized C implementation. When you've squeezed the last drop of performance out of your CLR code, there will still be plenty of room left to squeeze in C. Likewise, when both are as tight as they can go, there will still be room left to optimize in assembly.
Java and C# provide language features that require more assembly instructions to complete. Bounds checking alone will do this, particularly in a tight loop. This is not a problem that needs to be resolved; Java was not designed to compete with C in speed. Tight loops that are performance sensitive should be optimizable at a level finer than what Java can provide, regardless of what the JIT compiler is doing. If you are not absolutely certain of this, compare the assembly for this C code and any JIT-compiled assembly code in Java:
You will find that no matter how tight your Java code is, the generated assembly will never reach this:
24 operations. That's compiled with gcc with -O2 optimization. Unroll the loop, and you'll go even faster. Discard the stack frame and use a char instead of an int for the index, and the code will be even shorter.
The byte code necessary to represent it may be smaller, but the assembly code will be much larger, may even involve more function calls, and even if completely inlined, would require at least one additional comparison and branch operation. Depending on how exceptions are implemented, it may also require setting up and tearing down an exception handler. It can't win, because at the very least it will be two operations longer than the equivalent C assembly.
I am happy that Java is finding a home in these devices, but these devices are just the same applets that I described previously. What is the underlying operating system written in? What is the underlying Java implementation implemented in? Again, how well will Java address the problem of the next decade?
I didn't call them "passing languages;" I would however refer to them as niche languages. Like Lisp, Ada, and FORTRAN, they cover certain problem spaces. Just about any programming problem can be implemented in these languages with the associated penalties for specific language features.
FORTRAN rocks for computation, but you can still beat it in assembly. The point is, you don't want to; it does a good enough job. More importantly, FORTRAN will not outperform C in non-computational implementations. At the best, it can achieve equivalent speeds. Per the example above, FORTRAN would probably unroll the entire loop, reorder the operations to keep the pipelines full, and employ multiple registers so the pipelines can work in parallel. There may even be a single operation that will perform the whole summation in a shot. FORTRAN likes that stuff. C won't go that extra mile for you because optimizing numeric computation is not what C was designed for.
So to answer yo
All the reasons you dislike C++ are the reasons that I'm a fan. I use many languages, but C++ in particular gives me more leverage overall.
1. Operator overloading - mandatory for best use of templated functions and algorithms. If people make poor decisions with respect to what they overload, that's hardly a problem with the language. I would consider not being able to overload an operator a problem with the language.
2. References are required for any function that returns a "left-hand value." If that phrase does not mean anything to you, then you are not actually discussing C++ references at all, merely glorified pointers. Since left-hand values cannot be NULL by definition, your misunderstanding with regard to their purpose seems likely.
3. Memory mangement is identical to that of C. The addition of the new and delete operators is nothing remarkable - they just call malloc and free. They are also overrideable on a per-class basis if that is not good enough for you. If by "memory management" you mean "takes complete control of object lifetime" than no, C++ thankfully let's you do whatever you want with your objects.
4. Templates are very powerful. They allow with a single declaration the ability to generate code optimized for a given problem. If you are complaining that the mechanism is too powerful, well, some of us like the extra capacity.
5. As for multiple inheritence, I use it frequently. Some types of inheritence are unfeasible, some are unimplementable without substantial performance penalties, and most are simply doable. If you're having trouble, and your inheritance tree is sound, then file a bug report for your C++ compiler.
Genuinely, most of your complaints misrepresent C++ as something it's not, namely a high level language. If C is one step from assembly, then C++ is maybe a step and a half. That's by design.
If I want rapid prototyping, I'll use PHP or Python. I'm not sure what Java gets me other than a sandbox and some friendly exceptions when things go wrong. That's nice, but I don't write weak code, so all that padded insulation does me no good at all.
-Hope
C, C++, and ASM are low-level languages.
COBOL, Java, and C# are high-level languages.
High-level languages come and go because they are written to solve the problem of the decade. For COBOL it was record management and batch computation. For Java and C#, it's applets, serverlets, processlets, and sandboxed code. What will tomorrow bring?
By contrast, C is still solving the problem of the century -- how to write portable assembly, and assembly is still solving the general problem of computing -- how to get the most processing for the least memory and time. Java and C# can't touch this, nor was this the purpose for which they were designed.
-Hope
Only the state of Maryland and possibly Virginia has a law (UCITA) that allow EULA's to have any legal standing. Whether the aforementioned "contract" constitutes a EULA is a whole different issue. In my opinion, it does not. Purchasing software and discovering that it will not install afterwards without a click-thru agreement is non-binding due to Doctrine of First Sale. However, agreeing to a contract before downloading music may well be binding.
-Hope
I realize that you are trying to be funny, but you appear to be confused on one important point. OSS hackers are not overly concerned with the cost of the aforementioned text. They are concerned with the freedom to use it without constraints. It's a human rights issue, not a money issue.
-Hope
IPv6: Not Ready for Prime Time.
This is the exact same comment he posted to the last article about IPv6. That comment was modded 0, Troll. Check his post history at January 11th. Also notice that in the last 15 posts, three of them are sitting at -1 and another two are moderated troll.
If you want a decent rebuttal of his silly argument, just go back to his previous post.
It has a score of zero for trolling.
Check his post history. Check his name. Review the content. He doesn't know what he's talking about. Leave it alone. Thank you.
I see where you're coming from. All I'm saying is that you cannot have a privilege separated system without the hardware-level protection regardless of what language you're working in. If it's possible to have unsafe code running, you need the MMU. With the following exception, I'm in agreement with everything you just said.
Establishing code validity through code signing is much more complicated than you imply. Since that's the subject of some of my research, I'm really not going to hash it out here, but basically you can sign something to guarantee it has not changed, but you cannot sign something to guarantee that it is valid code without establishing a trust relationship with the compiler author. That's a long way to go to avoid using an MMU.
As a completely incidental aside, my account name HopeOS refers to an operating system that does have signed binaries and checked code can run in the same process space provided that it is signed by the same key. All other processes must use formal IPC (usually page-level hyperqueues) to transfer data. This is still a work in progress, but the idea is to allow foreign binaries to execute on a machine with the privilege level of the author, not the current user.
-Hope
I didn't write the paper, so I can't really expound on the subject, but my own experience with network issues suggests that your statement is true if your OC-3 is normally under-utilized, but in heavy congestion, would not be as responsive to changes in the congestion pattern.
This is to say that if your window sizes are already set to large values you can mitigate the long ramp time, but when congestion occurs, you'll still encounter the reduction in bandwidth, and unless your implementation is specifically tweaked to return to the large window sizes immediately, you'll have to wait it out. The BIC-TCP algorithm just takes larger steps and reacts more quickly.
-Hope
I think you're proving my points for me. The statement was that the kernel/user space boundary is required for security reasons. The effectiveness of any specific implementation is moot.
Code signing is not a valid solution since you are assuming the signer is not malicious.
Finally, if your implementation of lisp allows you to break out to assembly, then you're already out of the sandbox, meaning that is possible to run unsafe code. If that's the case, then your argument is defeated. Either the code is all safe and there is a performance barrier or the code is unsafe and there is not.
-Hope
I was specifically objecting to this statement: If you use a safe language, you don't need memory protection, or even a kernel/userspace boundry for that matter. You get completely fine-grained protection for all objects. It may be correct in theory but in practice it is not true. Sandboxes can be circumvented. Compiled code, whether from lisp source or C, can be modified such that it compromises the system. This is the distinction between an academic problem and a real-world engineering problem. Bad things happen, even when best efforts are made to ensure against. Type-safety is certainly a Good Thing, but it's not the salvation of the software industry you implied in the previous post.
Yes, lisp can be compiled pretty tightly. It can also do wonderful things, including optimizing the implementation of algorithms, even under different runtime conditions. C++ template classes provide similar optimization at compile time, but that's neither here nor there. When putting C and lisp head to head, C will always win because it is always possible to take C to the next level - ultimately to assembly itself - if necessary. With lisp, the point of diminishing returns is reached sooner and is unbreachable. That alone makes it unsuitable for certain classes of problems.
Lisp is, like many other academic languages, very capable at handling specific sets of problems given unfettered resources in ideal conditions. When the conditions get dicey, many of the benefits like uniform memory management, the ability to defer execution of code until absolutely necessary, etc. become impediments when the memory manager enters a worst-case mode of operation or the given execution order begins to cause problems.
On a final note, although I do not program in Ada, I am of the opinion that a useful compiler should be able to generate raw assembly with the efficiency of C and optionally validate code at compile-time to ensure that it is strictly mathematically sound. Obviously, C does not do this at present.
-Hope
First, the actual paper is more informative. The crux of the argument is as follows.
If you have a fat pipe, say 1 to 10GB/s, standard TCP will not fully utilize the bandwidth because the congestion control algorithm throttles the rate. As packets move and there are no errors, the rate increases, but not nearly fast enough. In particular, it takes 1.5 hours of error-free data transfer to reach full capacity, and a single error will cut the connection's bandwidth in half.
BIC-TCP uses a different algorithm for congestion control that is more effective at these speeds.
End of news flash.
-Hope
This is precisely the kind of thing that separates computer science, that division of mathematics that deals with algorithms and computational theory, from engineering which deals with real-world solutions to real-world implementation problems.
If you think that implementing a program in lisp is going to be so inherently secure that there is no need for hardware-level page protection, you are sorely mistaken. Malicious code exists, even in Lisp.
Outside of C and assembly, nothing is comparable for speed. If you're seeing similar execution times from lisp and Java, then you're doing something so trivial as to be uninteresting or something is wrong with your C implementation.
-Hope
One of the big interview questions that I ask involves the difference between virtual and member functions. Maybe one in ten applicants comes even close to answering the question correctly. Of those, less than half know what a vtable is. We use this question as a disqualifier, but we have hired some of these people as junior programmers from time to time. Interestingly enough, many of those who answered correctly still could not program in C++ to save their lives. Having a thorough understanding of the compiler generated implementation is not the same as having a good background of algorithms or experience with cost-performance balances in implementation. For every sin I've witnessed in C++, I can recall at least as many in C.
-Hope
As for the user, if I sit down at a computer that is localized in French, I can still use it because we all agree on what the command names are, regardless of what language we speak. "cd" is not "change directory," it's the mnemonic for the command that changes the directory. I don't care if it's zk or zmienkatalog, so long as it's the same. If I want something else I can alias it. By way of example, I logged into my normal account using Croatian as the localization context. Everything works as expected, but I can't read the error messages.OK. Let's see what languages are supported on this machine.
No problem. English, Japanese, and Croatian. My Japanese is not much better than my Croatian, so let's try English.
Oh... that wasn't too bad. Let's just set the language for English from here on out though.By ensuring that all the commands and protocols are the same, Japanese, Croatian, and English users of this machine can all use the same programs, and most importantly, their programs can interact as well.
-Hope
There is also this: IPX Online. Some mild discussion at groklaw about it midway down the page.
-Hope
-Hope
Your statements remind me of those made by people who rally behind their first amendment rights and then decry other people's exercise of free speech.
If you stand for copyrights and the rights of the author then you should honor the GPL as a statement of the author's intent. If you challenge the legitimacy of that exercise, then you are challenging the legitimacy of copyright law itself. A reasonable man cannot do both at the same time. Your position appears to be that the world must honor your copyrights, but the exercise of their copyrights should be limited to that which conveniences you. That is not a defensible position.
I have yet to see any situation in which an author was coerced into releasing their software for free. Nor have I seen any situation in which 12 year olds trading Britney Spears MP3's have invoked the GPL as the basis for renewed discussion on the legitimacy of copyright. If anything, it's brought up the inefficiencies of the distribution system, both for the dissemination of content and for the artist's remuneration.
Your only point of evidence appears to be that a culture of content sharing is growing. If that content is shared legally and according to the author's intent, where exactly is your complaint?
-Hope
Naturely, this must be so since you say it is so, but forgive me for being skeptical, particularly since you offer no evidence. The artificial scarcity of information is coming to an ignoble end. I hope that your fortunes are not tied to the wrong side of history. You can no more prevent the people from sharing than you can prevent them from talking to one another or peacefully assembling. If you try to stop them, they will revolt.
-Hope
You appear to be confused as for what it is precisely that you charge people money.
No one is saying that you should not be able to charge for your service as a software developer. My livelihood, as yours, depends on the ability to charge for the time that I spend solving other people's software problems.
More to the point, if we cannot make a living because all the algorithms and best-practices necessary for our work are restricted by patents, then we have only a few choices. We can starve. We can throw in the towel and become house slaves to some multi-national corporation. We can find another line of business. Finally, and most assuredly, we can stand up and defend our rights.
When Eben Moglin talks about "guys with little paste-it labels", he is talking about the people that threaten our livelihood as independent software developers, small companies, and individuals. He's talking about preserving your Civil Rights.
-Hope
When the machine blue screens on reboot, there's not much left to do but reinstall.
Given the number of Windows machines in my office that have required complete reinstallation after a bad Windows Update, I'd say we've spent many thousands of dollars in lost development time. Think developers not working * average wage * hours twiddling thumbs waiting for reinstallation for the bigger picture.
My desktop XP is on its fifth install. I have compressed images of the XP partitions saved on the network so I can restore the entire system state rather than reinstall from scratch.
-Hope
This may come off as overly aggressive, and for that I apologize in advance, but people who haven't adminstrated *nix boxes in large-scale deployments often fail to recognize that there's a delibrate method behind the file system.
/bin, /usr/bin, and /usr/local/bin may seem trivial to you as a user, but from an administrative vantage point, they are very important.
/bin, /sbin, and /lib. That means that all tools necessary for fixing the system must be there including all kernel modules and shared libraries. It must also be possible for this device to be completely read-only, possibly even residing in firmware. Installing an application in /bin while its companion libraries are on /usr/lib would be folly since the /usr partition may be completely inaccessible. You may notice that some distributions install a stripped-down, statically-linked version of vi in /bin and a full-featured, shared-library version in /usr/bin. Now you know why.
/lib, the remaining partitions can be mounted. On a single-user machine, the /usr directory may be on the same partition as root. Often times it has its own partition. But for large-scale deployments, the entire /usr partition may be on a network share. It may also be on a CDROM. Installing software to /usr may be impossible or require a site-wide change. Secondly, it won't do to have software trying to write data to this partition, so programs and data are always separated. All data goes to /var which is normally a machine-specific mount. Also, a diskless machine may mount /var on a ram disk.
/usr/local directory. If /usr is read-only, /usr/local is mounted to a separate writeable volume. All software not packaged by the distributor or site administrator belongs in /usr/local if it's machine-wide and in the user's home directory if not. Other conventions exist, including the use of /opt, but that's a site policy issue.
/bin, /usr/bin, or /usr/local/bin. Libraries go to the equivalent lib directory. Header files to the equivalent include directory. Manual pages to man. Cross-application data to share. All application data goes to /var including log files and databases. All temporary files go to /tmp. If you follow these rules, there's no end to the configurations you can create. Violate any single rule and you have a machine that cannot be recovered, applications that cannot be shared site-wide, machine-wide, or between users, and data that cannot be conveniently backed up. Sorta like Windows.
/usr/software/netscape won't help if the installer is looking for /usr/software/mozilla. This class of problem has been solved many times over with package configuration files and scripts. The responsibility is mainly that of the distribution maintainers to facilitate this. If it's not happening for your distro, get satisfaction, or move to a distro that cares.
Each one of those directories has a very distinct purpose; it didn't happen that way by accident. The difference between
In single user mode with an ailing system, the most you may successfully get booted is the root partition. You have at your disposal only
Once booted and all the necessary kernel modules are loaded from
To address software installed on individual machines, we use the
So that's that. Given any package, it is a simple matter to determine if its executables go to
You specifically address the issue of plug-ins, but even having an application located at
That said, the browser plug-in issue annoys me, too.
-Hope