This is a startup we are talking about. A simpler solution is to just treat the file server as somewhat untrusted. Provide GPG/PGP/some encryption software to all employees and keep important files encrypted when on the server.
I would guess that it costs less to outsource this sort of work
That's true. It's mostly a tax and shareholder benefit (you don't have assets and depreciation (CAPEX) instead you have costs and service charges (OPEX)) but it's also true that since the outsourcing company probably works for several other companies they can share costs and normally come in cheaper.
This means that it's a simple calculation in theory. If the extra cost of doing on site administration properly, or at least better than the external company, is more than the value of the information (asset) that might be lost times the chance of it being lost (risk) then forget about it. There's a slight chance might save your company money, but you guarantee to lose it some money.
Simply put; in business, especially start ups; there's always risk. If you have a fire in your office your company is probably dead. Probably there's a key person in your team who, if he leaves, will stop the company working. List all the risks you can think of and handle those risks where you can get the best benefit for the least money. Do that in the cheapest way possible (maybe a contract change will reduce the risk of your administrator to a reasonable level). It is possible that there's some special data where that risk is the system administrator in which case you might be worth adding extra protection. For the rest just accept the risk and move forward.
In the end; you seem to be the responsible manager. You have to calculate the above things to your satisfaction and spend your money to make things work best taking into account all possibilities and not just this one. Since we don't have enough information about the information we can't really help you.
I don't see how licensing the code under the GPL is any sort of safety net for Dev Ltd in comparison to the BSD licence, given that it wouldn't prevent a potential competitor who might get hold of the code from offering that code under the exact same terms, but without the cost overhead of actually having to do the development work.
The trick is that you can use this for price differentiation. Some customers want full control and are willing to pay. Others want the code as cheap as possible and don't care. Give them a discount if they take GPL. That way you can be sure that they just make normal use of it.
Re:This isn't sensationalist, it's the truth
on
Leaving the GPL Behind
·
· Score: 3, Insightful
The GPL is obviously preferable to closed-source software in this case, but I'm not sure how it's preferable to the BSD/MIT ilk of licences.
This depends on circumstances. In most cases the majority of the entities working on the software are not competitors, however competitors also can use the software.
When you release BSD software, you get equal support to all the other people who cooperate with you. However, your competitors have a possibility to get a specific advantage. They can take your software, use it as you do, but add their own proprietary changes which they do not share.
This means that companies should not contribute to BSD projects without considerable care. E.g. if a feature is basic and your competitor already has it in their products you can contribute it because your competitor won't benefit. If a feature is advanced and product differentiating then you should never release it to a BSD project.
With a GPL project, there is another option. You contribute to the project. Any competitors which take that feature change their relationship with you. You and your former competitor cooperate in an open and legal way in one particular area (this is legal because it is directly to the benefit of the consumers / public etc.) whilst competing on others (service ; hardware ; other software bundled etc.).
In theory, this means that BSD software is better for short throw away projects where you will never work with anyone else whilst GPL is better for long term stable projects where cooperation will be most valuable. In practice, things which are planned short term very often become long term. This means it's normally better to use and release GPL software
There is one exception to this. If you are releasing a feature that you want everybody to use, including proprietary vendors, then you might find that the GNU All Permissive License is a good option. At least noticing its existence is quite ironic given the summary on this story.
It's just history and cooler heads are now prevailing.
I'm really not sure what you mean by that? The free software foundation has had a page recommending licenses other than the GPL for as long as I remember. You can't say "The proponents of GPL" without including the free software foundation. You can't say "like to tell people that the world only needs one open source license" about an organisation which since at least 2001 has been recommending the X11 license as a better alternative to the BSD license (check archive.org).
If the author wanted to merely mislead, he would have said something like "there are GPL proponents who will tell you that the world only needs one open source license". If he wanted to tell the truth, he would say something "a few irrelevant fanatics who have no real credibility even in the free software movement will tell you that the GPL is the only acceptable license for software" or, "I once met a guy in a bar who, after downing 10 pints and just before falling under the table said 'wouldn't it be really good if all software was under the GPL'. As it was, he lied.
"fabrication" is a nice word. Lie is better. The Free software foundation, the main proponent of the GPL, actively recommends many other licenses than the GPL and for them and most users there is little difference. It's when you see a lie like this in the headline that you know that someone has an anti FOSS agenda (admittedly, it's in the middle of the Yahoo article, but the person writing it knew which sentence would go at the top in Slashdot). I wonder if yahoo really isn't joining the dark side.
What I've found, however, is that in a commercial environment the GPL is a very important tool. It's the one of the few licenses which can be trusted to build a completely fair sharing system where many companies can come together and produce one set of code without the likelihood of the other companies cheating on them. It's definitely true that commercial entities make more software based on BSD/MIT licenses. However, the fact that you see more contributions to the base software on GPL systems is not an accident. It happens because the commercial entities can be happy that if their contribution is used against them, they will at least have the come back of being able to use changes.
I've seen (and posted about before) many examples where the use of a non copyleft license or a less effective copyleft license has lead to abandoned projects. The most classic being the failure of the ipsilon routing contributions to be pushed back into FreeBSD which died with the operating system. This happens because licenses such as Apache and BSD don't demand contributions, which means that when the lawyers are asked, they often recommend against contributing "for now" and the contributions actually never happen.
For this usage, the AGPLv3 is also a big advance and should IMHO probably be the license of choice for all projects which want to have efficient long term cooperation with commercial software producers going forward. Having said that, the most important thing is to work together with other people who have similar interestes. The F vs OSS debate is all very fine in theory, but in real life everybody has very much to cooperate over. That's seems to be the main reason why Free software foundation generally recommends that people contribute using the projects own license.
In OSS it code often gets abandoned for other reasons. This can be code that "just works". It's somewhat similar to various legacy applications that are running in dos boxes today because they do something very obscure and useful but which can't drive further commercial development.
Abandoned, unused, code loses value. However, abandoned, used code often becomes more valuable. The world changes to ensure it has the environment to keep it going. In this case the OSS model of leaving the code around is much better. When someone decides the code has become too valuable to be abandoned, then they can un-abandon it. If the code remains abandoned and is less and less used; it's hardly difficult to use project activity as a filtering criteria in searching.
When rewriting, the old code is crucial competition. In the OSS model, it's also a crucial set of information. It should be maintained until such time as the new code is clearly better in (almost) every way. The new code should be able to replace the old with little difficulty and only few limitations. If it can't do that, then likely it has failed to learn from the old and will actually be worse.
I'm sure there are exceptions, but what Joel is saying is that there should be a presumption for old code. I think that he's almost always right.
That's actually wrong and deliberately so. The Scottish system has "not guilty", "not-proven" and "guilty". Legally there is little difference, but by custom, not proven means "managed to get away with it" and is attached to specific social stigma. Not guilty means "everybody should treat this man as innocent". English tradition, including US tradition has specifically rejected the not-proven verdict.
Innocence or guilt is a matter of fact, not of proof.
I don't see the justification for modding the parent down. legally you are "innocent until proven guilty". However, that doesn't mean you didn't do it. If I saw you do it; even if you get cleared because two of your mates say you didn't do it, I can still say you are guilty. If you try to sue me, you have a completely different standard of proof. Even if someone sues you for the damage you did during your crime, they have a different standard. That's why when the police screwed up the prosecution of OJ by messing with the evidence it was perfectly right that he got let off on the criminal trial and lost at the civil trial. The jury couldn't reasonably give a guilty verdict if racist US were involved in prosecuting a black man and tampering with evidence, but you and I know that OJ was probably guilty as sin.
Innocent until proven guilty is a useful thing. If someone is found innocent by a court you should probably treat them as such unless you know different. That keeps the police working harder; it keeps the system cleaner and it means that when innocent people are charged the consequences of the mistake are minimised. However, if you do know different and you don't do work for the government your obligations are pretty limited.
I don't think the compiler has any way to be sure. The check against that in the i386 architecture is to make sure that the page at address 0 isn't mapped in to process / kernel memory. However, that mapping could be changed at run time, so the warning could be there or not during program run for the same code at compile time.
For me, an important downward turning point occurred when Microsoft violated Apple's UI guidelines, which stated that documents should always re-open with the insertion point positioned where it was
Damnit Sir; where may I subscribe to your journal? I never even noticed that. I had thought that it was just system stability which peaked in the 1970/1980s and of course the Web in the 1990s.. We're doomed.
What you and, it seems Negroponte himself, don't understand is that the OLPC project should have been completely doomed from the start. They had to do G1G1 because otherwise they would have been directly competing against normal PC/computer/software manufacturers who have patents and would kill them dead. It's surprising that this project did anything at all. That it managed to kick start the Netbook and effectively wipe out a huge proportion of Microsoft's profit is astounding. Negroponte seems a bit deluded to me; I think he completely screwed up the community aspect. However, I also think that most people would have completely failed at this project. Better to see the glass half full in my opinon. In the middle of the Sahara desert.
This code is only reasonably legitimate because Linux user processes normally do guarantee that null pointer de-references cause aborts.
Bullshit; What you mean is:
The reason this could be legitimate in the Linux Kernel is because they have a special environment where null pointer dereferences are guaranteed not to cause a crash. However, that means that they have to rely on the compiler behaving in a defined way which means that they are fundamentally responsible for checking all the optimisations etc. etc. which their code relies on.
In a Linux user process, the compiler behaviour would be fine because Linux user processes normally do guarantee that null pointer de-references cause aborts. The kernel code would be wrong because
Thinking about this, it seems more, it seems to be a needlessly hairy and careless thing to allow in kernel code. There's a perfectly legitimate way to do this in C (get the buffer, check it's not null, use it). That legitimate way could be optimised by the compiler to be just as fast as the code used. Why not just do it right in the first place. Then, when someone cuts and pastes into user code at some later point, there won't be an problems.
You can spin it any way you want but it is still not true. There are jokes about "undocumented features" but this isn't even that. It's a clearly documented feature if you look up the optimisation. It's not even incorrect according to the C standard. When you dereference the null pointer then you get "undefined behaviour" up to and including initiation of global nuclear war on computers with the appropriate peripherals (unfortunately I can't find the original Fortran quote I am abusing here). The fact that your compiler does different things during different compiles is perfectly correct and the least of your problems.
This code is only reasonably legitimate because Linux user processes normally do guarantee that null pointer de-references cause aborts.
It's not a compiler "bug" since it's clearly documented behaviour (for the -fdelete-null-pointer-checks optimisation which is active at this point and which can be turned on or off) which is appropriate in the environments where the documentation states it is. In so far as there's a gcc bug, it's a documentation bug for the -O2 optimisation since it -O2 doesn't clearly warn that code meaning modification may take place and state explicitly which -f flags to examine to be sure that all the modifications are okay.
The error was that the compiler optimized away the if statement,
Being more specific, based on reading the code in the SANS report after getting the suggestion from a user comment in the Register, the error was that the compiler was in an optimising mode which told it to optimise away such checks where the Null pointer had already been dereferenced. -O2 was active and that clearly means that -fdelete-null-pointer-checks is turned on.
Two groups are at fault here:
The optimisation was sufficiently clearly documented (it's listed in gcc under -O2 and when you look at the documentation of that option it does say that some checks may be optimised away and that in some environments this may be dangerous). Thus the Linux Kernel team has some blame.
In the GCC optimisation options under -O2 it does not explicitly mention that the optimisations may have security implications. There should be, in my opinion, a clear statement that below some optimisation level GCC will try not to change the meaning of code under any circumstances.
From one point of view, I guess this shows the strength of the Linux model of development where release early/release often means such bugs can be found before the public starts to actually use the software.
From another point of view, however, I wish that the Linux kernel developers could come up with a more mature attitude to security people, however immature. Yes, it's true that the "security bugs" are, in a sense, just more bugs that could cause loss of data. However, a) that's not an excuse and b) if those bugs did turn up on a real production system in an important application they could cause real problems; exploitable security bugs are much more dangerous than other data loss bugs precisely because they only trigger when someone wants them to trigger.
Linux kernel people who want their kernel to be broadly userd have to make a clear security statement which says why bugs don't matter. It's not good enough to just say "don't use Linux for high security applications" but it should be enough to say "before you use Linux in a configuration where security might be important, ensure you have done a) a source code audit; b) the functional tests according to XYZ etc...".
If you think of each web site you use as an application (and in a real way it is) then think about what proportion of the applications you used in the last year were web sites and what proportion were native binaries. Doesn't it make a bit of sense to optimise for the 90% case (99.9%??). Even if you look at it in terms of time used, you might find that the aged among us still have majority use of native binaries, but most younger people probably spend much more time using web applications. It makes sense to confine Windows applications to a Citrix server where someone else can manage them properly and you have no need to learn the complexity of Windows permissions model etc.
I think that the value of systems often comes from the challenge they set themselves. In this sense, the web browser has set its self the challenge of allowing anyone at random to provide code and still providing a safe environment (yes; it's failing at present, but it's close and Chrome sounds even closer) which separates one application from the other. It's pretty clear that Windows gave up completely on that challenge and just decided "you have to have a virus scanner and if anything new comes up, you're on your own". In that environment, the web browser is now delivering much of the value in a system and native applications are becoming legacy. They will take years and years to die (lots of people still use VMS, you know) but they become irrelevant to future development.
Personally I don't like this at all. When you lose control of your computing, you lose control of your privacy. If your files are "in the cloud" then there's little to stop the person controlling the cloud from poking around without your knowledge. Given that MS seems to have given up, I hope that someone from outside can make a third way in this competition.
Slashdot Mirror
This is a startup we are talking about. A simpler solution is to just treat the file server as somewhat untrusted. Provide GPG/PGP/some encryption software to all employees and keep important files encrypted when on the server.
"which company do you work for?"
To which I can only reply; "a major one."
You may. I buy lego. As I said, if the value to be protected multiplied by the risk is more than the cost then go for it. In this case it is.
I would guess that it costs less to outsource this sort of work
That's true. It's mostly a tax and shareholder benefit (you don't have assets and depreciation (CAPEX) instead you have costs and service charges (OPEX)) but it's also true that since the outsourcing company probably works for several other companies they can share costs and normally come in cheaper.
This means that it's a simple calculation in theory. If the extra cost of doing on site administration properly, or at least better than the external company, is more than the value of the information (asset) that might be lost times the chance of it being lost (risk) then forget about it. There's a slight chance might save your company money, but you guarantee to lose it some money.
Simply put; in business, especially start ups; there's always risk. If you have a fire in your office your company is probably dead. Probably there's a key person in your team who, if he leaves, will stop the company working. List all the risks you can think of and handle those risks where you can get the best benefit for the least money. Do that in the cheapest way possible (maybe a contract change will reduce the risk of your administrator to a reasonable level). It is possible that there's some special data where that risk is the system administrator in which case you might be worth adding extra protection. For the rest just accept the risk and move forward.
In the end; you seem to be the responsible manager. You have to calculate the above things to your satisfaction and spend your money to make things work best taking into account all possibilities and not just this one. Since we don't have enough information about the information we can't really help you.
I don't see how licensing the code under the GPL is any sort of safety net for Dev Ltd in comparison to the BSD licence, given that it wouldn't prevent a potential competitor who might get hold of the code from offering that code under the exact same terms, but without the cost overhead of actually having to do the development work.
The trick is that you can use this for price differentiation. Some customers want full control and are willing to pay. Others want the code as cheap as possible and don't care. Give them a discount if they take GPL. That way you can be sure that they just make normal use of it.
The GPL is obviously preferable to closed-source software in this case, but I'm not sure how it's preferable to the BSD/MIT ilk of licences.
This depends on circumstances. In most cases the majority of the entities working on the software are not competitors, however competitors also can use the software.
When you release BSD software, you get equal support to all the other people who cooperate with you. However, your competitors have a possibility to get a specific advantage. They can take your software, use it as you do, but add their own proprietary changes which they do not share.
This means that companies should not contribute to BSD projects without considerable care. E.g. if a feature is basic and your competitor already has it in their products you can contribute it because your competitor won't benefit. If a feature is advanced and product differentiating then you should never release it to a BSD project.
With a GPL project, there is another option. You contribute to the project. Any competitors which take that feature change their relationship with you. You and your former competitor cooperate in an open and legal way in one particular area (this is legal because it is directly to the benefit of the consumers / public etc.) whilst competing on others (service ; hardware ; other software bundled etc.).
In theory, this means that BSD software is better for short throw away projects where you will never work with anyone else whilst GPL is better for long term stable projects where cooperation will be most valuable. In practice, things which are planned short term very often become long term. This means it's normally better to use and release GPL software
There is one exception to this. If you are releasing a feature that you want everybody to use, including proprietary vendors, then you might find that the GNU All Permissive License is a good option. At least noticing its existence is quite ironic given the summary on this story.
It's just history and cooler heads are now prevailing.
I'm really not sure what you mean by that? The free software foundation has had a page recommending licenses other than the GPL for as long as I remember. You can't say "The proponents of GPL" without including the free software foundation. You can't say "like to tell people that the world only needs one open source license" about an organisation which since at least 2001 has been recommending the X11 license as a better alternative to the BSD license (check archive.org).
If the author wanted to merely mislead, he would have said something like "there are GPL proponents who will tell you that the world only needs one open source license". If he wanted to tell the truth, he would say something "a few irrelevant fanatics who have no real credibility even in the free software movement will tell you that the GPL is the only acceptable license for software" or, "I once met a guy in a bar who, after downing 10 pints and just before falling under the table said 'wouldn't it be really good if all software was under the GPL'. As it was, he lied.
"fabrication" is a nice word. Lie is better. The Free software foundation, the main proponent of the GPL, actively recommends many other licenses than the GPL and for them and most users there is little difference. It's when you see a lie like this in the headline that you know that someone has an anti FOSS agenda (admittedly, it's in the middle of the Yahoo article, but the person writing it knew which sentence would go at the top in Slashdot). I wonder if yahoo really isn't joining the dark side.
What I've found, however, is that in a commercial environment the GPL is a very important tool. It's the one of the few licenses which can be trusted to build a completely fair sharing system where many companies can come together and produce one set of code without the likelihood of the other companies cheating on them. It's definitely true that commercial entities make more software based on BSD/MIT licenses. However, the fact that you see more contributions to the base software on GPL systems is not an accident. It happens because the commercial entities can be happy that if their contribution is used against them, they will at least have the come back of being able to use changes.
I've seen (and posted about before) many examples where the use of a non copyleft license or a less effective copyleft license has lead to abandoned projects. The most classic being the failure of the ipsilon routing contributions to be pushed back into FreeBSD which died with the operating system. This happens because licenses such as Apache and BSD don't demand contributions, which means that when the lawyers are asked, they often recommend against contributing "for now" and the contributions actually never happen.
For this usage, the AGPLv3 is also a big advance and should IMHO probably be the license of choice for all projects which want to have efficient long term cooperation with commercial software producers going forward. Having said that, the most important thing is to work together with other people who have similar interestes. The F vs OSS debate is all very fine in theory, but in real life everybody has very much to cooperate over. That's seems to be the main reason why Free software foundation generally recommends that people contribute using the projects own license.
In OSS it code often gets abandoned for other reasons. This can be code that "just works". It's somewhat similar to various legacy applications that are running in dos boxes today because they do something very obscure and useful but which can't drive further commercial development.
Abandoned, unused, code loses value. However, abandoned, used code often becomes more valuable. The world changes to ensure it has the environment to keep it going. In this case the OSS model of leaving the code around is much better. When someone decides the code has become too valuable to be abandoned, then they can un-abandon it. If the code remains abandoned and is less and less used; it's hardly difficult to use project activity as a filtering criteria in searching.
When rewriting, the old code is crucial competition. In the OSS model, it's also a crucial set of information. It should be maintained until such time as the new code is clearly better in (almost) every way. The new code should be able to replace the old with little difficulty and only few limitations. If it can't do that, then likely it has failed to learn from the old and will actually be worse.
I'm sure there are exceptions, but what Joel is saying is that there should be a presumption for old code. I think that he's almost always right.
That's actually wrong and deliberately so. The Scottish system has "not guilty", "not-proven" and "guilty". Legally there is little difference, but by custom, not proven means "managed to get away with it" and is attached to specific social stigma. Not guilty means "everybody should treat this man as innocent". English tradition, including US tradition has specifically rejected the not-proven verdict.
s/racist US/racist US police/ apologies to anyone feeling slighted.
Innocence or guilt is a matter of fact, not of proof.
I don't see the justification for modding the parent down. legally you are "innocent until proven guilty". However, that doesn't mean you didn't do it. If I saw you do it; even if you get cleared because two of your mates say you didn't do it, I can still say you are guilty. If you try to sue me, you have a completely different standard of proof. Even if someone sues you for the damage you did during your crime, they have a different standard. That's why when the police screwed up the prosecution of OJ by messing with the evidence it was perfectly right that he got let off on the criminal trial and lost at the civil trial. The jury couldn't reasonably give a guilty verdict if racist US were involved in prosecuting a black man and tampering with evidence, but you and I know that OJ was probably guilty as sin.
Innocent until proven guilty is a useful thing. If someone is found innocent by a court you should probably treat them as such unless you know different. That keeps the police working harder; it keeps the system cleaner and it means that when innocent people are charged the consequences of the mistake are minimised. However, if you do know different and you don't do work for the government your obligations are pretty limited.
read and understand; please
Let me tell you that your application for Verizon marketing department is hereby declined. Thanks. Don't call us, we'll call you.
I don't think the compiler has any way to be sure. The check against that in the i386 architecture is to make sure that the page at address 0 isn't mapped in to process / kernel memory. However, that mapping could be changed at run time, so the warning could be there or not during program run for the same code at compile time.
For me, an important downward turning point occurred when Microsoft violated Apple's UI guidelines, which stated that documents should always re-open with the insertion point positioned where it was
Damnit Sir; where may I subscribe to your journal? I never even noticed that. I had thought that it was just system stability which peaked in the 1970/1980s and of course the Web in the 1990s.. We're doomed.
What you and, it seems Negroponte himself, don't understand is that the OLPC project should have been completely doomed from the start. They had to do G1G1 because otherwise they would have been directly competing against normal PC/computer/software manufacturers who have patents and would kill them dead. It's surprising that this project did anything at all. That it managed to kick start the Netbook and effectively wipe out a huge proportion of Microsoft's profit is astounding. Negroponte seems a bit deluded to me; I think he completely screwed up the community aspect. However, I also think that most people would have completely failed at this project. Better to see the glass half full in my opinon. In the middle of the Sahara desert.
Reply to myself; sorry
This code is only reasonably legitimate because Linux user processes normally do guarantee that null pointer de-references cause aborts.
Bullshit; What you mean is:
The reason this could be legitimate in the Linux Kernel is because they have a special environment where null pointer dereferences are guaranteed not to cause a crash. However, that means that they have to rely on the compiler behaving in a defined way which means that they are fundamentally responsible for checking all the optimisations etc. etc. which their code relies on.
In a Linux user process, the compiler behaviour would be fine because Linux user processes normally do guarantee that null pointer de-references cause aborts. The kernel code would be wrong because
Thinking about this, it seems more, it seems to be a needlessly hairy and careless thing to allow in kernel code. There's a perfectly legitimate way to do this in C (get the buffer, check it's not null, use it). That legitimate way could be optimised by the compiler to be just as fast as the code used. Why not just do it right in the first place. Then, when someone cuts and pastes into user code at some later point, there won't be an problems.
You can spin it any way you want but it is still not true. There are jokes about "undocumented features" but this isn't even that. It's a clearly documented feature if you look up the optimisation. It's not even incorrect according to the C standard. When you dereference the null pointer then you get "undefined behaviour" up to and including initiation of global nuclear war on computers with the appropriate peripherals (unfortunately I can't find the original Fortran quote I am abusing here). The fact that your compiler does different things during different compiles is perfectly correct and the least of your problems.
This code is only reasonably legitimate because Linux user processes normally do guarantee that null pointer de-references cause aborts.
Well, after 2008, the year of the Windows.NET stock exchange, I think 2009 is already the year of the Linux stock exchange. At least it's clear now that people do get fired for buying Microsoft.
It's not a compiler "bug" since it's clearly documented behaviour (for the -fdelete-null-pointer-checks optimisation which is active at this point and which can be turned on or off) which is appropriate in the environments where the documentation states it is. In so far as there's a gcc bug, it's a documentation bug for the -O2 optimisation since it -O2 doesn't clearly warn that code meaning modification may take place and state explicitly which -f flags to examine to be sure that all the modifications are okay.
The error was that the compiler optimized away the if statement,
Being more specific, based on reading the code in the SANS report after getting the suggestion from a user comment in the Register, the error was that the compiler was in an optimising mode which told it to optimise away such checks where the Null pointer had already been dereferenced. -O2 was active and that clearly means that -fdelete-null-pointer-checks is turned on.
Two groups are at fault here:
The optimisation was sufficiently clearly documented (it's listed in gcc under -O2 and when you look at the documentation of that option it does say that some checks may be optimised away and that in some environments this may be dangerous). Thus the Linux Kernel team has some blame.
In the GCC optimisation options under -O2 it does not explicitly mention that the optimisations may have security implications. There should be, in my opinion, a clear statement that below some optimisation level GCC will try not to change the meaning of code under any circumstances.
From one point of view, I guess this shows the strength of the Linux model of development where release early/release often means such bugs can be found before the public starts to actually use the software.
From another point of view, however, I wish that the Linux kernel developers could come up with a more mature attitude to security people, however immature. Yes, it's true that the "security bugs" are, in a sense, just more bugs that could cause loss of data. However, a) that's not an excuse and b) if those bugs did turn up on a real production system in an important application they could cause real problems; exploitable security bugs are much more dangerous than other data loss bugs precisely because they only trigger when someone wants them to trigger.
Linux kernel people who want their kernel to be broadly userd have to make a clear security statement which says why bugs don't matter. It's not good enough to just say "don't use Linux for high security applications" but it should be enough to say "before you use Linux in a configuration where security might be important, ensure you have done a) a source code audit; b) the functional tests according to XYZ etc...".
The following simple test shows that /dev/zero is all holes.
bash-3.2$ dd if=/dev/zero bs=4096 count=2560 of=testme
2560+0 records in
2560+0 records out
10485760 bytes (10 MB) copied, 0.0258266 s, 406 MB/s
bash-3.2$ cp --sparse=always testme testmetoo
bash-3.2$ ls -l testme testmetoo
-rw-r--r-- 1 rtfatroll rtfatroll 10485760 2009-07-17 22:01 testme
-rw-r--r-- 1 rtfatroll rtfatroll 10485760 2009-07-17 22:02 testmetoo
bash-3.2$ ls -s testme testmetoo
10256 testme 0 testmetoo
bash-3.2$
I had the same reaction, also Cringly is trying to be provocative for the sake page views; that is to say advertising revenue.
fixed that for you
If you think of each web site you use as an application (and in a real way it is) then think about what proportion of the applications you used in the last year were web sites and what proportion were native binaries. Doesn't it make a bit of sense to optimise for the 90% case (99.9%??). Even if you look at it in terms of time used, you might find that the aged among us still have majority use of native binaries, but most younger people probably spend much more time using web applications. It makes sense to confine Windows applications to a Citrix server where someone else can manage them properly and you have no need to learn the complexity of Windows permissions model etc.
I think that the value of systems often comes from the challenge they set themselves. In this sense, the web browser has set its self the challenge of allowing anyone at random to provide code and still providing a safe environment (yes; it's failing at present, but it's close and Chrome sounds even closer) which separates one application from the other. It's pretty clear that Windows gave up completely on that challenge and just decided "you have to have a virus scanner and if anything new comes up, you're on your own". In that environment, the web browser is now delivering much of the value in a system and native applications are becoming legacy. They will take years and years to die (lots of people still use VMS, you know) but they become irrelevant to future development.
Personally I don't like this at all. When you lose control of your computing, you lose control of your privacy. If your files are "in the cloud" then there's little to stop the person controlling the cloud from poking around without your knowledge. Given that MS seems to have given up, I hope that someone from outside can make a third way in this competition.