No pointers. This is Cg's most serious omission. Pointers are necessary for storing scene graphs, so this will quickly become a serious omission for vector processors that can store and process the entire scene or even sections of it.
You do not need (C-style) pointers for high performance graphics. You do not need pointers even for representing relational structures. People have been implementing graph algorithms in languages without pointers since before most of us were born. You can even do it in a language as tedious as Fortran 66. C pointers are a bizarre aberration in language design and play havoc with high performance computing and optimization. You have to jump through hoops in order to even optimize siple uses, and then add lost of special purpose declarations to make them work. Any use of C pointers can be replaced with the use of arrays and integers (but the logic of your program may change dramatically).
Another reason pointers are generally not such a good idea in graphics or high performance is that they have to be large enough to address all of memory. An index into a array can be 1, 2, 3, or 4 bytes long depending on how much data it actually needs to address. That can lead to saving a lot of space.
When dedicated C hackers make such statements, it is understandable. But a company in the business of writing high performance compilers ought to be familiar with the work, programming styles, and languages that people in high performance computing adopt, and those often don't include pointers. C programmers want pointers becaues they are used to them, and CodePlay is in the business of satisfying this desire, but that doesn't make it a good engineering choice.
Incidentally, I program in C++, including numerical and graphics code. It is quite easy to eliminate most uses of pointers from C++ code, and the result is code that is a lot easier to debug and often run faster, too.
There are many factors that influence climate. But we know for certain that CO2 levels have increased dramatically already, due to human activity, and that increase continue. If we don't stop that, that will lead to massive, unpredictable changes in our climate and that just can't be good. Looking at temperature records is secondary.
What does a vectorizing compiler for a C-like language for the x86/PS2 have to do with a C-like shader language for nVIDIA graphics processors? It seems to me they are different languages for different purposes, even running on different parts of the same system.
Yup, Perl is "capable" of complex programming tasks. I just think other languages are more suitable when things go beyond small scripts, and unless you are language-phobic, why not learn a bunch of them and use the best one for the task?
Try http://games.yahoo.com/ and
http://www.smartmoney.com/marketmap/ There are also plenty of very useful Java applets being used for education and scientific results.
And there are many tiny Java applets for menus, buttons, and counters that you probably don't even notice.
Assuming you are willing to use 2 to 4 times more memory for the Java wordprocessor equivalent and take a 50% speed hit relative to C++, it certainly could be written in Java. (Java only matches C++ speed in benchmarks where objects are not created).
It really doesn't make too much sense to compare Java and C++ in that way. For example, yes, "object creation" in Java is slower than in C++, but the two don't do the same thing.
In general, Java requires a different programming style from C++ to get efficient code. There are many habits C++ programmers acquire to keep their C++ programs from crashing and to interact well with C++'s constrained memory management. Many of those habits are meaningless and costly in Java. Java is not a "simple and safe C++", it's a very different language.
Ever try to debug a Swing problem? You often get stack traces that are more than 25 levels deep - all in Sun's Swing code. Temporary objects being created like there is no tomorrow. Any way you slice it, Swing is a horribly designed graphics toolkit.
I have had no problems with Swing--it seems like one of the better toolkits around in terms of its APIs. Its implementation is rather inefficient, but on modern hardware, it doesn't seem to matter all that much.
In the case of a JIT JVM, you are correct. [lots more verbiage]
There are interpreters for C and C++ as well. Does that make C and C++ "interpreted languages"? The fact is that there are excellent native code compilers for Java, both JIT and batch. Java is as much a compiled language as C++.
however, the basic execution is bytecode interpretation.
For some uninteresting definition of "basic" that may be true. In real life, however, with a good JIT, all compute-intensive Java code is compiled into native code. Java byte code that is executed rarely may be interpreted, but that doesn't matter for performance, exactly because it's rare (in fact, it saves memory).
Of course the reverse is also true; the Java bytecode compiler cannot do as much type checking as a C++ compiler can, and it cannot do some of the optimizations that C++ can because until runtime it cannot know if they will be usefull or not.
That is utter nonsense. A JIT has much more type information and much more statistical information available to it than any C++ compiler. Furthermore, the Java language spec prohibits aliasing in many cases in which C++ does not, giving Java compilers a lot more opportunity for optimization where a C++ compiler can't do anything. So, even a batch compiler for Java has a lot more opportunities for optimization than a batch compiler for C++.
This is mostly offtopic and mostly pedantic, but, as a developer who uses several languages, I hate to see silly comments by language biggots go unchallanged. Always remember: All languages suck; some just suck less in a given situation than the others do.
When arguments fail you, you resort to insults? All I said was that Java is natively compiled (i.e., that there are native compilers for it) and that it offers more opportunities for optimization, two statements that I completely stand by.
Java is not interpreted. It's compiled to native code, with optimizations and features that C++ compilers simply can't do (e.g., inlining of functions and methods from dynamically loaded code).
Development hurdles that Sun must overcome are removing and redesigning X11 protocol specific code to work with Quartz 2D -- Apple's windowing API -- and redesigning the user interface such that it conforms to the Apple Aqua guidlines.
Rather than addressing this for each application over and over again, Apple should really just improve X11 support on OSX and ship an X11 server with every Macintosh. X11 is quite small compared to other software these days, and to many new Mac users, good X11 support is essential.
Supporting Apple's look-and-feel and guidelines is a separate issue and doesn't depend on whether the low-level graphics is based on X11 of Quartz.
he ever-pressing issue of how to make money by selling an essentially open-source product. Sun plans to do this not by merely offering support,
Sun should be happy if they get a significant user community for OpenOffice at all because that makes their hardware and software more viable. Trying to make money off it at the same time is killing the goose.
Even though JVMs improved a lot in the meantime, there's no way a JVM is going to make an app such as OpenOffice as smooth to use as a native version.
Sure there is. Java is quite fast these days and it has gotten a lot more stable and robust. OpenOffice could actually become smaller and simpler if it is written in Java because much of the big and complex stuff in OpenOffice is already taken care of by the Java runtime.
Also, Sun finally needs to put the resources behind Java for client/desktop apps--that means developing large and complex client/desktop apps and fixing whatever problems remain in Java and the Java runtime.
Corel already tried and we all saw the result: slow and dismissed by the market.
Corel didn't know what they were doing and they didn't have the option of hacking the Java runtime much. Besides, there are an awful lot of bad or failed C and C++ applications--should we stop using C and C++ because of that as well?
The O'reilly Perl library is an invaluable resource for education in the more difficult (and not-so-difficult) areas of Perl.
I agree with that statement. I just recommend that once things start getting difficult, people should start using something other than Perl. For the kinds of things Perl is really good at, little scripts, you don't need a lot of books.
If you are looking for a concise book on C++, look at Pohl's "C++ Distilled".
For Java, a smart person with a little computer background should be able to figure it out from the language definition. Any of the more complex topics in Java change so quickly that it isn't worth buying books on them anyway--just use the on-line references. Sun has on-line tutorials ("trails") at developer.java.sun.com, left over from the days when Java wasn't hot yet and when they still had to bother recruiting people to Java.
For Perl, I wouldn't bother with any kind of reference. Just find scripts that roughly do what you want and hack them; it's blind groping around, but that's the way Perl works. If you can't get it to work that way, you probably should be writing in something else other than Perl. If you must, get something like the Perl Cookbook and a quick reference guide.
For Python, I like "Python and Tkinter Programming" and "The Quick Python Book", although O'Reilly's reference is also decent.
For a fun yet challenging introduction to computer programming, "Structure and Interpretation of Computer Programs" is good. What makes it even better is the fact that it's a book that teaches modern abstraction techniques but does not rely on object-oriented programming for everything. Most people coming to computers and computer programming wrongly think that objects are either the best, or even the only, way to build abstractions.
Unfortunately, most of the UNIX stuff just doesn't run well on Windows XP: path names, terminals, etc. on Windows are just wildly different from UNIX. If Windows XP actually shipped with a working, decent BSD personality, it would be a lot more tolerable. But instead of adding UNIX/BSD functionality, Microsoft is steadily making Windows XP less compatible with the rest of the world.
Technically, the most interesting aspect of Apple's Unix is its use of Adobe's PDF imaging model. This is based on the PostScript imaging model from NeXtStep, within the MacOS X layer instead of the more traditional X Window System-based approach.
Maybe that's "interesting", but it isn't really much of an advantage. First of all, X11 now supports the same imaging model (antialiasing, transparency, etc.). Also, it takes the wind out of the sails of people who like to complain about client/server window systems: Apple and X11 both are client/server. Even Windows XP is, although the server is now in the kernel because Microsoft couldn't figure out how to take an old direct drawing API and convert it into an efficient client/server protocol.
With Darwin you can add X11 at any time, and even run both concurrently, but the imaging system defaults to the PostScript-derived PDF display model.
You can "add X11" to just about any window system any time--X11 is a fairly simple protocol (WeirdX is a whole 200k large). But X11 on the Mac works by drawing unaccelerated into off-screen bitmaps and then blitting them into screen memory. That was the easiest way of taking an existing X11 server and adapting it to the Mac, and it was the only way the developers could easily guarantee accurate rendering. And, somewhat ironically, X11 graphics applications in that mode often seem to run faster than native Mac applications (at least on my G4 Mac) despite all the blitting, and they consume less memory, too.
I'd say that Quartz is a decent graphics system, if a bit resource intensive. I'd also say that Apple would have been better off in the long run using X11 directly as a back-end for their desktop--the programming model, look, and feel would have been indistinguishable, and things would have run faster and required less memory. But it would also have been a lot of work--NeXTStep was based on Postscript, and converting that to PDF was probably the path of least resistance. However, necessity isn't really a virtue: Display PDF is not something the rest of the UNIX/Linux world should or will emulate.
However, the elegant look and ease-of-use of many of the of the Mac desktop applications and utilities is something Linux can and should emulate.
Technically, I think the most important technical difference (as opposed to available applications, which, of course, differ greatly) to users between OSX and Linux is the kernel: the OSX kernel really does seem to allow kernel extensions to be distributed and installed with much less headaches than Linux.
Why does this have anything to do with his employer? Is Perens employed by HP for the purpose of breaking DVD players? If he is doing it on his own time, HP shouldn't care and shouldn't be liable (of course, they might still want to fire him for violating a law, but that's another issue).
Matloff implicitly assumes that there is some fixed number of US jobs and that the US has some say in the matter who gets them. But those programming jobs don't belong to the US. The foreign programmers are not going to take up knitting if they can't work in the US. They will either work for the same company in a different country, or they will end up competing against the US company, having much lower salaries and overhead.
In these arguments, people keep assuming that there is some fixed number of job slots in the US that either get filled with US citizens or foreigners.
That's the wrong model. These jobs are created in the US because that's where the programmers want to live. Companies are competing for programmers internationally, and a US location is merely another benefit, like health care and stock options. If the US restricts the availability of that benefit, companies are still going to hire the same people, they are just going to work in different locations. If it were up to companies, they would dearly love to employ programmers in India, Asia, or Europe, where salaries and other costs are generally much lower than in, say, Silicon Valley or NYC.
And if it were up to foreign governments, they would like to see nothing more than to have the US restrict skill-based visas and immigration because the US, quite unfairly, takes advantage of the well-functioning social services and educational systems of other countries to replenish its own labor market. That's why California can get away with such an underfunded educational system and still have a high-tech industry.
The US really only has two choices: let foreign programmers into the country and derive the economic benefits in taxes from that, or see those jobs and programmers go overseas. In the era of global software companies and outsourcing, it is simply not possible to force companies to give programming jobs to Americans if they don't think it's in their interest.
You assumed, but I didn't say anything specifically either about NFS or about using POSIX APIs to implement ACLs on networked file systems.
Obviously, in order to be useful for a networked file system, the ACL APIs you need to support on the client are those required by the network file system used by the server. Those can be different from the ACL APIs either used by the local file system or by the server's file system. Take a look, for example, at what AFS does (I'm not endorsing it, merely pointing out what it does).
You are missing the point. Of course, you could somehow check even if GNU ls did't do that. The point is: it's one more thing to go wrong. And it's not just that people need to pay attention--security audit tools need to deal with this, and they need to be configured to interpret the ACLs correctly.
ACLs just make things much more complex, in many cases unnecessarily so. And it certainly doesn't make things more secure.
you could totally ignore them if you didn't want to use them
You can't "totally ignore them", in particular when it comes to system security. ACLs allow people to get additional access to files relative to standard UNIX permissions, and that is something that needs to be checked. With ACLs, not only do I have to check whether/etc/passwd is owned by root, I also have to check whether someone has snuck in and given themselves write access to it through ACLs.
I would be really happy about a similar implementation being a part of Linux and not just a patch.
It should probably be in the kernel, but I think it should not be enabled by default because it creates security holes and because the functionality just isn't needed for many applications. Desktop users of Linux often don't need a complex permission system at all, and neither do many server applications (dedicated web server, dedicated database server, etc.).
Where ACLs will be most useful will be for Linux clients accessing network file systems that have them. That's the reason why they should be in the kernel, but they should be enabled only for specific file systems. But in that case, ACLs are there for interoperability, not for additional security.
Let me second that. Having had to untangle ACLs as a system manager when converting file systems to UNIX, my observation is that they often don't do what users intend. Furthermore, systems I have used that have had ACLs may have passed various security certifications but were very easy to break into in practice because in real life, ACLs were never set up right.
The traditional UNIX user/group system requires some advance thought and effort in setting up groups for an organization. That leads to a more manageable set of possible permissions.
ACLs are an important check-list item for Linux because there are some people who swear by them. But I also hope that as a system manager, I will never have to deal with them again--I think they are much more trouble than they are worth in the real world.
With very few exceptions, adding more stuff to your kernel doesn't make it more secure. ACLs, for example, make it very easy to screw up in numerous ways.
One of the best ways to keep your system secure is to keep it simple: remove daemons, remove kernel modules, remove software you don't need, etc.
Slashdot Mirror
You do not need (C-style) pointers for high performance graphics. You do not need pointers even for representing relational structures. People have been implementing graph algorithms in languages without pointers since before most of us were born. You can even do it in a language as tedious as Fortran 66. C pointers are a bizarre aberration in language design and play havoc with high performance computing and optimization. You have to jump through hoops in order to even optimize siple uses, and then add lost of special purpose declarations to make them work. Any use of C pointers can be replaced with the use of arrays and integers (but the logic of your program may change dramatically).
Another reason pointers are generally not such a good idea in graphics or high performance is that they have to be large enough to address all of memory. An index into a array can be 1, 2, 3, or 4 bytes long depending on how much data it actually needs to address. That can lead to saving a lot of space.
When dedicated C hackers make such statements, it is understandable. But a company in the business of writing high performance compilers ought to be familiar with the work, programming styles, and languages that people in high performance computing adopt, and those often don't include pointers. C programmers want pointers becaues they are used to them, and CodePlay is in the business of satisfying this desire, but that doesn't make it a good engineering choice.
Incidentally, I program in C++, including numerical and graphics code. It is quite easy to eliminate most uses of pointers from C++ code, and the result is code that is a lot easier to debug and often run faster, too.
There are many factors that influence climate. But we know for certain that CO2 levels have increased dramatically already, due to human activity, and that increase continue. If we don't stop that, that will lead to massive, unpredictable changes in our climate and that just can't be good. Looking at temperature records is secondary.
What does a vectorizing compiler for a C-like language for the x86/PS2 have to do with a C-like shader language for nVIDIA graphics processors? It seems to me they are different languages for different purposes, even running on different parts of the same system.
Yup, Perl is "capable" of complex programming tasks. I just think other languages are more suitable when things go beyond small scripts, and unless you are language-phobic, why not learn a bunch of them and use the best one for the task?
Try http://games.yahoo.com/ and http://www.smartmoney.com/marketmap/ There are also plenty of very useful Java applets being used for education and scientific results. And there are many tiny Java applets for menus, buttons, and counters that you probably don't even notice.
It really doesn't make too much sense to compare Java and C++ in that way. For example, yes, "object creation" in Java is slower than in C++, but the two don't do the same thing.
In general, Java requires a different programming style from C++ to get efficient code. There are many habits C++ programmers acquire to keep their C++ programs from crashing and to interact well with C++'s constrained memory management. Many of those habits are meaningless and costly in Java. Java is not a "simple and safe C++", it's a very different language.
Ever try to debug a Swing problem? You often get stack traces that are more than 25 levels deep - all in Sun's Swing code. Temporary objects being created like there is no tomorrow. Any way you slice it, Swing is a horribly designed graphics toolkit.
I have had no problems with Swing--it seems like one of the better toolkits around in terms of its APIs. Its implementation is rather inefficient, but on modern hardware, it doesn't seem to matter all that much.
There are interpreters for C and C++ as well. Does that make C and C++ "interpreted languages"? The fact is that there are excellent native code compilers for Java, both JIT and batch. Java is as much a compiled language as C++.
however, the basic execution is bytecode interpretation.
For some uninteresting definition of "basic" that may be true. In real life, however, with a good JIT, all compute-intensive Java code is compiled into native code. Java byte code that is executed rarely may be interpreted, but that doesn't matter for performance, exactly because it's rare (in fact, it saves memory).
Of course the reverse is also true; the Java bytecode compiler cannot do as much type checking as a C++ compiler can, and it cannot do some of the optimizations that C++ can because until runtime it cannot know if they will be usefull or not.
That is utter nonsense. A JIT has much more type information and much more statistical information available to it than any C++ compiler. Furthermore, the Java language spec prohibits aliasing in many cases in which C++ does not, giving Java compilers a lot more opportunity for optimization where a C++ compiler can't do anything. So, even a batch compiler for Java has a lot more opportunities for optimization than a batch compiler for C++.
This is mostly offtopic and mostly pedantic, but, as a developer who uses several languages, I hate to see silly comments by language biggots go unchallanged. Always remember: All languages suck; some just suck less in a given situation than the others do.
When arguments fail you, you resort to insults? All I said was that Java is natively compiled (i.e., that there are native compilers for it) and that it offers more opportunities for optimization, two statements that I completely stand by.
Java is not interpreted. It's compiled to native code, with optimizations and features that C++ compilers simply can't do (e.g., inlining of functions and methods from dynamically loaded code).
Rather than addressing this for each application over and over again, Apple should really just improve X11 support on OSX and ship an X11 server with every Macintosh. X11 is quite small compared to other software these days, and to many new Mac users, good X11 support is essential.
Supporting Apple's look-and-feel and guidelines is a separate issue and doesn't depend on whether the low-level graphics is based on X11 of Quartz.
he ever-pressing issue of how to make money by selling an essentially open-source product. Sun plans to do this not by merely offering support,
Sun should be happy if they get a significant user community for OpenOffice at all because that makes their hardware and software more viable. Trying to make money off it at the same time is killing the goose.
Sure there is. Java is quite fast these days and it has gotten a lot more stable and robust. OpenOffice could actually become smaller and simpler if it is written in Java because much of the big and complex stuff in OpenOffice is already taken care of by the Java runtime.
Also, Sun finally needs to put the resources behind Java for client/desktop apps--that means developing large and complex client/desktop apps and fixing whatever problems remain in Java and the Java runtime.
Corel already tried and we all saw the result: slow and dismissed by the market.
Corel didn't know what they were doing and they didn't have the option of hacking the Java runtime much. Besides, there are an awful lot of bad or failed C and C++ applications--should we stop using C and C++ because of that as well?
I agree with that statement. I just recommend that once things start getting difficult, people should start using something other than Perl. For the kinds of things Perl is really good at, little scripts, you don't need a lot of books.
For Java, a smart person with a little computer background should be able to figure it out from the language definition. Any of the more complex topics in Java change so quickly that it isn't worth buying books on them anyway--just use the on-line references. Sun has on-line tutorials ("trails") at developer.java.sun.com, left over from the days when Java wasn't hot yet and when they still had to bother recruiting people to Java.
For Perl, I wouldn't bother with any kind of reference. Just find scripts that roughly do what you want and hack them; it's blind groping around, but that's the way Perl works. If you can't get it to work that way, you probably should be writing in something else other than Perl. If you must, get something like the Perl Cookbook and a quick reference guide.
For Python, I like "Python and Tkinter Programming" and "The Quick Python Book", although O'Reilly's reference is also decent.
For a fun yet challenging introduction to computer programming, "Structure and Interpretation of Computer Programs" is good. What makes it even better is the fact that it's a book that teaches modern abstraction techniques but does not rely on object-oriented programming for everything. Most people coming to computers and computer programming wrongly think that objects are either the best, or even the only, way to build abstractions.
Unfortunately, most of the UNIX stuff just doesn't run well on Windows XP: path names, terminals, etc. on Windows are just wildly different from UNIX. If Windows XP actually shipped with a working, decent BSD personality, it would be a lot more tolerable. But instead of adding UNIX/BSD functionality, Microsoft is steadily making Windows XP less compatible with the rest of the world.
Maybe that's "interesting", but it isn't really much of an advantage. First of all, X11 now supports the same imaging model (antialiasing, transparency, etc.). Also, it takes the wind out of the sails of people who like to complain about client/server window systems: Apple and X11 both are client/server. Even Windows XP is, although the server is now in the kernel because Microsoft couldn't figure out how to take an old direct drawing API and convert it into an efficient client/server protocol.
With Darwin you can add X11 at any time, and even run both concurrently, but the imaging system defaults to the PostScript-derived PDF display model.
You can "add X11" to just about any window system any time--X11 is a fairly simple protocol (WeirdX is a whole 200k large). But X11 on the Mac works by drawing unaccelerated into off-screen bitmaps and then blitting them into screen memory. That was the easiest way of taking an existing X11 server and adapting it to the Mac, and it was the only way the developers could easily guarantee accurate rendering. And, somewhat ironically, X11 graphics applications in that mode often seem to run faster than native Mac applications (at least on my G4 Mac) despite all the blitting, and they consume less memory, too.
I'd say that Quartz is a decent graphics system, if a bit resource intensive. I'd also say that Apple would have been better off in the long run using X11 directly as a back-end for their desktop--the programming model, look, and feel would have been indistinguishable, and things would have run faster and required less memory. But it would also have been a lot of work--NeXTStep was based on Postscript, and converting that to PDF was probably the path of least resistance. However, necessity isn't really a virtue: Display PDF is not something the rest of the UNIX/Linux world should or will emulate.
However, the elegant look and ease-of-use of many of the of the Mac desktop applications and utilities is something Linux can and should emulate.
Technically, I think the most important technical difference (as opposed to available applications, which, of course, differ greatly) to users between OSX and Linux is the kernel: the OSX kernel really does seem to allow kernel extensions to be distributed and installed with much less headaches than Linux.
Or, to put it more succinctly: "Windows is only free if you pirate it and your time is worth nothing."
Why does this have anything to do with his employer? Is Perens employed by HP for the purpose of breaking DVD players? If he is doing it on his own time, HP shouldn't care and shouldn't be liable (of course, they might still want to fire him for violating a law, but that's another issue).
Matloff implicitly assumes that there is some fixed number of US jobs and that the US has some say in the matter who gets them. But those programming jobs don't belong to the US. The foreign programmers are not going to take up knitting if they can't work in the US. They will either work for the same company in a different country, or they will end up competing against the US company, having much lower salaries and overhead.
That's the wrong model. These jobs are created in the US because that's where the programmers want to live. Companies are competing for programmers internationally, and a US location is merely another benefit, like health care and stock options. If the US restricts the availability of that benefit, companies are still going to hire the same people, they are just going to work in different locations. If it were up to companies, they would dearly love to employ programmers in India, Asia, or Europe, where salaries and other costs are generally much lower than in, say, Silicon Valley or NYC.
And if it were up to foreign governments, they would like to see nothing more than to have the US restrict skill-based visas and immigration because the US, quite unfairly, takes advantage of the well-functioning social services and educational systems of other countries to replenish its own labor market. That's why California can get away with such an underfunded educational system and still have a high-tech industry.
The US really only has two choices: let foreign programmers into the country and derive the economic benefits in taxes from that, or see those jobs and programmers go overseas. In the era of global software companies and outsourcing, it is simply not possible to force companies to give programming jobs to Americans if they don't think it's in their interest.
Obviously, in order to be useful for a networked file system, the ACL APIs you need to support on the client are those required by the network file system used by the server. Those can be different from the ACL APIs either used by the local file system or by the server's file system. Take a look, for example, at what AFS does (I'm not endorsing it, merely pointing out what it does).
ACLs just make things much more complex, in many cases unnecessarily so. And it certainly doesn't make things more secure.
You can't "totally ignore them", in particular when it comes to system security. ACLs allow people to get additional access to files relative to standard UNIX permissions, and that is something that needs to be checked. With ACLs, not only do I have to check whether /etc/passwd is owned by root, I also have to check whether someone has snuck in and given themselves write access to it through ACLs.
I would be really happy about a similar implementation being a part of Linux and not just a patch.
It should probably be in the kernel, but I think it should not be enabled by default because it creates security holes and because the functionality just isn't needed for many applications. Desktop users of Linux often don't need a complex permission system at all, and neither do many server applications (dedicated web server, dedicated database server, etc.).
Where ACLs will be most useful will be for Linux clients accessing network file systems that have them. That's the reason why they should be in the kernel, but they should be enabled only for specific file systems. But in that case, ACLs are there for interoperability, not for additional security.
The traditional UNIX user/group system requires some advance thought and effort in setting up groups for an organization. That leads to a more manageable set of possible permissions.
ACLs are an important check-list item for Linux because there are some people who swear by them. But I also hope that as a system manager, I will never have to deal with them again--I think they are much more trouble than they are worth in the real world.
One of the best ways to keep your system secure is to keep it simple: remove daemons, remove kernel modules, remove software you don't need, etc.
There are plenty of other printer companies to make up for that: Lexmark, Epson, other Japanese ones, ...
With these stories, why do they alway show objects that are a couple of thousand miles large and plop into the earth like a pebble into a big pond?