Coroporate death penalty has existed for centuries, and only recently (the 20th century) it stopped getting used.
As for the 'poor shareholders', what about the poor mother of a criminal, who raised him the best she could, and invested in him, and had nothing to do with his criminal actions and decisions? should the criminal be put in jail and make his mother suffer so bad? For mothers' sake, don't put criminals in jail!
I'm sorry but your claim about the shareholders is downright rediculous.
You cannot follow a company crime-by-crime, and try it again and again for criminal activities, and let it later continue with mostly profitable criminal activities. Its simply not effective (e.g Microsoft). A corporoate death penalty is a lot more effective, and screw the shareholders who should not invest in stock, if they fear losing their money due to serious criminal activities.
Since when does OO have overhead?
The declarative nature of "OO languages" like C++ and Java have overhead to define classes, methods their argument types, etc.
When using Python, I don't feel it takes any more time to write the proper OO solution than it is to write the procedural hack.
In C, you don't really have to 'switch' for polymorphism.
You could use a vtable. You don't have to use malloc and inits, and can write a new and init method for your object. As for a 'dynamic' number of parameters, you'd need a vararg list in C++ too. You're talking about overloaded argument lists, and this can be implemented in C, if you just manually mangle the arglist into the function/method name. C++ doesn't really add conceptual improvements to C (except for exception handling and templates, but both are broken beyond repair), and all of the new C++ syntax is just abbriviating some C underscores:)
You generally end up with the same C++ code, with:: replaced by underscores, vtables manually written, and new methods to malloc and call _init methods that you could do without in C++.
round = round_pipe_new(30.0, 0, 0);
result = round->vtable->flow_rate(round, 12.0, 9.0);
rect = rectangular_pipe_new(0, 40, 4);
result = rect->vtable->flow_rate(rect, 12.0, 9.0);
Yes, a lot more pain doing the declarative stuff, but once its done, the actual code is just as simple.
-------------
For goodness sake, don't use that #define PIPE thing, that's what typedef's are for!
And two #defines in a range? That's what enums are for!
Your bias against safe languages is almost too appearant.
Your claims sum up to:
Popularity is a measure of quality:
Should I really have to discredit this one? What has NetBSD or FreeBSD done to make Windows less popular? Nothing. Are they better than Windows for many many useful purposes? Most people think so.
Python webservers, and Python code is often used in server-side, but maybe you haven't done your homework.
Major sites like Google, NASA, Yahoo, FourEleven, Nortel... use it in the core of their products.
There is a huge list of Lisp users, not to mention Java server-side code.
C and C++'s popularity is dying down, and now that Microsoft Marketing will be pushing C# down everyone's throats, it'll probably remain only in the *nix domain, and as hardware improves, eventually die down.
Safe languages are slow:
Much research and comparison of different languages, such as Lisp and C++ seem to contradict this. Many show that most Common Lisp code using a good compiler will in fact execute faster than most C++ code.
Already C compilers try to analyze the low-level code, making out high-level details of it in order to optimize it. Higher-level languages are in fact becoming more optimizable than C as compilers are getting more advanced.
C is more portable:
This is sort of a paradox as Python, Java, etc have C implementations, and require only high-level access, allowing portable implementations anywhere.
Java VM can run both Java and Python code. Java VM's are implemented on more platforms than proper POSIX-compliant C compilers, last I checked.
C is conceptually less portable. High-level languages will easily/natively make use of the new technologies like VLIW, whereas C compilers will have a VERY hard time using that technology in such low-level code.
Programming is hard - therefore lack of safety (note: safety, not security) is acceptable:
Note that not all, but most security problems result from this lack of safety. Unlike your claim, this safety really exists in languages like Python and Lisp.
When was the last time pure Python or Lisp (without C modules) crashed? I've writtens dozens to hundreds of thousands of Python lines, and never experienced crashes in pure Python code. Some C extension modules crashed, as C code often tends to.
The guarantee of safety is not worth the performance hit:
Maybe running a pure Python-code webserver on a 586 100 with 16 megs of RAM is a bad idea.
However, Common Lisp, OCaml, Python code to 'glue' optimized C modules, etc executes fast enough even on the older hardware, and the memory requirements are generally not that bad. Usually something like a factor of 2 or 3, with some constant size addition to C code.
Today's hardware makes the language of your choice irrelevant, as the differences become more and more unnoticable.
This almost-unnoticable 'hit' on performance is definitely worth the guarantee of safety, that eliminates almost all security problems.
Outlook security holes were not solved by safe languages:
True, but VBS *is* safe (not secure, SAFE). This means it does not crash.
Most security problems are already eliminated. As for complete access to the machine, that's a security problem that has nothing to do with the use of safe languages.
Buffer overruns do not occur because programmers do not know how to do bounds checking.
I suppose you meant that programmers do not bound-check properly. Obviously this is the cause of the failures. However, safe languages solve this problem by guaranteeing this can't happen.
We see a lot of buffer overruns occur however, because the only languages truly suitable for most problem domains are the languages that allow these things to happen.
Tell me, how are the unsafe languages such as C or C++ more suitable for daemon coding than Python, Lisp, Scheme, etc?
Python, along with Twisted Matrix, for example, allows for easy, safe, and very fast network daemons. Medusa is an example of a very fast Python webserver, written in much less code than equivalent C\C++, and executing at least as fast.
If Python allows performance, ease of development, reliability and guarantee of security (from such volunerabilities), how is it less suitable than C or C++ for the development of network daemons?
Completeness has nothing to do with that by the way. Reliability, memory usage, speed and portability issues have.
Reliability, and portability issues are both voting against C and C++.
As for speed, safe languages prove to be at least fast enough for I/O-bound applications. Some safe languages (Common Lisp, OCaml) even prove to compile to much more efficient code than C\C++ in many cases.
Besides, if programmers can't get something simple like array indexing right, then how are they going to get the much, much, much more complicated domain-specific safety issues right?
That's bull. All programmers make mistakes. What you are talking about here is the ability to make 0 mistakes as far as array indexing, pointer management, and other low-level issues are concerned. Firstly, there are always potential mistakes in any part of a program. Secondly, pointer management (killing dangling pointers correctly, managing complex pointing graphs, etc) is not trivial at all.
Therefore, a language that makes you a guarantee of safety in those regards, and handles all those low-level issues automatically and correctly, is a huge benefit.
And how are you going to prove that your favorite Common LISP implementation actually does not violate any of the requirements? Look at how "safe" a language like Javascript is. Or Visual Basic.
You're not going to prove it, but debugging a single, finite code base (A compiler) is a hell of a lot easier than debugging and correcting infinite amounts of code written all the time. To claim it is as hard to maintain correctness of the compiler as it is of EVERY program out there is absurd.
As for Visual Basic and Javascript, my experience is that they are safe in those regards. They are obviously (at least Visual Basic) not examples of stable well-tested platforms, as many of the Lisp, Python, and other compilers/VM's are (especially when considering the reputation of the creators).
You see where I am coming from, when your C code malfunctions, that is not a flaw with C -- it's a flaw in your code.
Assuming the goals of your language are to ease development and provide the best platform for developing software, a language that does not provide a guarantee of safety is far inferior to one that does, in terms of fulfilling those goals.
There is no reason for a compiler to have to have
any ability to write to the accounting files.
If that is considered a design requirement,
then the design was wrong.
But the compiler IS outputting accounting information here.
Its easy to claim that any design requiring a certain feature *nix cannot provide is wrong, but it sounds quite an absurd claim to me. You're trying to adjust the world to your OS, rather than write an OS that fits your needs.
In terms of debug/frequency stats, create a
directory, make the compiler setuid or gid
to be able to write there, and put the stats
and ONLY the stats in that directory (
you do the set(ug)id, at the very end,
just to write the stats file as the last
hurrah.) Or even just leave it public write,
if someone wants to futz with your stats
they really have time on their hands.
Problems:
How is your solution preventing the original problem of a malicious user naming a billing filename as an output file?
As long as the compiler 'changes hats' (Setuid/gid), the privelege-checking is quite complex and will probably result in VERY complex ACL's to achieve the goal.
These stats are used for billing information, and people would thus be VERY willing to mess with them.
All these security settings require root to set up, meaning that only a system administrator is capable of setting up any system involving security checks.
Alternative approach:
The mechanism used to identify (name) objects is that of unforgable, OS-implemented keys called "capabilities". These capabilities are much like *nix file descriptors, but they are never open()'d or close()'d. Having the capability is a necessary and sufficient condition to access the named object, the object does not care who access it.
The above example, is very simply solved by capabilities:
In order to name the billing file to the compiler, the user must have a capability to that billing file. In that case, the user is fully authorized to access this file. Obviously, the user does not have a capability to this file, only the compiler does, and since there is no way to forge a capability (just like file descriptors), the user cannot name the file he must not access, and may not confuse the deputy.
Advantages:
Users (code) can only express requests by access to a capability, meaning that code is only capable of expressing authorized requests. This means that there is no ACL test failure that may give false access to this user, as the mere ability to express a request is an indication of authority to do it.
The only security test required at runtime is that the capability is valid, which is equivalent to the validity test of a file descriptor, nearing 0 time.
Capability systems are in fact simpler systems, and many security properties of such can be mathematically proven, as demonstrated by Shapiro, in his proof of part of his EROS system.
Capabilities have per-process granulity, rather than per-user granulity, and very fine-grained control of which objects every process has access to, thus the principle of least privelege is implemented.
No need for a 'super user' that bypasses ACL's, because that would destroy the principle of least privelege. Every user can create objects and spawn capabilities to use those objects, and distribute them through every channel he has a capability to.
This means any process with some minimal set of capabilities can set up a security system, not requiring any super user to bother, and killing the vast majority of threats involving a superuser.
Safe languages are languages incapable of expressing things like buffer overruns or overrunning other memory, or invalid array indexing. This means they cannot express corruption of memory and are not volenurable to the vast majority of problems in most things today. Those languages, including Python, Smalltalk, Lisp, Perl, and others are incapable of crashing the machine (although sometimes C modules written for these do crash the machine), yet are Turing Complete and capable of solving any problem C, C++, or other unsafe language is capable of solving.
Re:There are major problems with compartmentalizat
on
HP-LX 1.0 Secure Linux
·
· Score: 4, Informative
The alternative, of course, is to ban the use of graphical interfaces on that system; but usually that is unacceptable.
The real way of doing this is putting the hardware drivers into the kernel (frame buffer devices).
No user process is supposed to access hardware directly, and if that meant we have no graphics, it would also mean no keyboard, text, or sound.
Although these issues can all be addressed, the problem of proper kernel security is at best a "whack a mole" situation in which a new hole will arise shortly after an existing hole is patched. Thus, the HP-LX software probably isn't worth the CD it is pressed onto.
That may be true, but it is only because of the nature of UNIX kernels. Kernels built with the principle of least privelege in mind (such as EROS) are definitely worth the fix, as it is quite unlikely to present new holes (and such a design is quite unlikely to have many holes in the first place)
The old comparison of piracy to stealing is completely invalid.
The people ""pirating"" software are only causing financial damage if, and only if they would otherwise pay for the software. The percentage of people who would actually pay for ""pirated"" software is extremely low, not to mention much lower than 100%.
When stealing, you enrich yourself at the expense of someone else. When ""pirating"", you enrich yourself, period. At worst, you enrich yourself at the expense of a dubious incentive to create.
As shown by much research, the worst creative incentive is money. The best and most original creators were motivated by their own need of creation. Also, a free market will always generate required products, even be that free information. Assuming all software is free by enforced law, a company requiring software not yet available, will pay for its creation. A user requiring software will simply get the latest and greatest from Gnome, KDE, XFce, or the vast free collection that would exist had all software been enforced free. Development will be far more efficient, as the entire world's existing code base is reusable in your software components!
The vast majority of people I know ""pirate"".
They do so because they don't believe in paying high prices for artifical scarcity, and because they don't really value copyrights.
How are these not moral reasons?
Are these reasons selfish?
There are perfectly valid world and moral views that dismiss intellectual property as an immoral limitation on freedom, that does not encourage innovation, but rather reinventing the wheel every time as the original wheel is copyrighted.
Aritificial scarcity is not only impractical (as shown by the ease of ""pirating""), but also unhelpful and immoral.
Now for something else you don't want to hear: Microsoft is justified in whining. They do have many, many people using their software without paying. Even if we see the software as crap, it's apparently "good enough" to be pretty damn popular. They deserve payment for that 24% (for Windows, probably more) of their software that's being pirated.
Microsoft has gained their wealth in far worse, illegal means than piracy. Do they really deserve any money at all? If money is an incentive, is Microsoft the example to set as the model of gaining money? Would the people ""pirating"" this software really pay to use this software?
And their attempts to stop piracy haven't been unfair, either! There's all this complaining about the Windows Auth Code -- and not even anecdotal evidence of it harming anyone. So you let the software authorize itself, big deal. For the tiny, tiny percentage of people who upgrade a lot, they just need to give MS a call, and MS will authorize their new code. Big deal.
Calling "Big Brother" for every upgrade, and/or having troubles upgrading and/or using the system is unacceptable to many, many people.
Are you afraid of being seen with pornography?
Last I checked, it wasn't a crime.
If you're so paranoid about it being found out, put it in a bag first, but don't blame the cameras, as any Joe Schmoe can see you too.
You cannot expect privacy in the street:
If a camera can see you, so can a human eye.
The only reason to fear being filmed by cameras is if you're planning on lying in your side of the story, hoping to have a word-against-word case, rather than a word-against-video. And then - what are you lying to protect?
There is no right way to name your string hierarchy (i.e a file system).
Since there is no proper convention of attributing things such as title, content, author, etc. on the file (only type, in the extension), these are conviniently put in the file name.
The problem here is not spaces in file names, but the weakness of a string hierarchy.
As someone already mentioned, the travelling salesman problem is about finding the *optimal* solution. For any practical purpose, a near-optimal solution can be found, and there are P solutions to this problem.
A certain P solution can be proven to always find a path at most twice the length of the optimal one.
Information theory proves that two sides that can transmit data to each other can transmit any information they want with any tunneling they want.
As for shutting down servers... A gnutella-type network may replace the www for typical restricted things. Outlawing the use of software is quite a difficult problem, and 'solutions' will always be found.
These two things above combined, mean that the Internet may never lose its information freedom, no matter how powerful or how badly some government wants.
Information theory is on our side, stop worrying so much:)
I have the same problem when it comes to helping my daughter with her math homework. I can't help her because I can't explain how to do it. I just do the problems instinctively. I send her to her mom, or to our next door neighbor (who is a math teacher).
Someone who is really good at maths, knows to break down the solution to the smallest pieces and explain the pieces. One who is good enough would find ways requiring less creativity to solve the problems, at least of some genre.
The problem with the education system is that they teach the what, and not the how or why, and I wouldn't trust a school teacher to do a good job at teaching, but maybe that's just the Israeli teachers..
That's one of the stupidest things I've read today.
DOS is a thin file-access and memory allocation library, with a very small and weak command shell, on top of the BIOS routines. Applications mostly serve as their own OS, or use the BIOS.
The reason DOS "itself" crashes little, is because there is almost none of it!
In fact, applications crashing the entire machine is exactly the reason DOS is completely unstable. It is the responsibility of the OS to ensure system stability.
which in the end is motivated mostly by economic concerns and nationalism and can be easily solved via some redistricting, establishment of a Palestinian nation, and economic aid to the Palestinians (well, it can be easily solved if you get the two sides to stop shooting for long enough, and you throw out the radicals on both sides who oppose any middle ground solutions).
More easily said than done. For peace, the majority has to support peace. After the Palestinian violence of the last year, there is no majority for peace. Even before so, there was no middle ground of agreement about the refugee problem.
The Israeli/Palestinian conflict cannot be easily solved.
Slashdot Mirror
Last I checked, testing got none of the security fixes.
Makes it a non-option for me.
Fortunatly for me, I am very happy with unstable, and find almost all of unstable's problems trivial to fix, and if not, trivial to hack around.
Coroporate death penalty has existed for centuries, and only recently (the 20th century) it stopped getting used.
As for the 'poor shareholders', what about the poor mother of a criminal, who raised him the best she could, and invested in him, and had nothing to do with his criminal actions and decisions? should the criminal be put in jail and make his mother suffer so bad? For mothers' sake, don't put criminals in jail!
I'm sorry but your claim about the shareholders is downright rediculous.
You cannot follow a company crime-by-crime, and try it again and again for criminal activities, and let it later continue with mostly profitable criminal activities. Its simply not effective (e.g Microsoft). A corporoate death penalty is a lot more effective, and screw the shareholders who should not invest in stock, if they fear losing their money due to serious criminal activities.
Since when does OO have overhead?
...
...
...
...
( ))
...
:)
The declarative nature of "OO languages" like C++ and Java have overhead to define classes, methods their argument types, etc.
When using Python, I don't feel it takes any more time to write the proper OO solution than it is to write the procedural hack.
For example:
def operate_on_matrix(matrix):
matrix *= 3
matrix += 5
def draw_matrix(matrix):
c = convert_matrix(matrix)
c.normalize()
draw_screen(my_screen, c)
matrix = [[0]*100]*100
operate_on_matrix(matrix)
draw_matrix(matrix)
Isn't really much shorter than:
class Matrix:
def __init__(self):
self.matrix = [[0]*100]*100
def operate(self):
self.matrix *= 3
self.matrix += 5
def draw(self):
my_screen.draw(self.matrix.converted().normalized
matrix = Matrix()
matrix.operate()
matrix.draw()
And I personally find the latter much more readable.
Procedural code is really just OO code gone wrong
Note that C++ mostly offers syntax sugar over C.
:)
:: replaced by underscores, vtables manually written, and new methods to malloc and call _init methods that you could do without in C++.
In C, you don't really have to 'switch' for polymorphism.
You could use a vtable. You don't have to use malloc and inits, and can write a new and init method for your object. As for a 'dynamic' number of parameters, you'd need a vararg list in C++ too. You're talking about overloaded argument lists, and this can be implemented in C, if you just manually mangle the arglist into the function/method name. C++ doesn't really add conceptual improvements to C (except for exception handling and templates, but both are broken beyond repair), and all of the new C++ syntax is just abbriviating some C underscores
You generally end up with the same C++ code, with
typedef struct {
struct pipe_vtable_s* vtable;
float diameter;
float width;
float height;
} pipe_t;
typedef struct pipe_vtable_s {
float (*flow_rate)(pipe_t* pipe, float x, float y);
} pipe_vtable_t;
float round_pipe_flow_rate(pipe_t* pipe, float x, float y);
float rectangular_pipe_flow_rate(pipe_t* pipe, float x, float y);
pipe_vtable_t round_pipe_vtable = { round_pipe_flow_rate };
pipe_vtable_t rectangular_pipe_vtable = { rectangular_pipe_flow_rate };
void pipe_init(pipe_t* pipe, pipe_vtable_t* vtable,
float diameter, float width, float height) {
pipe->vtable = vtable;
pipe->diameter = diameter;
pipe->width = width;
pipe->height = height;
}
pipe_t* round_pipe_new(float diameter, float width, float height) {
pipe_t* pipe = (pipe_t*)malloc(sizeof(pipe_t));
pipe_init(pipe, &round_pipe_vtable, diameter, width, height);
return pipe;
}
pipe_t* rectangular_pipe_new(float diameter, float width, float height) {
pipe_t* pipe = (pipe_t*)malloc(sizeof(pipe_t));
pipe_init(pipe, &rectangular_pipe_vtable, diameter, width, height);
return pipe;
}
float round_pipe_flow_rate(pipe_t* pipe, float x, float y) {
return stuff;
}
float rectangular_pipe_flow_rate(pipe_t* pipe, float x, float y) {
return stuff;
}
pipe_t *round, *rect;
float result;
round = round_pipe_new(30.0, 0, 0);
result = round->vtable->flow_rate(round, 12.0, 9.0);
rect = rectangular_pipe_new(0, 40, 4);
result = rect->vtable->flow_rate(rect, 12.0, 9.0);
Yes, a lot more pain doing the declarative stuff, but once its done, the actual code is just as simple.
-------------
For goodness sake, don't use that #define PIPE thing, that's what typedef's are for!
And two #defines in a range? That's what enums are for!
Your claims sum up to:
Popularity is a measure of quality:
Should I really have to discredit this one? What has NetBSD or FreeBSD done to make Windows less popular? Nothing. Are they better than Windows for many many useful purposes? Most people think so.
Python webservers, and Python code is often used in server-side, but maybe you haven't done your homework.
Major sites like Google, NASA, Yahoo, FourEleven, Nortel... use it in the core of their products.
There is a huge list of Lisp users, not to mention Java server-side code.
C and C++'s popularity is dying down, and now that Microsoft Marketing will be pushing C# down everyone's throats, it'll probably remain only in the *nix domain, and as hardware improves, eventually die down.
Safe languages are slow:
Much research and comparison of different languages, such as Lisp and C++ seem to contradict this. Many show that most Common Lisp code using a good compiler will in fact execute faster than most C++ code.
Already C compilers try to analyze the low-level code, making out high-level details of it in order to optimize it. Higher-level languages are in fact becoming more optimizable than C as compilers are getting more advanced.
C is more portable:
This is sort of a paradox as Python, Java, etc have C implementations, and require only high-level access, allowing portable implementations anywhere.
Java VM can run both Java and Python code. Java VM's are implemented on more platforms than proper POSIX-compliant C compilers, last I checked.
C is conceptually less portable. High-level languages will easily/natively make use of the new technologies like VLIW, whereas C compilers will have a VERY hard time using that technology in such low-level code.
Programming is hard - therefore lack of safety (note: safety, not security) is acceptable:
Note that not all, but most security problems result from this lack of safety. Unlike your claim, this safety really exists in languages like Python and Lisp.
When was the last time pure Python or Lisp (without C modules) crashed? I've writtens dozens to hundreds of thousands of Python lines, and never experienced crashes in pure Python code. Some C extension modules crashed, as C code often tends to.
The guarantee of safety is not worth the performance hit:
Maybe running a pure Python-code webserver on a 586 100 with 16 megs of RAM is a bad idea.
However, Common Lisp, OCaml, Python code to 'glue' optimized C modules, etc executes fast enough even on the older hardware, and the memory requirements are generally not that bad. Usually something like a factor of 2 or 3, with some constant size addition to C code.
Today's hardware makes the language of your choice irrelevant, as the differences become more and more unnoticable.
This almost-unnoticable 'hit' on performance is definitely worth the guarantee of safety, that eliminates almost all security problems.
Outlook security holes were not solved by safe languages:
True, but VBS *is* safe (not secure, SAFE). This means it does not crash.
Most security problems are already eliminated. As for complete access to the machine, that's a security problem that has nothing to do with the use of safe languages.
Buffer overruns do not occur because programmers do not know how to do bounds checking.
I suppose you meant that programmers do not bound-check properly. Obviously this is the cause of the failures. However, safe languages solve this problem by guaranteeing this can't happen.
We see a lot of buffer overruns occur however, because the only languages truly suitable for most problem domains are the languages that allow these things to happen.
Tell me, how are the unsafe languages such as C or C++ more suitable for daemon coding than Python, Lisp, Scheme, etc?
Python, along with Twisted Matrix, for example, allows for easy, safe, and very fast network daemons. Medusa is an example of a very fast Python webserver, written in much less code than equivalent C\C++, and executing at least as fast.
If Python allows performance, ease of development, reliability and guarantee of security (from such volunerabilities), how is it less suitable than C or C++ for the development of network daemons?
Completeness has nothing to do with that by the way. Reliability, memory usage, speed and portability issues have.
Reliability, and portability issues are both voting against C and C++.
As for speed, safe languages prove to be at least fast enough for I/O-bound applications. Some safe languages (Common Lisp, OCaml) even prove to compile to much more efficient code than C\C++ in many cases.
Besides, if programmers can't get something simple like array indexing right, then how are they going to get the much, much, much more complicated domain-specific safety issues right?
That's bull. All programmers make mistakes. What you are talking about here is the ability to make 0 mistakes as far as array indexing, pointer management, and other low-level issues are concerned. Firstly, there are always potential mistakes in any part of a program. Secondly, pointer management (killing dangling pointers correctly, managing complex pointing graphs, etc) is not trivial at all.
Therefore, a language that makes you a guarantee of safety in those regards, and handles all those low-level issues automatically and correctly, is a huge benefit.
And how are you going to prove that your favorite Common LISP implementation actually does not violate any of the requirements? Look at how "safe" a language like Javascript is. Or Visual Basic.
You're not going to prove it, but debugging a single, finite code base (A compiler) is a hell of a lot easier than debugging and correcting infinite amounts of code written all the time. To claim it is as hard to maintain correctness of the compiler as it is of EVERY program out there is absurd.
As for Visual Basic and Javascript, my experience is that they are safe in those regards. They are obviously (at least Visual Basic) not examples of stable well-tested platforms, as many of the Lisp, Python, and other compilers/VM's are (especially when considering the reputation of the creators).
You see where I am coming from, when your C code malfunctions, that is not a flaw with C -- it's a flaw in your code.
Assuming the goals of your language are to ease development and provide the best platform for developing software, a language that does not provide a guarantee of safety is far inferior to one that does, in terms of fulfilling those goals.
any ability to write to the accounting files.
If that is considered a design requirement,
then the design was wrong.
But the compiler IS outputting accounting information here.
Its easy to claim that any design requiring a certain feature *nix cannot provide is wrong, but it sounds quite an absurd claim to me. You're trying to adjust the world to your OS, rather than write an OS that fits your needs.
In terms of debug/frequency stats, create a
directory, make the compiler setuid or gid
to be able to write there, and put the stats
and ONLY the stats in that directory (
you do the set(ug)id, at the very end,
just to write the stats file as the last
hurrah.) Or even just leave it public write,
if someone wants to futz with your stats
they really have time on their hands.
Problems:
How is your solution preventing the original problem of a malicious user naming a billing filename as an output file?
As long as the compiler 'changes hats' (Setuid/gid), the privelege-checking is quite complex and will probably result in VERY complex ACL's to achieve the goal.
These stats are used for billing information, and people would thus be VERY willing to mess with them.
All these security settings require root to set up, meaning that only a system administrator is capable of setting up any system involving security checks.
Alternative approach:
The mechanism used to identify (name) objects is that of unforgable, OS-implemented keys called "capabilities". These capabilities are much like *nix file descriptors, but they are never open()'d or close()'d. Having the capability is a necessary and sufficient condition to access the named object, the object does not care who access it.
The above example, is very simply solved by capabilities:
In order to name the billing file to the compiler, the user must have a capability to that billing file. In that case, the user is fully authorized to access this file. Obviously, the user does not have a capability to this file, only the compiler does, and since there is no way to forge a capability (just like file descriptors), the user cannot name the file he must not access, and may not confuse the deputy.
Advantages:
Users (code) can only express requests by access to a capability, meaning that code is only capable of expressing authorized requests. This means that there is no ACL test failure that may give false access to this user, as the mere ability to express a request is an indication of authority to do it.
The only security test required at runtime is that the capability is valid, which is equivalent to the validity test of a file descriptor, nearing 0 time.
Capability systems are in fact simpler systems, and many security properties of such can be mathematically proven, as demonstrated by Shapiro, in his proof of part of his EROS system.
Capabilities have per-process granulity, rather than per-user granulity, and very fine-grained control of which objects every process has access to, thus the principle of least privelege is implemented.
No need for a 'super user' that bypasses ACL's, because that would destroy the principle of least privelege. Every user can create objects and spawn capabilities to use those objects, and distribute them through every channel he has a capability to.
This means any process with some minimal set of capabilities can set up a security system, not requiring any super user to bother, and killing the vast majority of threats involving a superuser.
Safe languages are languages incapable of expressing things like buffer overruns or overrunning other memory, or invalid array indexing. This means they cannot express corruption of memory and are not volenurable to the vast majority of problems in most things today. Those languages, including Python, Smalltalk, Lisp, Perl, and others are incapable of crashing the machine (although sometimes C modules written for these do crash the machine), yet are Turing Complete and capable of solving any problem C, C++, or other unsafe language is capable of solving.
The alternative, of course, is to ban the use of graphical interfaces on that system; but usually that is unacceptable.
The real way of doing this is putting the hardware drivers into the kernel (frame buffer devices).
No user process is supposed to access hardware directly, and if that meant we have no graphics, it would also mean no keyboard, text, or sound.
Although these issues can all be addressed, the problem of proper kernel security is at best a "whack a mole" situation in which a new hole will arise shortly after an existing hole is patched. Thus, the HP-LX software probably isn't worth the CD it is pressed onto.
That may be true, but it is only because of the nature of UNIX kernels. Kernels built with the principle of least privelege in mind (such as EROS) are definitely worth the fix, as it is quite unlikely to present new holes (and such a design is quite unlikely to have many holes in the first place)
The Confused Deputy will stay confused, no matter how sophisiticated the ACL's are.
The only real approach to security is a pure capability system, and ofcourse the combination of pure capbility systems with safe languages.
And software security is nothing without physical security.
Besides, a firewall is not a solution, a pure capability system like EROS or Vapour is.
The people ""pirating"" software are only causing financial damage if, and only if they would otherwise pay for the software. The percentage of people who would actually pay for ""pirated"" software is extremely low, not to mention much lower than 100%.
When stealing, you enrich yourself at the expense of someone else. When ""pirating"", you enrich yourself, period. At worst, you enrich yourself at the expense of a dubious incentive to create.
As shown by much research, the worst creative incentive is money. The best and most original creators were motivated by their own need of creation. Also, a free market will always generate required products, even be that free information. Assuming all software is free by enforced law, a company requiring software not yet available, will pay for its creation. A user requiring software will simply get the latest and greatest from Gnome, KDE, XFce, or the vast free collection that would exist had all software been enforced free. Development will be far more efficient, as the entire world's existing code base is reusable in your software components!
The vast majority of people I know ""pirate"".
They do so because they don't believe in paying high prices for artifical scarcity, and because they don't really value copyrights.
How are these not moral reasons?
Are these reasons selfish?
There are perfectly valid world and moral views that dismiss intellectual property as an immoral limitation on freedom, that does not encourage innovation, but rather reinventing the wheel every time as the original wheel is copyrighted.
Aritificial scarcity is not only impractical (as shown by the ease of ""pirating""), but also unhelpful and immoral.
Now for something else you don't want to hear: Microsoft is justified in whining. They do have many, many people using their software without paying. Even if we see the software as crap, it's apparently "good enough" to be pretty damn popular. They deserve payment for that 24% (for Windows, probably more) of their software that's being pirated.
Microsoft has gained their wealth in far worse, illegal means than piracy. Do they really deserve any money at all? If money is an incentive, is Microsoft the example to set as the model of gaining money? Would the people ""pirating"" this software really pay to use this software?
And their attempts to stop piracy haven't been unfair, either! There's all this complaining about the Windows Auth Code -- and not even anecdotal evidence of it harming anyone. So you let the software authorize itself, big deal. For the tiny, tiny percentage of people who upgrade a lot, they just need to give MS a call, and MS will authorize their new code. Big deal.
Calling "Big Brother" for every upgrade, and/or having troubles upgrading and/or using the system is unacceptable to many, many people.
Last I checked, it wasn't a crime.
If you're so paranoid about it being found out, put it in a bag first, but don't blame the cameras, as any Joe Schmoe can see you too.
You cannot expect privacy in the street:
If a camera can see you, so can a human eye.
The only reason to fear being filmed by cameras is if you're planning on lying in your side of the story, hoping to have a word-against-word case, rather than a word-against-video. And then - what are you lying to protect?
There is no right way to name your string hierarchy (i.e a file system).
Since there is no proper convention of attributing things such as title, content, author, etc. on the file (only type, in the extension), these are conviniently put in the file name.
The problem here is not spaces in file names, but the weakness of a string hierarchy.
File systems are dated technology (EROS Tunes...)
Try to compare the loss of life from space debris, and from chemcial/other missles that can be shot from Iraq/Iran/etc.
Where would you put your money?
As someone already mentioned, the travelling salesman problem is about finding the *optimal* solution. For any practical purpose, a near-optimal solution can be found, and there are P solutions to this problem.
A certain P solution can be proven to always find a path at most twice the length of the optimal one.
Called compression?
Information theory proves that two sides that can transmit data to each other can transmit any information they want with any tunneling they want.
:)
As for shutting down servers... A gnutella-type network may replace the www for typical restricted things. Outlawing the use of software is quite a difficult problem, and 'solutions' will always be found.
These two things above combined, mean that the Internet may never lose its information freedom, no matter how powerful or how badly some government wants.
Information theory is on our side, stop worrying so much
This comment is funny, not insightful :)
:)
And I agree with the Debian part
I have the same problem when it comes to helping my daughter with her math homework. I can't help her because I can't explain how to do it. I just do the problems instinctively. I send her to her mom, or to our next door neighbor (who is a math teacher).
Someone who is really good at maths, knows to break down the solution to the smallest pieces and explain the pieces. One who is good enough would find ways requiring less creativity to solve the problems, at least of some genre.
The problem with the education system is that they teach the what, and not the how or why, and I wouldn't trust a school teacher to do a good job at teaching, but maybe that's just the Israeli teachers..
That's one of the stupidest things I've read today.
DOS is a thin file-access and memory allocation library, with a very small and weak command shell, on top of the BIOS routines. Applications mostly serve as their own OS, or use the BIOS.
The reason DOS "itself" crashes little, is because there is almost none of it!
In fact, applications crashing the entire machine is exactly the reason DOS is completely unstable. It is the responsibility of the OS to ensure system stability.
which in the end is motivated mostly by economic concerns and nationalism and can be easily solved via some redistricting, establishment of a Palestinian nation, and economic aid to the Palestinians (well, it can be easily solved if you get the two sides to stop shooting for long enough, and you throw out the radicals on both sides who oppose any middle ground solutions).
More easily said than done. For peace, the majority has to support peace. After the Palestinian violence of the last year, there is no majority for peace. Even before so, there was no middle ground of agreement about the refugee problem.
The Israeli/Palestinian conflict cannot be easily solved.
I'm horrified at how IDE has flourished. It's the worst possible standard for a drive interface.
:)
If you ever wrote FDC drivers, you'd know that's not true.
You misspelled Python as Perl there :)