Yes, if you use C++ with a decent class library and good programmers, you get good runtime safety. The problem with C++ is that if you have a large project with lots of ex-C programmers, they sneak in unsafe code everywhere and usually don't even understand that they are doing so.
Nevertheless, it would probably be a big step forward if Linux and BSD allowed C++ code in the kernel.
This work plan does not include scopes outside of "mail from" and "pra",
Do we know for certain that Microsoft isn't also claiming rights to PRA? After all, their disclosure of intellectual property interests explicitly cites PRA.
Same problem: C is a language that makes it difficult to write correct code, for numerous reasons.
A systems programming language with error checking needs to handle both automatic storage management and array bounds checking (plus a few other compile-time and runtime tests that are missing from C). Users should also be able to turn off either/both selectively and explicitly.
There are debugging tools out there which reliably find these bugs in C/C++ and FORTRAN.
No, they don't find them "reliably", they only find them if you happen to have a test case that triggers the bug and you run the software under valgrind or purify when you execute the test case. For security problems arising from buffer overflows, the probably is usually that developers don't even think of the case.
Tools such as these help to find problems, while avoiding the inefficiency of array bounds checking on each access.
The "inefficiency" of array bounds checking is a few percent in real code, hardly a big cost. But it's wrong to look at that cost by itself anyway--the question is: if you don't have array bounds checks in the compiler, what are you going to do instead? And pretty much everything you are going to do instead is going to be much more costly. Using languages in which unsafe array access are the default is penny wise and pound foolish.
And in really performance critical code, you can selectively turn it off in most languages.
The C dialect in Plan 9 is not very different from ANSI C; it doesn't address safety or security issues. Alef, on the other hand, looks pretty similar to C, but I believe is considerably safer than C.
Because of changes in technologies, business models and service offerings (e.g. horse and buggy, carrier pidgeon), law enforcement authorities are concerned that some data may not always be stored by all communications operators to the same extent as they were in recent years. Public authorities believe that they just are not able to catch up with a horse-and-buggy by running after it on foot anymore, or to get a carrier pidgeon to reveal its destination through torture, like they could with messages delivered by messengers traveling on foot.
As for not using C, I've read that Theo de Raadt likes the compiler and language that is used in Plan 9. Can't use it due to license problems, though.
You mean Alef? I don't think there are licensing problems with the language, and writing a compiler for it wouldn't be hard. I'm not convinced, though, that Alef is a good systems programming language.
But safer systems programming languages are a dime a dozen, people just have to use them.
Having run a linux system for a while and having my graphics card not 'just work' with RH's default version of X, my experience is that the stuff that I want to use 'just works' with the Mac and is less likely to work with RH. That's not a complete story, but it is tell tale.
Of course, Apple's graphics cards work with Apple's operating system--they ship together. Duh. When you buy a Linux machine from a Linux vendor, the graphics card also "just works".
It is ironic that people, on the one hand, fool themselves into thinking that these things don't happen to them, and on the other hand, have to go off bug hunting for days to find "baffling bugs". How much more productively could that development time have been spent?
Face it, memory corruption bugs, off-by-one-errors, and all that, happen to even the most experienced and careful programmers. The way to deal with them is to use programming languages that detect them reliably. In different words, we need to retire C or fix C.
And, no, "retiring C" doesn't mean switching to Java or C#. Instead, it means switching to a systems programming language that has error checking by default but still gives you all the low-level features you need when you need them. There have been a number of such languages over the years, but, unfortunately, they were all killed by C, not because C was better, but because C shipped with UNIX.
A lot of hardware also "just works" with Linux and BSD. In fact, I suspect a lot more hardware "just works" with Linux than with Macintosh because Linux includes so many drivers out of the box.
The reason for why hardware "just works" on all those non-Windows platfoms is simple: if OS vendors don't ship drivers with the hardware, you have to ship drivers with the OS.
Note that a lot of "driver CDs" contain a lot more than drivers: they contain documentation, setup utilities, etc. So, built-in support, whether on Macintosh or Linux or BSD, is often not as good as what you get from vendors. (OTOH, vendor CDs often install lots of garbage in addition to what you need.)
In the long run, we need more standard hardware interfaces, so that the low-level suff works for all hardware out of the box, but we also need to get vendors to support non-Windows platforms more.
I love Debian, and I think Debian's package system beats the other Linux systems, Windows, and Macintosh hands down for software installs and maintenance.
But you are dealing with an organization with lots of people who are used to doing things one way, and it will take them time to learn. If you want to convert them over to Linux (and there are lots of good reasons for doing so, including cost and security), pick a distro with a feel as close to Windows as possible. I think (for better or for worse) SuSE meets that goal. RedHat is probably also pretty good in that regard. Both also have commercial support and companies behind them, which makes management happy (even if you don't actually need it).
Change organizations gradually, otherwise you will have a revolution on your hands.
It's good to see that even Gartner believes that Linux and Windows will be comparable in 2008. But they are probably greatly underestimating the number of machines that run Linux as a server OS: most Linux installations aren't "shipped" and are hard to count. I suspect there are already more actual Linux server machines than there are Windows machines.
Because it's not a manufacturing industry. Building a car or a suit is a repetitive process that can be aided with robots.
Even if that were true, what difference does that make? If the job can be done more cheaply elsewhere, it makes sense to do it elsewhere. That's the premise of US trade policy, and there is no reason to make an exception for IT work.
But the distinction you are trying to make isn't valid anyway. Car manufacturing is mostly automated, even overseas, so jobs are highly skilled and require experience. And there is lots of manual, custom work outsourced already: custom tailoring and dental prostheses (crowns, etc.) are two examples that are frequently outsourced to China.
But outsourcing sends a signal that your job is not at all secure,
Of course, VB development jobs or MS system management jobs aren't secure. Why should they be? They require less training to perform adequately than many other jobs. As a result, workers in those jobs are easily replaced and those jobs are not secure.
The industry becomes de-skilled and you end up with no industry at all.
The IT industry became "de-skilled" years ago. And not by accident: the whole point of easy-to-use systems (you know, what companies like Microsoft, IBM, and Apple are trying to sell you) is that they don't require a lot of skill. And that trend is going to continue: billions of dollars are being invested into developing software that makes "database administrators" and "network administrators" obsolete and makes it easy for end-users to solve their own programming problems.
The only skilled jobs in IT that will remain secure will be people that come up with genuinely new algorithms and techniques (probably less than 1% of all IT jobs). And those people get their jobs in the countries of their choosing.
As the IT industry comprises up to 15% of an advanced economy, you are effectively emasculating that economy. I worry about the long term effects...
I still don't see any reason why you would think that these 15% of the economy are any more important than other 15% of the economy that we have outsourced previously.
If anything, I think IT jobs are a better candidate for outsourcing because most of them will disappear pretty soon anyway because of improvements in technology.
To get the designers, you would also need hardware as well designed as Apple hardware (read: designer hardware),
There is lots of very high-quality PC hardware out there. On the other hand, Macs are built mostly from standard PC components these days anyway (other than the processor).
you need to completely remove the need to go to the command line, you need to simplify the interface.
There is no more and no less need to "go to the command line" on a modern Linux installation as there is on an OS X installation.
But most importantly, X needs proper colour matching support. Designers need to work with ICC profiles. Otherwise matching colours properly is not possible!!
There are several color management systems for Linux and X11 (Xcms was shipped in 1991 and goes back even further). However, there just hasn't been much demand for it so far. Once more of the applications move to Linux and X11, those systems will get more use.
Yes, it makes sense to represent window layering and/or focus also using color. For example, you may want to reduce the saturation of content that isn't in focus.
Another thing that has been done is to blur window content that is layered on top of one another differently: the current layer is sharp and other layers are increasingly blurred. Some video games already use that technique.
I believe this extension makes it easier to experiment with such visual cues, although eventually, it may be useful to add specific primitives to it (they would enable hardware acceleration).
At the meeting, Hira described some of the adverse effects offshoring is having on engineers and other high-tech workers in the United States.
Of course, outsourcing has "adverse effects" on US high-tech workers; we don't need a $2m study to determine that. But if people in India can provide IT services more efficiently than us, they should provide IT services. And that's not something India forced upon us, it's something we have pressed the rest of the world to accept for several decades now.
And it's not like it's anything new: textile workers, steel workers, many parts of the service sector, manufacturing, assembly jobs, etc. have all moved overseas. Why is IT supposed to be special? Slapping together a VisualBasic app or debugging a network requires no more skill than assembling a car or making a suit.
X11 has had translucency for a long time--as part of its OpenGL support. So, if you needed translucency for actual work (visualizations, etc.) it was there.
This extension gives you translucency for eye candy and desktop apps. The reason that took so long is because (1) there didn't use to be much demand for it and (2) normal desktop machines didn't quite have the horsepower for it. Until there was demand and until machines got fast enough, there wasn't much reason for anybody to make the effort to put this in.
Even if P==NP, that doesn't automatically make all NP-complete problems "instantaneously" solvable. Overly exhuberant theorists referred to problems in P as "tractable", but just because they are called "tractable" doesn't make them so. Conversely, many problems in NP are so "tractable" already as to be useless for cryptography.
But more importantly, there is not a shred of evidence that P==NP, so talking about what terrorists would do if P==NP makes about as much sense as speculating about what terrorists would do if they had teleportation or Voodoo dolls.
A friend told me that the embarrassing thing was that the Chinese paper was REJECTED from the conference. They presented their results at the rump session. Other non-Asian researchers with hash collisions got papers in the conference
I don't know the particular paper in question, but the paper may have been rejected because it contained errors; even if a paper claims to show something extraordinary, if it contains errors, it will get rejected.
Even if the research itself was correct, the may well have been rejected for a reason indirectly related to having been written by Chinese authors: the presentation may have been unacceptably poor.
Like it or not, when the official language for a conference or journal is English, papers must be written in clear, correct, readable English and follow the academic standards of the English-speaking world.
The problem is probably not fixable at the level of toolkits: their APIs weren't designed with that kind of usage in mind and KDE and Gnome application programs seem to assume local connections as well (e.g., in their redraw logic).
In fact, one of the reasons for the existence of the low-level parts of Gtk+ seems to be to pretend that the complexities that writing high performance client-server GUI apps entails don't exist (of course, pretending that doesn't make them go away).
What we really need is a server extension or tool that lets you simulate running applications on a slow, long-latency line. Then, application programmers can see the effects of their design choices.
it should be secure out of the box
on
Hardening Apache
·
· Score: 1
The following should be secure even for the most inexperienced user:
Installing Apache
Installing PHP
Serving HTML files from the default Apache tree and/or ~/public_html
Writing and serving PHP scripts that access the file system and databases with default permissions
If Apache and PHP can't fulfill those operations securely out of the box, then there is something wrong with either the design or implementation of Apache and PHP, not the experience level of the user.
In different words, the default should be secure, and users should have to go through extra steps to make it not secure.
MPEG is also patented.
Of course, the MPEG licensing association may not have had much interest in going after open source because there is little money in it. Microsoft may go after open source just in order to hurt open source.
But, ultimately, the problem is patented codecs in general, not which particular patented codec gets put into hardware.
What are these people trying to sell? The connectivity between a visualization tool and a database, or a visualization tool? It seems like they are breaking new ground in neither area: there are well-established spreadsheet, visualization, graphing, and statistical analysis tools, with more ways of interacting with and visualizing your data than you could ever want. And all of those existing tools can use database data, either because they have database functions built-in, or because you can export/import data.
Maybe these people are doing a better job on the user interface or the software engineering, but in terms of technology, I see nothing new there.
There is PHPMyEdit and its derivatives. It is nowhere near as comfortable as some of the Windows GUI apps, but it covers some of the same ground: it makes it easy to put together simple database apps quickly.
Slashdot Mirror
Yes, if you use C++ with a decent class library and good programmers, you get good runtime safety. The problem with C++ is that if you have a large project with lots of ex-C programmers, they sneak in unsafe code everywhere and usually don't even understand that they are doing so.
Nevertheless, it would probably be a big step forward if Linux and BSD allowed C++ code in the kernel.
Do we know for certain that Microsoft isn't also claiming rights to PRA? After all, their disclosure of intellectual property interests explicitly cites PRA.
Same problem: C is a language that makes it difficult to write correct code, for numerous reasons.
A systems programming language with error checking needs to handle both automatic storage management and array bounds checking (plus a few other compile-time and runtime tests that are missing from C). Users should also be able to turn off either/both selectively and explicitly.
There are debugging tools out there which reliably find these bugs in C/C++ and FORTRAN.
No, they don't find them "reliably", they only find them if you happen to have a test case that triggers the bug and you run the software under valgrind or purify when you execute the test case. For security problems arising from buffer overflows, the probably is usually that developers don't even think of the case.
Tools such as these help to find problems, while avoiding the inefficiency of array bounds checking on each access.
The "inefficiency" of array bounds checking is a few percent in real code, hardly a big cost. But it's wrong to look at that cost by itself anyway--the question is: if you don't have array bounds checks in the compiler, what are you going to do instead? And pretty much everything you are going to do instead is going to be much more costly. Using languages in which unsafe array access are the default is penny wise and pound foolish.
And in really performance critical code, you can selectively turn it off in most languages.
The C dialect in Plan 9 is not very different from ANSI C; it doesn't address safety or security issues. Alef, on the other hand, looks pretty similar to C, but I believe is considerably safer than C.
As for not using C, I've read that Theo de Raadt likes the compiler and language that is used in Plan 9. Can't use it due to license problems, though.
You mean Alef? I don't think there are licensing problems with the language, and writing a compiler for it wouldn't be hard. I'm not convinced, though, that Alef is a good systems programming language.
But safer systems programming languages are a dime a dozen, people just have to use them.
Having run a linux system for a while and having my graphics card not 'just work' with RH's default version of X, my experience is that the stuff that I want to use 'just works' with the Mac and is less likely to work with RH. That's not a complete story, but it is tell tale.
Of course, Apple's graphics cards work with Apple's operating system--they ship together. Duh. When you buy a Linux machine from a Linux vendor, the graphics card also "just works".
It is ironic that people, on the one hand, fool themselves into thinking that these things don't happen to them, and on the other hand, have to go off bug hunting for days to find "baffling bugs". How much more productively could that development time have been spent?
Face it, memory corruption bugs, off-by-one-errors, and all that, happen to even the most experienced and careful programmers. The way to deal with them is to use programming languages that detect them reliably. In different words, we need to retire C or fix C.
And, no, "retiring C" doesn't mean switching to Java or C#. Instead, it means switching to a systems programming language that has error checking by default but still gives you all the low-level features you need when you need them. There have been a number of such languages over the years, but, unfortunately, they were all killed by C, not because C was better, but because C shipped with UNIX.
A lot of hardware also "just works" with Linux and BSD. In fact, I suspect a lot more hardware "just works" with Linux than with Macintosh because Linux includes so many drivers out of the box.
The reason for why hardware "just works" on all those non-Windows platfoms is simple: if OS vendors don't ship drivers with the hardware, you have to ship drivers with the OS.
Note that a lot of "driver CDs" contain a lot more than drivers: they contain documentation, setup utilities, etc. So, built-in support, whether on Macintosh or Linux or BSD, is often not as good as what you get from vendors. (OTOH, vendor CDs often install lots of garbage in addition to what you need.)
In the long run, we need more standard hardware interfaces, so that the low-level suff works for all hardware out of the box, but we also need to get vendors to support non-Windows platforms more.
Hmm what? MSFT has been pretty honest about their past designs and it's security flaws as of late.
That amounts to saying "yes, it sucks, but we know you don't have a choice but to buy it anyway". That's supposed to make people feel good?
I love Debian, and I think Debian's package system beats the other Linux systems, Windows, and Macintosh hands down for software installs and maintenance.
But you are dealing with an organization with lots of people who are used to doing things one way, and it will take them time to learn. If you want to convert them over to Linux (and there are lots of good reasons for doing so, including cost and security), pick a distro with a feel as close to Windows as possible. I think (for better or for worse) SuSE meets that goal. RedHat is probably also pretty good in that regard. Both also have commercial support and companies behind them, which makes management happy (even if you don't actually need it).
Change organizations gradually, otherwise you will have a revolution on your hands.
It's good to see that even Gartner believes that Linux and Windows will be comparable in 2008. But they are probably greatly underestimating the number of machines that run Linux as a server OS: most Linux installations aren't "shipped" and are hard to count. I suspect there are already more actual Linux server machines than there are Windows machines.
Because it's not a manufacturing industry. Building a car or a suit is a repetitive process that can be aided with robots.
Even if that were true, what difference does that make? If the job can be done more cheaply elsewhere, it makes sense to do it elsewhere. That's the premise of US trade policy, and there is no reason to make an exception for IT work.
But the distinction you are trying to make isn't valid anyway. Car manufacturing is mostly automated, even overseas, so jobs are highly skilled and require experience. And there is lots of manual, custom work outsourced already: custom tailoring and dental prostheses (crowns, etc.) are two examples that are frequently outsourced to China.
But outsourcing sends a signal that your job is not at all secure,
Of course, VB development jobs or MS system management jobs aren't secure. Why should they be? They require less training to perform adequately than many other jobs. As a result, workers in those jobs are easily replaced and those jobs are not secure.
The industry becomes de-skilled and you end up with no industry at all.
The IT industry became "de-skilled" years ago. And not by accident: the whole point of easy-to-use systems (you know, what companies like Microsoft, IBM, and Apple are trying to sell you) is that they don't require a lot of skill. And that trend is going to continue: billions of dollars are being invested into developing software that makes "database administrators" and "network administrators" obsolete and makes it easy for end-users to solve their own programming problems.
The only skilled jobs in IT that will remain secure will be people that come up with genuinely new algorithms and techniques (probably less than 1% of all IT jobs). And those people get their jobs in the countries of their choosing.
As the IT industry comprises up to 15% of an advanced economy, you are effectively emasculating that economy. I worry about the long term effects...
I still don't see any reason why you would think that these 15% of the economy are any more important than other 15% of the economy that we have outsourced previously.
If anything, I think IT jobs are a better candidate for outsourcing because most of them will disappear pretty soon anyway because of improvements in technology.
To get the designers, you would also need hardware as well designed as Apple hardware (read: designer hardware),
There is lots of very high-quality PC hardware out there. On the other hand, Macs are built mostly from standard PC components these days anyway (other than the processor).
you need to completely remove the need to go to the command line, you need to simplify the interface.
There is no more and no less need to "go to the command line" on a modern Linux installation as there is on an OS X installation.
But most importantly, X needs proper colour matching support. Designers need to work with ICC profiles. Otherwise matching colours properly is not possible!!
There are several color management systems for Linux and X11 (Xcms was shipped in 1991 and goes back even further). However, there just hasn't been much demand for it so far. Once more of the applications move to Linux and X11, those systems will get more use.
Yes, it makes sense to represent window layering and/or focus also using color. For example, you may want to reduce the saturation of content that isn't in focus.
Another thing that has been done is to blur window content that is layered on top of one another differently: the current layer is sharp and other layers are increasingly blurred. Some video games already use that technique.
I believe this extension makes it easier to experiment with such visual cues, although eventually, it may be useful to add specific primitives to it (they would enable hardware acceleration).
At the meeting, Hira described some of the adverse effects offshoring is having on engineers and other high-tech workers in the United States.
Of course, outsourcing has "adverse effects" on US high-tech workers; we don't need a $2m study to determine that. But if people in India can provide IT services more efficiently than us, they should provide IT services. And that's not something India forced upon us, it's something we have pressed the rest of the world to accept for several decades now.
And it's not like it's anything new: textile workers, steel workers, many parts of the service sector, manufacturing, assembly jobs, etc. have all moved overseas. Why is IT supposed to be special? Slapping together a VisualBasic app or debugging a network requires no more skill than assembling a car or making a suit.
X11 has had translucency for a long time--as part of its OpenGL support. So, if you needed translucency for actual work (visualizations, etc.) it was there.
This extension gives you translucency for eye candy and desktop apps. The reason that took so long is because (1) there didn't use to be much demand for it and (2) normal desktop machines didn't quite have the horsepower for it. Until there was demand and until machines got fast enough, there wasn't much reason for anybody to make the effort to put this in.
Even if P==NP, that doesn't automatically make all NP-complete problems "instantaneously" solvable. Overly exhuberant theorists referred to problems in P as "tractable", but just because they are called "tractable" doesn't make them so. Conversely, many problems in NP are so "tractable" already as to be useless for cryptography.
But more importantly, there is not a shred of evidence that P==NP, so talking about what terrorists would do if P==NP makes about as much sense as speculating about what terrorists would do if they had teleportation or Voodoo dolls.
A friend told me that the embarrassing thing was that the Chinese paper was REJECTED from the conference. They presented their results at the rump session. Other non-Asian researchers with hash collisions got papers in the conference
I don't know the particular paper in question, but the paper may have been rejected because it contained errors; even if a paper claims to show something extraordinary, if it contains errors, it will get rejected.
Even if the research itself was correct, the may well have been rejected for a reason indirectly related to having been written by Chinese authors: the presentation may have been unacceptably poor.
Like it or not, when the official language for a conference or journal is English, papers must be written in clear, correct, readable English and follow the academic standards of the English-speaking world.
The problem is probably not fixable at the level of toolkits: their APIs weren't designed with that kind of usage in mind and KDE and Gnome application programs seem to assume local connections as well (e.g., in their redraw logic).
In fact, one of the reasons for the existence of the low-level parts of Gtk+ seems to be to pretend that the complexities that writing high performance client-server GUI apps entails don't exist (of course, pretending that doesn't make them go away).
What we really need is a server extension or tool that lets you simulate running applications on a slow, long-latency line. Then, application programmers can see the effects of their design choices.
If Apache and PHP can't fulfill those operations securely out of the box, then there is something wrong with either the design or implementation of Apache and PHP, not the experience level of the user.
In different words, the default should be secure, and users should have to go through extra steps to make it not secure.
MPEG is also patented. Of course, the MPEG licensing association may not have had much interest in going after open source because there is little money in it. Microsoft may go after open source just in order to hurt open source. But, ultimately, the problem is patented codecs in general, not which particular patented codec gets put into hardware.
What are these people trying to sell? The connectivity between a visualization tool and a database, or a visualization tool? It seems like they are breaking new ground in neither area: there are well-established spreadsheet, visualization, graphing, and statistical analysis tools, with more ways of interacting with and visualizing your data than you could ever want. And all of those existing tools can use database data, either because they have database functions built-in, or because you can export/import data.
Maybe these people are doing a better job on the user interface or the software engineering, but in terms of technology, I see nothing new there.
There is PHPMyEdit and its derivatives. It is nowhere near as comfortable as some of the Windows GUI apps, but it covers some of the same ground: it makes it easy to put together simple database apps quickly.