You're right that Nvidia has put a lot of effort into making their binary-only drivers work with custom kernels. But remember that all the complex installation would be unnecessary if the drivers were free software in the first place, and could be included with free OSes like Red Hat.
In fact, Nvidia keep the specs of their cards secret, so not only will they not provide free drivers, they stop anybody else writing them.
So by all means praise Nvidia for making the best of a bad job with their proprietary drivers, but to call them particularly 'dedicated' to Linux or the other common Unixes (are there Nvidia drivers for the BSDs?) is unfair to the many other hardware vendors who have released open-source drivers or hardware specifications.
Today this meaning is
commonly extended to include the killing of any large proportion of a group. Sixty-six percent of the Usage Panel accepts this extension...
But I don't see that this Usage Panel is necessarily the final arbiter, unless it is drawn from people who are likely to be knowledgeable about words. If it is just a random cross-section of the English-speaking public, then there would be no point in having dictionaries.
Words are determined by usage, yes, but when there are two different usages and one is almost the opposite of the other I think it is reasonable to argue in favour of the 'correct' one, which is often the older meaning.
Philip and Alex covers the same topic (building a website with a database backend). It has a large number of pages which are not at all useful because they are colour photographs of Alex or of various parts of North America. And others are random sidetracks or rants against the stupidity of web designers or 'junkware'. But they are not wasted pages because they are entertaining to read or look at.
To avoid are books with a large number of pages which are neither useful nor entertaining - like most of the 500-page monsters you see in bookshops. ('Teach Yourself To Be A Dummy In 24 Hours' - Philip.)
Yes, words change their meaning over time. The word 'literally' now has acquired the meaning 'figuratively', as in: He literally flew out of the window. Indeed, this may now be the most common usage. But wouldn't you agree that it is wrong?
Somehow it seems most annoying when words acquire a new meaning which is the opposite of their original meaning. 'Literally' is one example, 'semantic' another (one Slashdot editor wrote a while back, 'this was just a semantic change, with no effect on the meaning'). I feel that the use of 'decimate' to mean reduce by 90%, rather than by 10%, is also a kind of stupid-opposite-meaning so I wanted to correct it.
'Decimate' means to reduce by one-tenth. It originates from the punishment for mutiny given to a whole Roman legion: killing every tenth man. So if you think that Windows installations are 10% less than they would have been if Linux didn't exist, then Linux has already decimated Windows, at least on the server.
The Mozilla roadmap is the first time I've seen 'performant' used by a native English speaker (or at least someone who doesn't have other obvious signs of using English as a second language). Until then I had heard it only from French speakers (as you say, it is a word in that language) or German speakers who were perhaps overgeneralizing from 'performance'. And we know that programmers or marketing types often say 'performance' when they mean 'speed'.
Back-forming 'performant' from 'performance' sounds reasonable enough, but there's no reason to use this new word when 'fast' is already available.
It's interesting how the source of America's energy is moving further west. At present a large part of oil consumption is imported from Arab countries. Now, apparently Turkey will replace that. The logical next step in a few years is to generate oil from Grease.
No but RPM and similar packaging systems do have compile-script stuff. That's what a source RPM is. It includes a spec file which says how to get the source, patch it, configure it, compile it, install it and finally put together the installed files into a binary RPM.
The RPM spec file format should be extended so it covers all of the features used by Gentoo's build scripts. (I think it probably handles most of them already.) Then Gentoo really could move to RPM for package handling - all built from source, naturally.
You just need to change the & character to & in your attributes. This is because HTML entities such as é are allowed in attribute values just as in normal text. So when you want a plain ampersand you have to escape it.
BTW, some web application libraries (such as Perl's CGI.pm) are moving to a newer style of URL that uses semicolons rather than ampersand to separate the parameters.
The election process you describe is called single transferrable vote (STV) or instant runoff. But if they were using that system, why the weird presentation of results? Normally in an STV election you just give the results of voting 'rounds':
Round 0: candidate A 45 votes, B 40 votes, C 15 votes. Eliminate C.
Round 1: candidate A 55 votes, B 45 votes. A wins.
I've never seen this weird tabular format with simulated one-on-one contests between candidates. Does anyone pay attention to that data?
What's even more interesting is that the next version of Solaris - Solaris 11 or 'Dingo' as it is codenamed - will be based on FreeDOS. Sun realizes that very often DOS based applications can get good performance, since they can run much closer to the hardware and make their own decisions about scheduling and the like (there is no preemption of processes in classic DOS). Furthermore, the DOS command shell and the Basic language (implemented in FreeDOS as bwbasic.exe) provide a powerful scripting environment for impactful, mission-critical applications.
The plan is apparently to recompile FreeDOS for SPARC and extend the SPARC architecture to support DOS's powerful and flexible memory model. Then applications such as Oracle and SAP will be ported to the new architecture. Of course it will all be compiled from source using debug.exe (which contains a built-in assembler) to ensure optimum performance.
I don't run Solaris 11 for everyday work but I had the opportunity to play with an early technology preview on some preproduction hardware (essentially a next-generation E10k running a modified ISA bus clocked at 100MHz and supporting asynchronous point-to-point transfers using Intel's i8529 controller) and it does seem to combine the best points of both Solaris and FreeDOS. WordStar runs beautifully - Sun is set to conquer the enterprise market soon after this thing launches.
But there are benchmarks showing the effects of different gcc flags and optimizations. The gcc people are pretty intelligent, they wouldn't bother to implement processor-specific optimizations if there weren't performance improvements from them.
Even if compiling for i686 rather than i386 only gave a one per cent performance improvement, nonetheless one per cent across the board is not to be sneezed at. For some particular programs like gzip you can often do a lot better.
The question is not 'why compile with the most optimizations possible' but rather 'why not, since we have a compiler that can handle it'.
I'm looking forward to the day when apt or similar tools can download source packages, compile and install them, after fetching all the dependencies automatically of course. That would combine most of the advantages of building from source with the easier management of RPM/dpkg-based systems.
char * as a common denominator among different string libraries leaves a lot to be desired, however; most importantly it breaks when strings contain NUL characters. A seamless conversion to and from std::string would be better.
The FSF has a policy of not linking to websites that promote proprietary software. Hence they cannot link to IBM's page because it might promote WebSphere, or DB2, or whatever.
Which kinda illustrates how odd it is that these companies are publicly supporting the FSF, given that organization's opposition to proprietary software.
There is a simple way to avoid freeing something twice: set the pointer to NULL after it has been freed.
Er, 'the' pointer? If there were guaranteed to be only one pointer to a chunk of memory then life would indeed be easy. You could use C++'s auto_ptr to make sure of that. Double-free bugs often come about when there could be more than one pointer to the same bit of memory and you're not sure which one 'owns' it.
Of course in normal coding you would set a pointer to null after free()ing the memory it references, unless the pointer is part of a structure which itself is soon to be destroyed.
No I meant that C++ doesn't have a 'safe' string class, responding to the original post. But it is provided by the standard library, so that's okay. The point being that it's not required for safe strings to be built into the language itself.
Good point about the other languages though. Although in the case of Haskell and ML it becomes a bit moot what is 'built in' and what isn't, since once you have algebraic data types, creating lists and strings is trivial.
PTypes looks interesting, but I think the world has enough C++ foundation libraries. There are at least a dozen on Freshmeat. But what about third-party libraries? Should they use the string class from PTypes, or from some other foundation library?
The 'S' in 'STL' is the most important letter.
(Actually in my original post I was suggesting a standard string library for C. A migration en masse to C++ would also solve the problem, but is even less likely. And it wouldn't be that great if all the C++ programs used different libraries for something so basic as strings.)
Yes, I specifically mentioned SQL stuffing vulnerabilities in my above post. The correct way to use SQL is not with string interpolation but using placeholders - often, these are 'variables' which begin with a colon, and are replaced with the value desired by the database access library.
It's not the SQL language which is at fault, it's the library or program which relies on gluing together strings to make an SQL query. If you wrote a program to generate C code by gluing together strings, compile it and then execute it, it would have similar vulnerabilities unless you wrote it carefully.
'Taint checking in the language' is impossible: the SQL language knows nothing about the way in which the query string might have been put together. It's just a string of code. After all, SQL has no provision for reading user input or getting data from a web form, so how could it do taint checking?
Modern C++ textbooks also tend to introduce pointers fairly late on. In fact the main reason you'll come across pointers when learning C++ and its standard library is for storing a container of pointers rather than a container of objects.
I disagree with you about getting more contributors if code is written in a higher-level language; it has to be a popular language. Far more people know C than know Haskell or Mercury or any other very-high-level language. Perl, despite having many faults as a language, is a good compromise for free software development because it is both fairly high-level and very popular, and has a good collection of libraries.
Tainting support ala Perl would be another great thing to have in a widely available library. Lazy programmers might still cast 'struct Poisonedstringfullofshellcode' to 'struct String' but at least it wouldn't happen by accident.
The reason Perl needs taint mode at all is because it does so many things in a blatantly insecure way. For example Perl's system() with a single string will pass that string to the shell, so if you do
system("grep $pattern $in >$out");
then people can smuggle things into $pattern or the other variables. The problem is caused by string interpolation; it's the same attack as 'SQL smuggling' in websites that construct their SQL code by interpolating strings. Now, in Perl there is a multi-argument form of system() which passes the strings directly to the exec() system call, so you can say
system('grep', $pattern, $in);
and you're immune to any smuggling attacks. But how do you specify the output redirection to the file $out? You can't, at least not without several lines of code. This is the trouble; the insecure way of doing things has become so common and people are so used to it, that there is no effort to provide a more secure but equally convenient way to accomplish the same task. At least, not as part of the standard Perl distribution, and not promoted in common Perl textbooks. Instead we get the workaround of 'taint mode' so you can check for the characters which cause the magic behaviour.
(The same thing explains why many Perl scripts break when given pathnames containing spaces - despite the fact that the space character has always been legal in Unix filenames and is common on other platforms. The scripts are relying on string interpolation instead of expressing what they want in real data structures.)
I'm pleased to say that in recent Perl versions a similar security hole has been fixed: instead of saying
open FH, $file;
which would let the user give a filename beginning with '>' and trick the program into writing somewhere rather than reading, you can now say
open FH, '<', $file;
which is safe. Again the problem was caused by adding 'cool features' based on looking inside strings. The file mode '<' should not be fetched from the filename string, any more than an I/O redirection '<' should be fetched from the string passed to system(). Putting them as separate arguments avoids the security hole and is no less convenient for the programmer.
In most compiled languages, a taint mode is not necessary because the language and libraries don't do 'useful' things based on magic characters in strings you happen to pass. Tell C to open() a file called '>foo' and it will try to do just that. This is much more sensible IMHO.
The problem with C or C++ is that no matter how much library code you add to them, they don't provide fault isolation. That is, I can do everything right in my code, but some other module can still screw up my data structures through a stray pointer.
Very true. One way to provide this isolation would be to run each library as a separate process or in its own address space, like how in classic Unix the kernel was a kind of library which happened to have restricted entry points and to switch the CPU to a different privilege level when entered. But I don't know if this would be practical on modern hardware (a thousand processes each linked with a thousand libraries demanding hardware isolation from each other).
Another way to get the same isolation at run time is to use a virtual machine where pointer accesses are either forbidden or strictly controlled. Of course, this is the Java or.net approach.
Or there could be a way to check statically (ie, at compile time) that a given library cannot scribble over your code. But I think this is too difficult to do without seriously restricting the library author's range of coding styles.
You're right that 'vector' and other STL classes don't guarantee safety, but they are surely a big step up from raw C arrays or NUL-terminated strings. Many STL implementations do have 'safe' or 'debug' modes; it's a pity this mode is not the default.
Slashdot Mirror
You're right that Nvidia has put a lot of effort into making their binary-only drivers work with custom kernels. But remember that all the complex installation would be unnecessary if the drivers were free software in the first place, and could be included with free OSes like Red Hat.
In fact, Nvidia keep the specs of their cards secret, so not only will they not provide free drivers, they stop anybody else writing them.
So by all means praise Nvidia for making the best of a bad job with their proprietary drivers, but to call them particularly 'dedicated' to Linux or the other common Unixes (are there Nvidia drivers for the BSDs?) is unfair to the many other hardware vendors who have released open-source drivers or hardware specifications.
The reference given above for 'decimate' says:
But I don't see that this Usage Panel is necessarily the final arbiter, unless it is drawn from people who are likely to be knowledgeable about words. If it is just a random cross-section of the English-speaking public, then there would be no point in having dictionaries.
Words are determined by usage, yes, but when there are two different usages and one is almost the opposite of the other I think it is reasonable to argue in favour of the 'correct' one, which is often the older meaning.
Philip and Alex covers the same topic (building a website with a database backend). It has a large number of pages which are not at all useful because they are colour photographs of Alex or of various parts of North America. And others are random sidetracks or rants against the stupidity of web designers or 'junkware'. But they are not wasted pages because they are entertaining to read or look at.
To avoid are books with a large number of pages which are neither useful nor entertaining - like most of the 500-page monsters you see in bookshops. ('Teach Yourself To Be A Dummy In 24 Hours' - Philip.)
Yes, words change their meaning over time. The word 'literally' now has acquired the meaning 'figuratively', as in: He literally flew out of the window. Indeed, this may now be the most common usage. But wouldn't you agree that it is wrong?
Somehow it seems most annoying when words acquire a new meaning which is the opposite of their original meaning. 'Literally' is one example, 'semantic' another (one Slashdot editor wrote a while back, 'this was just a semantic change, with no effect on the meaning'). I feel that the use of 'decimate' to mean reduce by 90%, rather than by 10%, is also a kind of stupid-opposite-meaning so I wanted to correct it.
'Decimate' means to reduce by one-tenth. It originates from the punishment for mutiny given to a whole Roman legion: killing every tenth man. So if you think that Windows installations are 10% less than they would have been if Linux didn't exist, then Linux has already decimated Windows, at least on the server.
:-).
It's the remaining 90% that is at stake
The Mozilla roadmap is the first time I've seen 'performant' used by a native English speaker (or at least someone who doesn't have other obvious signs of using English as a second language). Until then I had heard it only from French speakers (as you say, it is a word in that language) or German speakers who were perhaps overgeneralizing from 'performance'. And we know that programmers or marketing types often say 'performance' when they mean 'speed'.
Back-forming 'performant' from 'performance' sounds reasonable enough, but there's no reason to use this new word when 'fast' is already available.
I like to think that Slashdot is subverting the April Fool's Day convention.
It's interesting how the source of America's energy is moving further west. At present a large part of oil consumption is imported from Arab countries. Now, apparently Turkey will replace that. The logical next step in a few years is to generate oil from Grease.
No but RPM and similar packaging systems do have compile-script stuff. That's what a source RPM is. It includes a spec file which says how to get the source, patch it, configure it, compile it, install it and finally put together the installed files into a binary RPM.
The RPM spec file format should be extended so it covers all of the features used by Gentoo's build scripts. (I think it probably handles most of them already.) Then Gentoo really could move to RPM for package handling - all built from source, naturally.
You just need to change the & character to & in your attributes. This is because HTML entities such as é are allowed in attribute values just as in normal text. So when you want a plain ampersand you have to escape it.
BTW, some web application libraries (such as Perl's CGI.pm) are moving to a newer style of URL that uses semicolons rather than ampersand to separate the parameters.
Those two commands you give, will they make sure the dependencies are built from source also?
Is that method of selection equivalent to conventional STV or can it sometimes produce a different result?
The election process you describe is called single transferrable vote (STV) or instant runoff. But if they were using that system, why the weird presentation of results? Normally in an STV election you just give the results of voting 'rounds':
Round 0: candidate A 45 votes, B 40 votes, C 15 votes. Eliminate C.
Round 1: candidate A 55 votes, B 45 votes. A wins.
I've never seen this weird tabular format with simulated one-on-one contests between candidates. Does anyone pay attention to that data?
What's even more interesting is that the next version of Solaris - Solaris 11 or 'Dingo' as it is codenamed - will be based on FreeDOS. Sun realizes that very often DOS based applications can get good performance, since they can run much closer to the hardware and make their own decisions about scheduling and the like (there is no preemption of processes in classic DOS). Furthermore, the DOS command shell and the Basic language (implemented in FreeDOS as bwbasic.exe) provide a powerful scripting environment for impactful, mission-critical applications.
The plan is apparently to recompile FreeDOS for SPARC and extend the SPARC architecture to support DOS's powerful and flexible memory model. Then applications such as Oracle and SAP will be ported to the new architecture. Of course it will all be compiled from source using debug.exe (which contains a built-in assembler) to ensure optimum performance.
I don't run Solaris 11 for everyday work but I had the opportunity to play with an early technology preview on some preproduction hardware (essentially a next-generation E10k running a modified ISA bus clocked at 100MHz and supporting asynchronous point-to-point transfers using Intel's i8529 controller) and it does seem to combine the best points of both Solaris and FreeDOS. WordStar runs beautifully - Sun is set to conquer the enterprise market soon after this thing launches.
But there are benchmarks showing the effects of different gcc flags and optimizations. The gcc people are pretty intelligent, they wouldn't bother to implement processor-specific optimizations if there weren't performance improvements from them.
Even if compiling for i686 rather than i386 only gave a one per cent performance improvement, nonetheless one per cent across the board is not to be sneezed at. For some particular programs like gzip you can often do a lot better.
The question is not 'why compile with the most optimizations possible' but rather 'why not, since we have a compiler that can handle it'.
I'm looking forward to the day when apt or similar tools can download source packages, compile and install them, after fetching all the dependencies automatically of course. That would combine most of the advantages of building from source with the easier management of RPM/dpkg-based systems.
char * as a common denominator among different string libraries leaves a lot to be desired, however; most importantly it breaks when strings contain NUL characters. A seamless conversion to and from std::string would be better.
Er no, strcmp() will compare two strings lexicographically, whether or not they are the same length. For example
int main(void)
{
const char *a = "hello";
const char *b = "hello there";
printf("%d\n", strcmp(a, b));
}
This prints -1 as you'd expect (a comes before b). Change both strings to "hello" and it prints 0.
The FSF has a policy of not linking to websites that promote proprietary software. Hence they cannot link to IBM's page because it might promote WebSphere, or DB2, or whatever.
Which kinda illustrates how odd it is that these companies are publicly supporting the FSF, given that organization's opposition to proprietary software.
Er, 'the' pointer? If there were guaranteed to be only one pointer to a chunk of memory then life would indeed be easy. You could use C++'s auto_ptr to make sure of that. Double-free bugs often come about when there could be more than one pointer to the same bit of memory and you're not sure which one 'owns' it.
Of course in normal coding you would set a pointer to null after free()ing the memory it references, unless the pointer is part of a structure which itself is soon to be destroyed.
No I meant that C++ doesn't have a 'safe' string class, responding to the original post. But it is provided by the standard library, so that's okay. The point being that it's not required for safe strings to be built into the language itself.
Good point about the other languages though. Although in the case of Haskell and ML it becomes a bit moot what is 'built in' and what isn't, since once you have algebraic data types, creating lists and strings is trivial.
PTypes looks interesting, but I think the world has enough C++ foundation libraries. There are at least a dozen on Freshmeat. But what about third-party libraries? Should they use the string class from PTypes, or from some other foundation library?
The 'S' in 'STL' is the most important letter.
(Actually in my original post I was suggesting a standard string library for C. A migration en masse to C++ would also solve the problem, but is even less likely. And it wouldn't be that great if all the C++ programs used different libraries for something so basic as strings.)
Yes, I specifically mentioned SQL stuffing vulnerabilities in my above post. The correct way to use SQL is not with string interpolation but using placeholders - often, these are 'variables' which begin with a colon, and are replaced with the value desired by the database access library.
It's not the SQL language which is at fault, it's the library or program which relies on gluing together strings to make an SQL query. If you wrote a program to generate C code by gluing together strings, compile it and then execute it, it would have similar vulnerabilities unless you wrote it carefully.
'Taint checking in the language' is impossible: the SQL language knows nothing about the way in which the query string might have been put together. It's just a string of code. After all, SQL has no provision for reading user input or getting data from a web form, so how could it do taint checking?
Modern C++ textbooks also tend to introduce pointers fairly late on. In fact the main reason you'll come across pointers when learning C++ and its standard library is for storing a container of pointers rather than a container of objects.
I disagree with you about getting more contributors if code is written in a higher-level language; it has to be a popular language. Far more people know C than know Haskell or Mercury or any other very-high-level language. Perl, despite having many faults as a language, is a good compromise for free software development because it is both fairly high-level and very popular, and has a good collection of libraries.
The reason Perl needs taint mode at all is because it does so many things in a blatantly insecure way. For example Perl's system() with a single string will pass that string to the shell, so if you do
system("grep $pattern $in >$out");
then people can smuggle things into $pattern or the other variables. The problem is caused by string interpolation; it's the same attack as 'SQL smuggling' in websites that construct their SQL code by interpolating strings. Now, in Perl there is a multi-argument form of system() which passes the strings directly to the exec() system call, so you can say
system('grep', $pattern, $in);
and you're immune to any smuggling attacks. But how do you specify the output redirection to the file $out? You can't, at least not without several lines of code. This is the trouble; the insecure way of doing things has become so common and people are so used to it, that there is no effort to provide a more secure but equally convenient way to accomplish the same task. At least, not as part of the standard Perl distribution, and not promoted in common Perl textbooks. Instead we get the workaround of 'taint mode' so you can check for the characters which cause the magic behaviour.
(The same thing explains why many Perl scripts break when given pathnames containing spaces - despite the fact that the space character has always been legal in Unix filenames and is common on other platforms. The scripts are relying on string interpolation instead of expressing what they want in real data structures.)
I'm pleased to say that in recent Perl versions a similar security hole has been fixed: instead of saying
open FH, $file;
which would let the user give a filename beginning with '>' and trick the program into writing somewhere rather than reading, you can now say
open FH, '<', $file;
which is safe. Again the problem was caused by adding 'cool features' based on looking inside strings. The file mode '<' should not be fetched from the filename string, any more than an I/O redirection '<' should be fetched from the string passed to system(). Putting them as separate arguments avoids the security hole and is no less convenient for the programmer.
In most compiled languages, a taint mode is not necessary because the language and libraries don't do 'useful' things based on magic characters in strings you happen to pass. Tell C to open() a file called '>foo' and it will try to do just that. This is much more sensible IMHO.
Very true. One way to provide this isolation would be to run each library as a separate process or in its own address space, like how in classic Unix the kernel was a kind of library which happened to have restricted entry points and to switch the CPU to a different privilege level when entered. But I don't know if this would be practical on modern hardware (a thousand processes each linked with a thousand libraries demanding hardware isolation from each other).
Another way to get the same isolation at run time is to use a virtual machine where pointer accesses are either forbidden or strictly controlled. Of course, this is the Java or .net approach.
Or there could be a way to check statically (ie, at compile time) that a given library cannot scribble over your code. But I think this is too difficult to do without seriously restricting the library author's range of coding styles.
You're right that 'vector' and other STL classes don't guarantee safety, but they are surely a big step up from raw C arrays or NUL-terminated strings. Many STL implementations do have 'safe' or 'debug' modes; it's a pity this mode is not the default.