That a living cell is defined as a cell that contains genetic properties (i.e: ones that are carried on to the next generation), thus allowing evolution and other properties of life to form.
The non-living cells would then be micro-mechanisms that contain some of the functionality of living cells, but not genetic properties, and as such they are not "alive", cannot evolve and cannot pass qualities to a "next generation". These non-living cells, however, could be great platforms for living cells to be created "in" (or in place of?).
I wasn't referring to the acts of 1962, but to the trade of map-making of the consitution-writing days. Map-makers were signing NDA's of secrecy so as to make money from their work. Copyright was created as a means to allow making works available while still being protected.
I'm not misinterpreting the constitution - It explicitly states that the copyrights should have limited times, and in the discussions prior to it, they explain it is because copyrights, as limitations on freedom, are the necessary evil - that should be minimized.
No, people were not inspired by a film just as much before and after it entered the public domain - because fewer people had access to the content. Now, everyone has free access to the content, and anyone can be inspired by it.
Film preservation is easy when stored as digital content.
You seem to think I'm claiming that everything-in-the-public-domain promotes science and useful arts more, simply because it does so immediately. But ofcourse I never claimed this, and only superficial analysis can result in such a flawed conclusion.
The longer it takes something to enter the public domain, the more incentive it gives to creating works, but the less valuable these works are to society (Since people have limited freedom in regard to those works). The shorter it takes something to enter the public domain, the less incentive there is to create it, but the more valuable creations are to society (the information is free to inspire everyone, and anyone can pass it on to anyone to learn from). For example, a teacher can copy meterial from the public domain to all of his students freely, to teach them about music, or novel writing, or such. On the contrary, he cannot require them to buy a book, or a music piece, or a movie.
Thus, a balance should be found, to maximize incentive and the value of the work to society. The original balance that was decided was 14 years (plus an additional optional 14 years if the author was still alive). Copyrights have been prolonged again and again since, and they are now Author's life + 150 years, which is an absurd amount of time, obviously contradicting the "For Limited Times" phrase in the constitution.
That statement doesn't make a whole lot of sense. US law, and the laws of the various European states, are based on traditions of law that came before them. A significant portion of US law, for example, was inspired by Iroquois law. And a significant portion of the various European bodies of law was inspired by US law. So there's a direct connection between the Iroquois tradition of intellectual property going back a thousand years and the copyright law that governs this very comment today. The connection is less direct than you may think. The copyright law was presented in the constitution of the united states after independent discussion and thought, and as a solution to their own intellectual output problems (secrecy and NDA's of the times).
Absolutely it does. It promotes science and the useful arts in two ways. First, it attaches a profit motive to the creation of new inventions, which, as history has demonstrated, promotes the heck out of science and the useful arts. You have a different view of what promotes science and useful arts than what I, and the framers of the US constitution have/had in mind. The idea is that Copyright is for limited times and only in this case is it promoting science and useful arts - because only works in the public domain are promoting science and useful arts. Works that are not accessible to society and are not readily available to inspire and be learned from, are not promoting science and useful arts.
Copyrights, as the US consitution defined them, promote Science and Useful Arts by securing for limited times exclusive copying rights to inventors - and then placing them under the public domain.
Second, it promotes original work. If person X wants to develop an invention based on IP owned by person Y, and person X doesn't want to pay person Y's asking price for a license, then person X will go out there and find a new and different way to accomplish the same goal. That's a good thing for science and the useful arts. It seems you are confusing copyrights and patents here. Copyrights are on expressions of ideas, not on ways to do things. So if person Y wants to express the same idea, he merely has to re-express it in a different way - not find a different idea.
(While we're on the subject, please explain to me how the entry of "Steamboat Willie" into the public domain will do anything to promote science or the useful arts. I've never really understood that assertion.) I don't think that anything is about to enter the public domain due to the time limit in the next 25 years or so, because of the reoccuring retro-active extension of the copyright length. This means that any release into the public domain is probably going to be meterial worthless to its creator - and likely to be worthless to society.
I've never before heard of this specific content, but now that I've googled to find what that content is all about - its enterance into the public domain may help artists be inspired and learn from these works, obviously.
Did you use the "Preview" button? Are you seriously saying that you believe the concept of property ought to be abolished? I'll just assume that you misspoke, and I look forward to reading your clarification.
I was talking about the idea of "Intellectual Property", giving exclusive copying rights to individuals indefinitely, limiting the freedom of everyone else with no intention of giving it back to them (with the enterance into the public domain), as a concept which should be abolished.
In any case, remember that we're not talking about pure intellectual property here. These are not simply ideas. These are works, created through the effort of individuals. Just as I wouldn't expect my exclusive right to sit in this chair-- which I bought, but I could just as well have built myself-- to end after 14 years, neither would I expect that my rights to "Steamboat Willie," the film, would end after 14 years. (Assuming I was the person who owned them, that is.)
The idea is - that once you choose to release and distribute what you have created, the information naturally "wants" to propogate for the education and advancement of human kind. Disallowing its propogation is evil (yes, necessary evil), and thus should be limited to the minimum that is required to encourage creation.
I don't believe in any natural inherent "ownership rights" of the universe or such - I only believe those which contribute to society as a whole. If a 14 year period copyright is enough to get people to create meterial - and still allow people virtually unlimited freedom to distribute information, its the best of both worlds.
When you remember that copyright protects not just ideas but actual works as well, it sort of throws the whole idea of an expiration date on rights into question.
I disagree - because I don't believe in inherent rights as you do.
It may not be recent globally, but it is recent in the states and Europe.
Again - making 'property' out of it is bad - because it doesn't advacne the real goal of copyrights - which is Promoting Science and Useful Arts.
'Property' implies it never enters the public domain, and is under the permanent and complete control of someone - which is a concept which should be abolished.
Equating intellectual output with "property" is a rather recent thing, done by strong copyright holders who want to get "property rights" (permanence, etc.) on their intellectual output. I think that such ideas should indeed be abolished.
Also, while I do believe that it is probably a bad idea to abolish copyrights altogether, I am not at all sure of that.. I am too agnostic to claim to know this -- however I am pretty firm in my belief that restoring copyrights to their original proportion would be beneficial for society - and may even eliminate a few monopolies.
Copyrights are draconian remainders of the original laws that existed centuries ago. This is why most/.'ers today do not wish to support them. Spam is simply an intrusion.
Thus, from a utility point of view, spam is evil, and copyright infringement isn't.
If Copyright laws were reestablished as they were centuries ago, with reasonable limited times, and requirement of publishing the works (The source code, etc.), then/.'ers may support them.
Lastly, there is a case to be made against the RIAA/MPAA/etc use of copyright to try and grasp the remainder of their market by the nails and the teeth, using primitive distribution technology and techniques that made them money in the past, simply because they aren't willing to move to a new model of making money, with the rest of the world.
People do not want to stay behind, wasting car fuel to go and get a bunch of data bits, when those bits can more efficiently travel through their internet connections.
On a tangent, that's why I love Perl. It's like English: it's so flexible and can be so cryptic that a bad programmer can quickly create a mess. However, following the analogy with English, a good programmer can make a masterpiece in short time.
Try Python, it avoids the first property (making it easy to write cryptic code), while still allowing the latter (letting good programmers make masterpieces in short times).
I can't wait to see Perl 6 in action. Once they improve OOP style Perl, I'm set.
Universities are not about teaching you how to work. They are supposed to teach you how to learn for yourself. They should cover the basics of as many areas as possible - and this includes programming and algorithms. This is why some language must be learned, or those areas can't be covered.
The purpose in teaching Java, or C, or Python in a university is not that you leave the university ready to code, but that you can learn what an O(2^n) algorithm is, or how important it is to write good code in general. With all respect to universities, people can and should learn to use pointers, debug, and other stuff on their own spare time.
University time should be spent teaching important basics. No, not important for the industry, important for the understanding and grasping computer science - and for that, pointers are completely useless.
A: I agree with everything he says in his article, and it obviously isn't obvious to most programmers these days, thus insightful.
B: Skimming through random code of his, it does seem that his code doesn't live up to such high standards that he may claim.
A: If you just look at the huge amount of high-level projects written in low-level languages such as C and C++, and the sheer amount of bugs, you can see he has a point. High level languages may have implementations that add security risks, but the languages themselves make it harder to accidentally express bugs, including those that generate security flaws. A language's practical security value can be measured by the security level of its implementations. If you look at CPython's implementation (The one written in C), for example, you see some very good code, written by very good hackers. I have no clue about the bug-levels in Python systems like psych, Jython, or others, but they are probably of adequate levels. Perl has been around long enough to have probably been debugged as well. Java is new and has some seriously crappy implementations with lots of bugs. But out of the vast amount of implementations, some must be safe. Adding the language implementation code, is similar to adding any type of code to your project (libraries, system calls, etc). However, language code is probably better debugged, and only a very small base of its implementation has to be debugged for pointer flaws and indexing problems to be eliminated. There is almost no doubt that Python has (nearly?) no pointer problems or indexing errors in typical configurations in its official sources.
B: Just skimming through his "light, secure, lightning-fast HTTP server" code, I saw some ugliness right off.. Using integers for enum values (even when an enum is declared!). Using complicated pointer arithmetic, where a simple indexing "for" construct can be used (to eliminate error-proneness). Using a static array of pointers to structures, malloc'ating each entry: This is combining the evils of static allocation (limited size, unused bytes for lower cases), and the evils of dynamic allocation (complexity of pointers), the need to malloc'ate (slower than not doing anything), memory fragmentation. Ofcourse he should have used a dynamically growing array of pointers (preferrably one implemented generically via macros/or void* lists, to reuse debugged code), or a static array of structures, but appearantly his code is second-class.
To summarize: while I think his code isn't the best, I do agree with the points he makes, and according to your claim that high-level languages cannot help security, I think that you are probably worse off.
I just read some manpages and figured out one way to do it, though I'm not sure its the "right way", because its just something I sketched up now:
Use dd to create a swap file of the wanted size: dd if=/dev/zero of=SWAP-FILENAME bs=512 size=SWAP-FILE-SIZE/0.5K Use mkswap to convert the file to swap format: mkswap SWAP-FILENAMESWAP-FILE-SIZE/0.5K Use losetup to set up a block device that accesses the file: losetup/dev/loop0 SWAP-FILENAME Ofcourse you can use loop1..7 in case loop0 is busy. Use swapon to enable the file swap space: swapon/dev/loop0
Congratulations, you have enabled file-based swap space!
However, it did remind me of a british Company that used to make PC's back in the early eighties, I can't quite remmember their name.
They put the power supply in the monitor, which has enough fanless vantilation, and thus did not need the power fan in the main case. The CPU's of those days did not require fans so it was a completely quiet setting.
However, one of the first FUD rumours was spread that this was somehow wrong, so they put a useless fan circulating air inside the main case to make noise. Those who had a clue, ripped off the power supply of that fan.
Anyhow, wouldn't it be possible to just put the power supply in the monitor or such, and thus eliminate the main source of noise (the big power fan)?
What if you delete an object? You'd have to revoke capabilities on all processes, or otherwise these processes could gain access to re-allocated space - this would compromise the object-reuse-protection mechanismn.
This is an implementation detail. In EROS, for example, pages are never deleted. The "object" capabilities that actually refer to another process's object, are actually START capabilities that are easily deleted (or more accurately invalidated) efficiently, without risking reuse of revoked access. To support page deletion, you have to simply add another indirection level, which is not very expensive.
But you would have to define different capabilities for the same program used by different users, because you don't want user A to read user B's files with the mail program that both users share. Still not very simple.
Ofcourse different processes that obey the same code (the same program, so to speak) (in other words, different instances of the program) have different sets of capabilities. This is not at all complicated.
Another thing which makes it pretty complicated. How do you manage your data? You could only manage mail files with your mail program, sound files with your mp3 player, and so on..
I have discussed this -- There is no global namespace accessible to all processes. There can easily exist a program that implements a namespace (database or hierarchy-like file system) for the user's convinience, but it still does not lend a global namespace for all processes. Then, the user can take capabilities to objects from this namespace, and pass them on selectively to both his mp3 player and his mail client - not limiting his options at all.
As soon as you break into a program which has a certain capability, you can transfer this capability to another program.
The result is exactly the same: You're potentially granting access to all other applications. Still not secure.
I believe you have failed to understand the point behind the cited text. Bugs are not being discussed here - but the level of fine-grained security. Its merely saying that user-based access control lists force me to grant access to all of dan's programs, if I want to grant access to any of them. I cannot select which program I want to grant access to.
If you have two-way communication with a program, you can still exploit/abuse it, but in capability systems, you can restrict the communication of programs such that they can only communicate with a select few.
TCSEC B3 level by NSA (for those who don't know it: that means ZERO DESIGN FLAWS)
This is highly subjective and depends on your definition of a "design flaw".
There are a lot of other problems with capability-based systems, especially when you want to share data between processes (and that's probably why you're using ONE computer for two programs and not TWO computers for two programs. Commercial applications need to share data).
There is nothing particularly difficult about sharing data in a capability system - you can easily share memory by passing a capability to the same page and mapping it into both of your address spaces.
So how do you protect a program which has some capability from modifying some pointer or other data structure which has something to do with the capability? You still need something like a system call everytime you use a capability, because you need to go into kernel mode to be able to work with capabilities that are protected from modification by user space processes.
Yes, capabilities are protected by the small trusted kernel-level code base. Yes, this requires a system call per-invocation. But capabilities are only invoked to perform IPC and to request kernel-level services so this is not worse in performance than a *nix variant.
Will never make it as close to the principle of least privelege as capability systems such as EROS, or KeyKOS. (And no, by "capabilities" I mean EROS-like capabilities, not the POSIX re-definition of the word "capability").
True security will never be achieved in the *nix way (Complicated ACL's attached to every 'command' or 'system call'), due to problems such as The confused deputy.
True security can only be achieved when there is complete identity between what requests a process can express, and what the process is authorized - only possible without a global namespace such as the set of system calls or the file system. Only capability systems are of this nature.
OpenBSD may be secure in the sense that it has few bugs, where almost every bug in the every-growing code base regarding *nix security is a security hole, but its not secure in the sense that truly secure systems such as EROS are secure - by having (to sum it up):
A small, finite, debugged code base that deals with security - and no extra security code.
Simple security paradigm with a single simple-logic security test per request.
Identity between what a process can request, and what the process is authorized to do.
Fine-grained access control, with each process having capabilities to the exact objects it needs to access.
The principle of least privelege (Your mp3 player cannot delete your files, your email client cannot listen on any port, etc).
Flexible security: The complicated authorization graph is between processes, and not between users and objects. The concept of "user" is not part of the operating system. This is also achievable because capability systems often have orthogonal persistence, that is transparent persistence (sort of like Hibernation Mode, in its functionality), which tends to be of much better disk performance.
No global namespace: There is no global namespace file system that all applications have access to. Perhaps a database of objects for the user's convinence that points via capabilities to the user's objects which are then passed on selectively. But there is no global file namespace that processes can access. All requests by processes must be carried out by activating a capability, whose mere existence authorizes the request. This instead of activating a system call from a global namespace of system calls, allowing any process to request almost anything, hoping that the security code regarding that request will properly deny that request. The global namespace allows extra communication and exploitation between processes that needn't be possible.
I believe this method of software creation is good for the Cathedral model, and with well-funded programmers who program for money, it can get done. But keep in mind, that since its not incremental, its not exciting. DFD's on paper, ERD's, are all boring, when you get down to them. Unless you finish it all very quickly, you're going to be stuck in very long design phases. Unless you're an extremely good designer, you're likely to hit some problems in the actual implementation that may require refining the design.
Code is getting cheaper and cheaper to write. A rapid prototype of how even a large program should generally work or look like can be created in a very-high-level language in just hours. So if you're one of those who can do the designing while coding, its probably most efficient to do it that way, as you can easily throw away the code if seeing the design sucks (Much easier to see with your head on the ground and code written).
Also, I don't see how multiple contributors can't fit into this well-framed process. I would also like to disagree with the requirement of pseudo-code, as today's high-level languages, such as Python, are pretty much as high-level as pseudo code and correctly described sometimes as "Running Pseudo Code". This also means that their code, written correctly, is _truly_ self-documenting, truly. Rarely is there a weird piece of code that requires extra documentation. I'm talking about the what and the how, and not the general software architecture, which should be documented separately.
In summary, I think that your software creation model is too "formal" in the sense that it will not excite programmers, and will be very difficult to get contributors from all around. Excited programmers are better programmers. Also, I think its a bit presumptious of you to think you can know, to detail, the exact best way for the program to be designed, and thus its probably best to write it piece by piece, and see where usability's taking you. An assumption of mine, is that most useful features of a program are suggested at its usage stage, and not its design stage - This means you better minimize the design stage, and get to the usage stage as soon as possible. Do you disagree with this assumption?
Only the top level design should be completed in order to start working. There is no way in hell a programmer can think of every single detail of a large software project, even after writing it, let alone prior to writing it.
Perhaps you mean that he shouldn't start if he doesn't have any idea of what interaction and what modules he has, and what the interfaces between those modules should at all look like.
In that, I agree. But I've made The Last Detail mistake in the past, and it has prevented the success of some of my attempted software projects. I have done much better in projects where I jumped right into the water. Usually got it right, when I didn't, I had a much better clue how to get it right the second time. The time it takes to spawn two attempts at a software problem is much quicker than trying to think of all of those details in the abstract.
An important thing to remmember, especially for motivational projects (projects that require a lot of motivation to keep going), is to write code incrementally.
One of the best methods I know to write code incrementally is to rapidly model it in a Rapid Development language such as Python.
Since I get excited by seeing results quickly, I'd probably start by deciding on a GUI toolkit, and find some Python bindings for it. Perhaps an OpenGL GUI of my own, in any case, that's where I'd start. Whatever excites you the most (Perhaps rendering ray-traced images of simple objects excites you, and you can start there), is where you should start. As long as you're excited about what you're doing, you can easily keep on going.
Then, when you have a GUI (Or a simple renderer for that matter), you need to generate "stubs" for other components. There are various meanings of the word "stub" flying around, so I'll explain mine: A simple replacement of the interface a software component, that is trivial to implement, lacks any of the functionality, and is intended to later be re-written.
This enables you to work on an exciting Skeleton of your program, that lacks almost all of the functionality, but there is already a bit of something very exciting to you, and perhaps to others who share your interests, to work with.
Notice this is the same method used in the early development of Linux.
Linus provided a very simple Skeleton of a Kernel, with either stubs or extremely naive implementations of almost all kernel subsystems. This is much better than the alternative, of trying to create the 2.4.19 kernel, component by component, from scratch. Linux 2.4.19 shares very little in design and in code with Linux 0.1, and the actual implementation decisions of Linux 0.1 don't really matter at all now.
This is why I emphasize that you should start before you know exactly where its going, because there's a good chance you'll be stuck planning it forever, if you try to get it all right in the first time. If you don't bind yourself to backwards compatability, it doesn't really make a difference what kind of design error you make now, it can be corrected with time and with rewrites. Don't worry - rewrites are much shorter than the original designs and writes, as they come after a lot of experience, and can often reuse most of the code.
Keep excited, start coding. Whenever there are tidbits of work you don't like doing, but must, keep in mind how the great cool exciting things that depend on it will look like. Don't code without design, but do code what little parts you know the design of already.
While common oppinion here is that copyright infringement is negative to society, I would like to present a different oppinion.
Firstly, I would like to point you to a well-written Slashdot comment about the current abuse of the original concept of Copyright. The points I would like to take from there are that Copyrights were intended to promote society, and the progress of Science and Useful Arts, but are now used for the sole means of creating profit for companies.
You must note that Copyrights, the exclusive rights to copy some data, is a big limitation on everyone's freedom to copy whatever they want. I'm not saying this means its necessarily a bad thing - because I agree its a necessary evil. Limiting people's freedom is acceptable in many aspects of life, and here too. Unfortunatly, the limit on our freedom remained through the years, but the original purpose of copyright - since it was originally drafted - was lost.
The original copyright concept was to give incentive to create, for the sole purpose of promoting science and useful arts. (Its true, its not meant to reward authors, its meant to promote science and useful arts - read about it in the constitution). This is why Copyright was created to last for limited times, which is not really limited anymore. This means that all copyrighted work is supposed to be out in the public domain within a reasonable amount of time - It is no longer this way. It also means that copyrights are only given to works that are published and distributed - for the inspiring of new works - for the progress of science and useful arts. Today's large copyright owners try to make people forget this purpose of copyright, and claim it is actually meant to protect them - That their creation is somehow their "Intellectual Property" and can be "Stolen". But the original framers of the constitution did not mean this, as Thomas Jefferson has said: There is no such thing as Intellectual Property.
If we take the software industry specifically, we must not forget that until the Copyright reforms of the 1970's, Binary Data was not copyright'able. Why? Because its creation does little to Promote Science and Useful Arts. See, you cannot both eat the cake (Get a Copyright) and have it full (Not promote science and useful arts). A copyright is not a god-given right, its given to the creator in exchange for his sharing of the created information, for the progress of science and useful arts for us all.
Since Copyright has devolved from a strong respected publishing incentive to an infamous tool for company profit, people have lost all moral obligation to it. There is no wonder people care not for the Copyrights of large corporations, as those copyrights place a limit on their freedom to "Help thy Neighbour", without contributing back to Science and Useful Arts.
This is why I will not obey the current draconian Copyright Laws, while I will support the GPL. Hypocracy? No: Copyrights have violated their mandate to Promote Science and Useful Arts. The GPL hasn't: It has inspired huge amounts of Free Software writers and possibly caused some of the greatest software code to be written and be out there for everyone to learn from.
Sorry this comment is a bit long, just my oppinion on the matter.
While I agree text files are pretty cool from many aspects, I disagree with your claims:
Text files are so amazing universal that it's a crime to not utilise their power and the many approaches one can take to the data.
Text files are not what's universal, its the text-able API to access them that's universal. This can work on binary data, which has an alternate text representation, but still retains the binary capabilities of algorithmic efficiency and such.
Binary configuration files are the devils spawn.
To this claim I can only reply: No, they're not.
Pray, which is the quicker way to change the box's ip... or navigate through control panel?
Although a Linux guru will reconfigure Linux stuff faster than a Windows guru configured Windows, this is hardly because of the text files. Its because of an unrelated issue, the user interface.
For example, take a more efficient Control Panel approach, where you type a couple of strokes and it fires the control panel, and then you type "ip a" or some shortcut for the ip address configuration and it jumps you right there, in which you easily change the IP... This should be at least as fast as editing with a text editor. Actually, due to the various types of configuration fields, a specialized GUI for editing the configuration should often be quite faster than a simple text file editor.
The KDE control center has taken this approach partially: You can search the control panel instead of navigating through, but its still not completely keyboard oriented and more keyword oriented rather than word-search oriented).
As long as a system retains its ability to access the configuration by unified API's that can access all types of other data, it does not matter whether its stored as text, because it can easily be represented that way. If its binary, many algorithmic efficiencies can be implemented.
The registry is quite a mess, and not really better than/etc and $HOME/.* text files.
Its faster, and has potential to be much better, but not as its currently implemented and with its current organization structure.
If the registry was at least created as a set of searchable binary search trees or such, so that searches can run in reasonable time, then it would really utilize the advantage of its structure. Currently, it takes a lot of time to search for keys, even when you know their exact name.
Since the registry has its own API's, as everthing in Windows does, it sure makes it harder to use a set of simple utilities on it. The registry would be best utilized in the unix way, of reusing the simple file system API to access the registry. Doesn't have to be a set of.txt files in a directory. It can also sit in its own partition or file as its own type of filesystem, with fast binary search trees, key type information and such, but at least allow the many utilities that can access files operate on it! It puts all utilities that can access files at a huge waste.
Obviously Microsoft programmers have never taken a single reasonably difficult programming class in their lives, or they're just not very smart and creative.
Capability systems have many provable mathematical properties that are very important to real security. For example, one can prove privelege escalation is impossible in a capability system.
Sure, a real life implementation will differ from the design until all bugs are resolved, but its still better than *nix security, where even the design itself has no secure properties that are mathematically provable. Also, since the security code in EROS and such systems is very limited to the implementation of the low-level capability mechanism, the amount of security-testing code is very finite in size, and thus will at some point in time be clear of bugs, and identical to the architecture's design.
One of the main differences between capability systems and systrace for all apps, is that in a capability system, _only_ authorized requests can even be expressed by an application, while with systrace, all requests can be expressed, and if a bug exists in one of the millions of requests' implementations, you get a security hole.
Also, capability systems grant you far more fine-grained security control, and they define processes as entities, rather than users.
Capability systems are also much simpler in concept, and do not have a global namespace such as a filesystem that makes for richer communication between distant entities of the system, even those who are not supposed to communicate.
Capability systems are not volunerable to the Confused Deputy problem that exists with ACL-type systems where you must have applications that 'Change hats' (All apps with 'suid bits').
Linux and BSD are both just *nix. *nix is *nix is *nix. Crappy ACL-type security (as opposed to Capability Systems security [EROS, for example]).
Performance differences are negligable. The areas where BSD and Linux do differ, usually the Linux way is better known around. The Stack is ripped off in closed source OS's because Linux doesn't use a license that supports Closed Source distributers.
In hardware support, Linux probably beats BSD, but I haven't followed it much.
Also, Linux has a native Debian distribution, and many others, while BSD has second-hand ports of such and its native distributions are in many oppinions far worse.
Slashdot Mirror
That a living cell is defined as a cell that contains genetic properties (i.e: ones that are carried on to the next generation), thus allowing evolution and other properties of life to form.
The non-living cells would then be micro-mechanisms that contain some of the functionality of living cells, but not genetic properties, and as such they are not "alive", cannot evolve and cannot pass qualities to a "next generation". These non-living cells, however, could be great platforms for living cells to be created "in" (or in place of?).
I wasn't referring to the acts of 1962, but to the trade of map-making of the consitution-writing days. Map-makers were signing NDA's of secrecy so as to make money from their work. Copyright was created as a means to allow making works available while still being protected.
I'm not misinterpreting the constitution - It explicitly states that the copyrights should have limited times, and in the discussions prior to it, they explain it is because copyrights, as limitations on freedom, are the necessary evil - that should be minimized.
No, people were not inspired by a film just as much before and after it entered the public domain - because fewer people had access to the content. Now, everyone has free access to the content, and anyone can be inspired by it.
Film preservation is easy when stored as digital content.
You seem to think I'm claiming that everything-in-the-public-domain promotes science and useful arts more, simply because it does so immediately. But ofcourse I never claimed this, and only superficial analysis can result in such a flawed conclusion.
The longer it takes something to enter the public domain, the more incentive it gives to creating works, but the less valuable these works are to society (Since people have limited freedom in regard to those works). The shorter it takes something to enter the public domain, the less incentive there is to create it, but the more valuable creations are to society (the information is free to inspire everyone, and anyone can pass it on to anyone to learn from). For example, a teacher can copy meterial from the public domain to all of his students freely, to teach them about music, or novel writing, or such. On the contrary, he cannot require them to buy a book, or a music piece, or a movie.
Thus, a balance should be found, to maximize incentive and the value of the work to society. The original balance that was decided was 14 years (plus an additional optional 14 years if the author was still alive). Copyrights have been prolonged again and again since, and they are now Author's life + 150 years, which is an absurd amount of time, obviously contradicting the "For Limited Times" phrase in the constitution.
That statement doesn't make a whole lot of sense. US law, and the laws of the various European states, are based on traditions of law that came before them. A significant portion of US law, for example, was inspired by Iroquois law. And a significant portion of the various European bodies of law was inspired by US law. So there's a direct connection between the Iroquois tradition of intellectual property going back a thousand years and the copyright law that governs this very comment today.
The connection is less direct than you may think. The copyright law was presented in the constitution of the united states after independent discussion and thought, and as a solution to their own intellectual output problems (secrecy and NDA's of the times).
Absolutely it does. It promotes science and the useful arts in two ways. First, it attaches a profit motive to the creation of new inventions, which, as history has demonstrated, promotes the heck out of science and the useful arts.
You have a different view of what promotes science and useful arts than what I, and the framers of the US constitution have/had in mind.
The idea is that Copyright is for limited times and only in this case is it promoting science and useful arts - because only works in the public domain are promoting science and useful arts. Works that are not accessible to society and are not readily available to inspire and be learned from, are not promoting science and useful arts.
Copyrights, as the US consitution defined them, promote Science and Useful Arts by securing for limited times exclusive copying rights to inventors - and then placing them under the public domain.
Second, it promotes original work. If person X wants to develop an invention based on IP owned by person Y, and person X doesn't want to pay person Y's asking price for a license, then person X will go out there and find a new and different way to accomplish the same goal. That's a good thing for science and the useful arts.
It seems you are confusing copyrights and patents here. Copyrights are on expressions of ideas, not on ways to do things. So if person Y wants to express the same idea, he merely has to re-express it in a different way - not find a different idea.
(While we're on the subject, please explain to me how the entry of "Steamboat Willie" into the public domain will do anything to promote science or the useful arts. I've never really understood that assertion.)
I don't think that anything is about to enter the public domain due to the time limit in the next 25 years or so, because of the reoccuring retro-active extension of the copyright length. This means that any release into the public domain is probably going to be meterial worthless to its creator - and likely to be worthless to society.
I've never before heard of this specific content, but now that I've googled to find what that content is all about - its enterance into the public domain may help artists be inspired and learn from these works, obviously.
Did you use the "Preview" button? Are you seriously saying that you believe the concept of property ought to be abolished? I'll just assume that you misspoke, and I look forward to reading your clarification.
I was talking about the idea of "Intellectual Property", giving exclusive copying rights to individuals indefinitely, limiting the freedom of everyone else with no intention of giving it back to them (with the enterance into the public domain), as a concept which should be abolished.
In any case, remember that we're not talking about pure intellectual property here. These are not simply ideas. These are works, created through the effort of individuals. Just as I wouldn't expect my exclusive right to sit in this chair-- which I bought, but I could just as well have built myself-- to end after 14 years, neither would I expect that my rights to "Steamboat Willie," the film, would end after 14 years. (Assuming I was the person who owned them, that is.)
The idea is - that once you choose to release and distribute what you have created, the information naturally "wants" to propogate for the education and advancement of human kind. Disallowing its propogation is evil (yes, necessary evil), and thus should be limited to the minimum that is required to encourage creation.
I don't believe in any natural inherent "ownership rights" of the universe or such - I only believe those which contribute to society as a whole. If a 14 year period copyright is enough to get people to create meterial - and still allow people virtually unlimited freedom to distribute information, its the best of both worlds.
When you remember that copyright protects not just ideas but actual works as well, it sort of throws the whole idea of an expiration date on rights into question.
I disagree - because I don't believe in inherent rights as you do.
It may not be recent globally, but it is recent in the states and Europe.
Again - making 'property' out of it is bad - because it doesn't advacne the real goal of copyrights - which is Promoting Science and Useful Arts.
'Property' implies it never enters the public domain, and is under the permanent and complete control of someone - which is a concept which should be abolished.
uninformed souls argue that copyright-- indeed all of intellectual property-- as a concept must be abolished.
Copyrights are not intellectual property, and I don't think I'm uninformed, and neither was Thomas Jefferson, but both of us think that there is no such thing as Intellectual Property.
Equating intellectual output with "property" is a rather recent thing, done by strong copyright holders who want to get "property rights" (permanence, etc.) on their intellectual output. I think that such ideas should indeed be abolished.
Also, while I do believe that it is probably a bad idea to abolish copyrights altogether, I am not at all sure of that.. I am too agnostic to claim to know this -- however I am pretty firm in my belief that restoring copyrights to their original proportion would be beneficial for society - and may even eliminate a few monopolies.
Copyrights are draconian remainders of the original laws that existed centuries ago. This is why most /.'ers today do not wish to support them. Spam is simply an intrusion.
/.'ers may support them.
Thus, from a utility point of view, spam is evil, and copyright infringement isn't.
If Copyright laws were reestablished as they were centuries ago, with reasonable limited times, and requirement of publishing the works (The source code, etc.), then
Lastly, there is a case to be made against the RIAA/MPAA/etc use of copyright to try and grasp the remainder of their market by the nails and the teeth, using primitive distribution technology and techniques that made them money in the past, simply because they aren't willing to move to a new model of making money, with the rest of the world.
People do not want to stay behind, wasting car fuel to go and get a bunch of data bits, when those bits can more efficiently travel through their internet connections.
Have you heard of references?
With references, you can more easily implement trees and linked lists than with pointers (See Scheme, Python, etc).
Ofcourse, references are implemented via pointers, but that's uninteresting to the computer science student, albeit interesting to the industry.
They are extremely important for industry programming. Not for grasping the Computer Science behind it.
On a tangent, that's why I love Perl. It's like English: it's so flexible and can be so cryptic that a bad programmer can quickly create a mess. However, following the analogy with English, a good programmer can make a masterpiece in short time.
:)
Try Python, it avoids the first property (making it easy to write cryptic code), while still allowing the latter (letting good programmers make masterpieces in short times).
I can't wait to see Perl 6 in action. Once they improve OOP style Perl, I'm set.
AND it has very nice OOP
Universities are not about teaching you how to work. They are supposed to teach you how to learn for yourself. They should cover the basics of as many areas as possible - and this includes programming and algorithms. This is why some language must be learned, or those areas can't be covered.
The purpose in teaching Java, or C, or Python in a university is not that you leave the university ready to code, but that you can learn what an O(2^n) algorithm is, or how important it is to write good code in general. With all respect to universities, people can and should learn to use pointers, debug, and other stuff on their own spare time.
University time should be spent teaching important basics. No, not important for the industry, important for the understanding and grasping computer science - and for that, pointers are completely useless.
A: I agree with everything he says in his article, and it obviously isn't obvious to most programmers these days, thus insightful.
B: Skimming through random code of his, it does seem that his code doesn't live up to such high standards that he may claim.
A: If you just look at the huge amount of high-level projects written in low-level languages such as C and C++, and the sheer amount of bugs, you can see he has a point.
High level languages may have implementations that add security risks, but the languages themselves make it harder to accidentally express bugs, including those that generate security flaws. A language's practical security value can be measured by the security level of its implementations. If you look at CPython's implementation (The one written in C), for example, you see some very good code, written by very good hackers. I have no clue about the bug-levels in Python systems like psych, Jython, or others, but they are probably of adequate levels. Perl has been around long enough to have probably been debugged as well.
Java is new and has some seriously crappy implementations with lots of bugs. But out of the vast amount of implementations, some must be safe.
Adding the language implementation code, is similar to adding any type of code to your project (libraries, system calls, etc). However, language code is probably better debugged, and only a very small base of its implementation has to be debugged for pointer flaws and indexing problems to be eliminated.
There is almost no doubt that Python has (nearly?) no pointer problems or indexing errors in typical configurations in its official sources.
B: Just skimming through his "light, secure, lightning-fast HTTP server" code, I saw some ugliness right off..
Using integers for enum values (even when an enum is declared!). Using complicated pointer arithmetic, where a simple indexing "for" construct can be used (to eliminate error-proneness). Using a static array of pointers to structures, malloc'ating each entry: This is combining the evils of static allocation (limited size, unused bytes for lower cases), and the evils of dynamic allocation (complexity of pointers), the need to malloc'ate (slower than not doing anything), memory fragmentation. Ofcourse he should have used a dynamically growing array of pointers (preferrably one implemented generically via macros/or void* lists, to reuse debugged code), or a static array of structures, but appearantly his code is second-class.
To summarize: while I think his code isn't the best, I do agree with the points he makes, and according to your claim that high-level languages cannot help security, I think that you are probably worse off.
You can already buy Windows binary for 0.99c on the streets of China, so what's the difference?
Linux supports file-based swap space.
/dev/loop0 SWAP-FILENAME /dev/loop0
I just read some manpages and figured out one way to do it, though I'm not sure its the "right way", because its just something I sketched up now:
Use dd to create a swap file of the wanted size:
dd if=/dev/zero of=SWAP-FILENAME bs=512 size=SWAP-FILE-SIZE/0.5K
Use mkswap to convert the file to swap format:
mkswap SWAP-FILENAME SWAP-FILE-SIZE/0.5K
Use losetup to set up a block device that accesses the file:
losetup
Ofcourse you can use loop1..7 in case loop0 is busy.
Use swapon to enable the file swap space:
swapon
Congratulations, you have enabled file-based swap space!
I'll start by explaining I know this is a joke.
However, it did remind me of a british Company that used to make PC's back in the early eighties, I can't quite remmember their name.
They put the power supply in the monitor, which has enough fanless vantilation, and thus did not need the power fan in the main case. The CPU's of those days did not require fans so it was a completely quiet setting.
However, one of the first FUD rumours was spread that this was somehow wrong, so they put a useless fan circulating air inside the main case to make noise. Those who had a clue, ripped off the power supply of that fan.
Anyhow, wouldn't it be possible to just put the power supply in the monitor or such, and thus eliminate the main source of noise (the big power fan)?
What if you delete an object? You'd have to revoke capabilities on all processes, or otherwise these processes could gain access to re-allocated space - this would compromise the object-reuse-protection mechanismn.
..
This is an implementation detail. In EROS, for example, pages are never deleted. The "object" capabilities that actually refer to another process's object, are actually START capabilities that are easily deleted (or more accurately invalidated) efficiently, without risking reuse of revoked access. To support page deletion, you have to simply add another indirection level, which is not very expensive.
But you would have to define different capabilities for the same program used by different users, because you don't want user A to read user B's files with the mail program that both users share. Still not very simple.
Ofcourse different processes that obey the same code (the same program, so to speak) (in other words, different instances of the program) have different sets of capabilities. This is not at all complicated.
Another thing which makes it pretty complicated. How do you manage your data? You could only manage mail files with your mail program, sound files with your mp3 player, and so on
I have discussed this -- There is no global namespace accessible to all processes. There can easily exist a program that implements a namespace (database or hierarchy-like file system) for the user's convinience, but it still does not lend a global namespace for all processes. Then, the user can take capabilities to objects from this namespace, and pass them on selectively to both his mp3 player and his mail client - not limiting his options at all.
As soon as you break into a program which has a certain capability, you can transfer this capability to another program.
The result is exactly the same: You're potentially granting access to all other applications. Still not secure.
I believe you have failed to understand the point behind the cited text. Bugs are not being discussed here - but the level of fine-grained security. Its merely saying that user-based access control lists force me to grant access to all of dan's programs, if I want to grant access to any of them. I cannot select which program I want to grant access to.
If you have two-way communication with a program, you can still exploit/abuse it, but in capability systems, you can restrict the communication of programs such that they can only communicate with a select few.
TCSEC B3 level by NSA (for those who don't know it: that means ZERO DESIGN FLAWS)
This is highly subjective and depends on your definition of a "design flaw".
There are a lot of other problems with capability-based systems, especially when you want to share data between processes (and that's probably why you're using ONE computer for two programs and not TWO computers for two programs. Commercial applications need to share data).
There is nothing particularly difficult about sharing data in a capability system - you can easily share memory by passing a capability to the same page and mapping it into both of your address spaces.
So how do you protect a program which has some capability from modifying some pointer or other data structure which has something to do with the capability? You still need something like a system call everytime you use a capability, because you need to go into kernel mode to be able to work with capabilities that are protected from modification by user space processes.
Yes, capabilities are protected by the small trusted kernel-level code base. Yes, this requires a system call per-invocation. But capabilities are only invoked to perform IPC and to request kernel-level services so this is not worse in performance than a *nix variant.
True security will never be achieved in the *nix way (Complicated ACL's attached to every 'command' or 'system call'), due to problems such as The confused deputy.
True security can only be achieved when there is complete identity between what requests a process can express, and what the process is authorized - only possible without a global namespace such as the set of system calls or the file system. Only capability systems are of this nature.
OpenBSD may be secure in the sense that it has few bugs, where almost every bug in the every-growing code base regarding *nix security is a security hole, but its not secure in the sense that truly secure systems such as EROS are secure - by having (to sum it up):
A small, finite, debugged code base that deals with security - and no extra security code.
Simple security paradigm with a single simple-logic security test per request.
Identity between what a process can request, and what the process is authorized to do.
Fine-grained access control, with each process having capabilities to the exact objects it needs to access.
Mathematically-found model, that has mathematically provable properties.
The principle of least privelege (Your mp3 player cannot delete your files, your email client cannot listen on any port, etc).
Flexible security: The complicated authorization graph is between processes, and not between users and objects. The concept of "user" is not part of the operating system. This is also achievable because capability systems often have orthogonal persistence, that is transparent persistence (sort of like Hibernation Mode, in its functionality), which tends to be of much better disk performance.
No global namespace: There is no global namespace file system that all applications have access to. Perhaps a database of objects for the user's convinence that points via capabilities to the user's objects which are then passed on selectively. But there is no global file namespace that processes can access. All requests by processes must be carried out by activating a capability, whose mere existence authorizes the request. This instead of activating a system call from a global namespace of system calls, allowing any process to request almost anything, hoping that the security code regarding that request will properly deny that request. The global namespace allows extra communication and exploitation between processes that needn't be possible.
I believe this method of software creation is good for the Cathedral model, and with well-funded programmers who program for money, it can get done. But keep in mind, that since its not incremental, its not exciting. DFD's on paper, ERD's, are all boring, when you get down to them. Unless you finish it all very quickly, you're going to be stuck in very long design phases. Unless you're an extremely good designer, you're likely to hit some problems in the actual implementation that may require refining the design.
Code is getting cheaper and cheaper to write. A rapid prototype of how even a large program should generally work or look like can be created in a very-high-level language in just hours. So if you're one of those who can do the designing while coding, its probably most efficient to do it that way, as you can easily throw away the code if seeing the design sucks (Much easier to see with your head on the ground and code written).
Also, I don't see how multiple contributors can't fit into this well-framed process. I would also like to disagree with the requirement of pseudo-code, as today's high-level languages, such as Python, are pretty much as high-level as pseudo code and correctly described sometimes as "Running Pseudo Code". This also means that their code, written correctly, is _truly_ self-documenting, truly. Rarely is there a weird piece of code that requires extra documentation. I'm talking about the what and the how, and not the general software architecture, which should be documented separately.
In summary, I think that your software creation model is too "formal" in the sense that it will not excite programmers, and will be very difficult to get contributors from all around. Excited programmers are better programmers. Also, I think its a bit presumptious of you to think you can know, to detail, the exact best way for the program to be designed, and thus its probably best to write it piece by piece, and see where usability's taking you. An assumption of mine, is that most useful features of a program are suggested at its usage stage, and not its design stage - This means you better minimize the design stage, and get to the usage stage as soon as possible. Do you disagree with this assumption?
I disagree.
Only the top level design should be completed in order to start working. There is no way in hell a programmer can think of every single detail of a large software project, even after writing it, let alone prior to writing it.
Perhaps you mean that he shouldn't start if he doesn't have any idea of what interaction and what modules he has, and what the interfaces between those modules should at all look like.
In that, I agree. But I've made The Last Detail mistake in the past, and it has prevented the success of some of my attempted software projects. I have done much better in projects where I jumped right into the water. Usually got it right, when I didn't, I had a much better clue how to get it right the second time. The time it takes to spawn two attempts at a software problem is much quicker than trying to think of all of those details in the abstract.
An important thing to remmember, especially for motivational projects (projects that require a lot of motivation to keep going), is to write code incrementally.
One of the best methods I know to write code incrementally is to rapidly model it in a Rapid Development language such as Python.
Since I get excited by seeing results quickly, I'd probably start by deciding on a GUI toolkit, and find some Python bindings for it. Perhaps an OpenGL GUI of my own, in any case, that's where I'd start. Whatever excites you the most (Perhaps rendering ray-traced images of simple objects excites you, and you can start there), is where you should start. As long as you're excited about what you're doing, you can easily keep on going.
Then, when you have a GUI (Or a simple renderer for that matter), you need to generate "stubs" for other components. There are various meanings of the word "stub" flying around, so I'll explain mine: A simple replacement of the interface a software component, that is trivial to implement, lacks any of the functionality, and is intended to later be re-written.
This enables you to work on an exciting Skeleton of your program, that lacks almost all of the functionality, but there is already a bit of something very exciting to you, and perhaps to others who share your interests, to work with.
Notice this is the same method used in the early development of Linux.
Linus provided a very simple Skeleton of a Kernel, with either stubs or extremely naive implementations of almost all kernel subsystems. This is much better than the alternative, of trying to create the 2.4.19 kernel, component by component, from scratch.
Linux 2.4.19 shares very little in design and in code with Linux 0.1, and the actual implementation decisions of Linux 0.1 don't really matter at all now.
This is why I emphasize that you should start before you know exactly where its going, because there's a good chance you'll be stuck planning it forever, if you try to get it all right in the first time. If you don't bind yourself to backwards compatability, it doesn't really make a difference what kind of design error you make now, it can be corrected with time and with rewrites. Don't worry - rewrites are much shorter than the original designs and writes, as they come after a lot of experience, and can often reuse most of the code.
Keep excited, start coding. Whenever there are tidbits of work you don't like doing, but must, keep in mind how the great cool exciting things that depend on it will look like.
Don't code without design, but do code what little parts you know the design of already.
While common oppinion here is that copyright infringement is negative to society, I would like to present a different oppinion.
Firstly, I would like to point you to a well-written Slashdot comment about the current abuse of the original concept of Copyright. The points I would like to take from there are that Copyrights were intended to promote society, and the progress of Science and Useful Arts, but are now used for the sole means of creating profit for companies.
You must note that Copyrights, the exclusive rights to copy some data, is a big limitation on everyone's freedom to copy whatever they want. I'm not saying this means its necessarily a bad thing - because I agree its a necessary evil. Limiting people's freedom is acceptable in many aspects of life, and here too. Unfortunatly, the limit on our freedom remained through the years, but the original purpose of copyright - since it was originally drafted - was lost.
The original copyright concept was to give incentive to create, for the sole purpose of promoting science and useful arts. (Its true, its not meant to reward authors, its meant to promote science and useful arts - read about it in the constitution). This is why Copyright was created to last for limited times, which is not really limited anymore. This means that all copyrighted work is supposed to be out in the public domain within a reasonable amount of time - It is no longer this way. It also means that copyrights are only given to works that are published and distributed - for the inspiring of new works - for the progress of science and useful arts. Today's large copyright owners try to make people forget this purpose of copyright, and claim it is actually meant to protect them - That their creation is somehow their "Intellectual Property" and can be "Stolen". But the original framers of the constitution did not mean this, as Thomas Jefferson has said: There is no such thing as Intellectual Property.
If we take the software industry specifically, we must not forget that until the Copyright reforms of the 1970's, Binary Data was not copyright'able. Why? Because its creation does little to Promote Science and Useful Arts. See, you cannot both eat the cake (Get a Copyright) and have it full (Not promote science and useful arts). A copyright is not a god-given right, its given to the creator in exchange for his sharing of the created information, for the progress of science and useful arts for us all.
Since Copyright has devolved from a strong respected publishing incentive to an infamous tool for company profit, people have lost all moral obligation to it. There is no wonder people care not for the Copyrights of large corporations, as those copyrights place a limit on their freedom to "Help thy Neighbour", without contributing back to Science and Useful Arts.
This is why I will not obey the current draconian Copyright Laws, while I will support the GPL. Hypocracy? No: Copyrights have violated their mandate to Promote Science and Useful Arts. The GPL hasn't: It has inspired huge amounts of Free Software writers and possibly caused some of the greatest software code to be written and be out there for everyone to learn from.
Sorry this comment is a bit long, just my oppinion on the matter.
While I agree text files are pretty cool from many aspects, I disagree with your claims:
... or navigate through control panel?
Text files are so amazing universal that it's a crime to not utilise their power and the many approaches one can take to the data.
Text files are not what's universal, its the text-able API to access them that's universal. This can work on binary data, which has an alternate text representation, but still retains the binary capabilities of algorithmic efficiency and such.
Binary configuration files are the devils spawn.
To this claim I can only reply: No, they're not.
Pray, which is the quicker way to change the box's ip
Although a Linux guru will reconfigure Linux stuff faster than a Windows guru configured Windows, this is hardly because of the text files. Its because of an unrelated issue, the user interface.
For example, take a more efficient Control Panel approach, where you type a couple of strokes and it fires the control panel, and then you type "ip a" or some shortcut for the ip address configuration and it jumps you right there, in which you easily change the IP... This should be at least as fast as editing with a text editor. Actually, due to the various types of configuration fields, a specialized GUI for editing the configuration should often be quite faster than a simple text file editor.
The KDE control center has taken this approach partially: You can search the control panel instead of navigating through, but its still not completely keyboard oriented and more keyword oriented rather than word-search oriented).
As long as a system retains its ability to access the configuration by unified API's that can access all types of other data, it does not matter whether its stored as text, because it can easily be represented that way. If its binary, many algorithmic efficiencies can be implemented.
The registry is quite a mess, and not really better than /etc and $HOME/.* text files.
.txt files in a directory. It can also sit in its own partition or file as its own type of filesystem, with fast binary search trees, key type information and such, but at least allow the many utilities that can access files operate on it! It puts all utilities that can access files at a huge waste.
Its faster, and has potential to be much better, but not as its currently implemented and with its current organization structure.
If the registry was at least created as a set of searchable binary search trees or such, so that searches can run in reasonable time, then it would really utilize the advantage of its structure. Currently, it takes a lot of time to search for keys, even when you know their exact name.
Since the registry has its own API's, as everthing in Windows does, it sure makes it harder to use a set of simple utilities on it. The registry would be best utilized in the unix way, of reusing the simple file system API to access the registry. Doesn't have to be a set of
Obviously Microsoft programmers have never taken a single reasonably difficult programming class in their lives, or they're just not very smart and creative.
Capability systems have many provable mathematical properties that are very important to real security. For example, one can prove privelege escalation is impossible in a capability system.
Sure, a real life implementation will differ from the design until all bugs are resolved, but its still better than *nix security, where even the design itself has no secure properties that are mathematically provable. Also, since the security code in EROS and such systems is very limited to the implementation of the low-level capability mechanism, the amount of security-testing code is very finite in size, and thus will at some point in time be clear of bugs, and identical to the architecture's design.
One of the main differences between capability systems and systrace for all apps, is that in a capability system, _only_ authorized requests can even be expressed by an application, while with systrace, all requests can be expressed, and if a bug exists in one of the millions of requests' implementations, you get a security hole.
Also, capability systems grant you far more fine-grained security control, and they define processes as entities, rather than users.
Capability systems are also much simpler in concept, and do not have a global namespace such as a filesystem that makes for richer communication between distant entities of the system, even those who are not supposed to communicate.
Capability systems are not volunerable to the Confused Deputy problem that exists with ACL-type systems where you must have applications that 'Change hats' (All apps with 'suid bits').
What Debian has to do with BSD is that it doesn't exist for BSD, and if there is some port, its not as good as the original Debian GNU/Linux.
My point was that Debian is probably the best distribution out there, and Debian GNU/Linux as a whole is thus probably better than BSD.
I have tried FreeBSD in several occasions, as well as some of my friends, we all abandoned it in favour of Debian, for apt and friends.
Probably a troll but:
Linux and BSD are both just *nix.
*nix is *nix is *nix. Crappy ACL-type security (as opposed to Capability Systems security [EROS, for example]).
Performance differences are negligable. The areas where BSD and Linux do differ, usually the Linux way is better known around. The Stack is ripped off in closed source OS's because Linux doesn't use a license that supports Closed Source distributers.
In hardware support, Linux probably beats BSD, but I haven't followed it much.
Also, Linux has a native Debian distribution, and many others, while BSD has second-hand ports of such and its native distributions are in many oppinions far worse.