Your argument made me think of qmail. The author wanted it to be more secure than sendmail, and designed it to be secure. I think he has a large cash reward to anyone who finds a bug in it. And to date, no-one has ever found a security bug in it.
Similarly, Dovecot is a replacement pop3/imap server, similarly designed to be secure and it too has a monetary reward for anyone who can find a security bug.
So, the argument that even the best, most conscientious and meticulous coder will inadvertently introduce a security bug like a buffer overflow is just wrong. People have written code without these bugs (and these are publicly network-connected apps, written in C or C++) without security issues.
I think the problem is about design of the code - if you make it modular, you can better audit the smaller chunks to see how it works and where the flaws may be,m then you use better libraries to wrap around the parts you know may be problematic. You also handle data input and output with more care and you have a secure system even if you write it in the most low-level language.
Also, writing code in.NET just prevents *some* security errors like buffer-overflows. Other issues are not fixable (eg. if you don't secure your user-input data, someone will try to inject code)
from the linked article (not the inquirer crap) SWORD robots are more accurate than human soldiers; the gun is mounted on a stable platform and fired electronically, eliminating trigger recoil, anticipation problems and timing the breathing cycle when firing
I think breath control is less of an issue when firing 750rpm. Breathing after suffering the recoil.. now that's another matter:-)
Apparently all the objects you create in their 'buckets' are encrypted and secure from everyone. So, fine with that.
I would like to see them implement rsync to get data to them, but as its primarily a data-storage service, and not a backup-service (ie its for your web app to hold and access data, not to dump nightly backups on), I doubt we'll see rsync ever, especially as rsync does require CPU time which I bet they have little of in comparison to the vast amounts of storage space.
Google are apparently working on a simialr storage system, so we'll have to see what they come up with. If you want backups.. bqinternet are very popular, and support rsync, and is roughly the same price as Amazon once you start storing a certain amount.
Why do you think that if code is compiled locally its inherently unstable? Debian package builders don't have a magical gcc which makes code crash less than my gcc.
Not that local compiled code is unstable, but it is less stable than a binary package. (* big difference).
The guy who compiles a binary for me (and everyone else) has it tested on thousands of machines, if there is a bug in his compile switches or *anything*, it will be found and fixed once. With a locally compiled version, I end up finding the bug first (and everyone else who compiles it too) and we reproduce the effort of working with the bug a hundredfold.
I refer particularly to my recent experiences with compiling a custom apache for a webserver control panel (one that has a good rep for reliability). In this case, compiling PHP 4.4.2 on my 64-bit box didn't work due to issues with compiling Pear. An rpm for this would have been a drop in and go issue, and I would have saved myself several hours compiling and reverting to the old version.
For some things, compiling is a good idea. But for many, many packages, especially very widely popular packages (such as Apache for instance), then binary distribution is definitely the superior solution. (doubly so with Apache and its loadable modules).
The performance issue, BTW, is another bit of FUD in this issue. All the binary packages I use come in several varieties for different platform, SMP, and processor varieties. Unlike Windows where you get the x86 version built with 'blend' processor options, the package builders compile in a sandbox with the different processor flags set so I get to install a 64-bit SMP version every time.
... and are any other reporting tools available in other languages, eg. C++. I know Crystal comes packaged as a COM object in MS land which makes it a language independant component, but what about integrating these OSS reporting tools into existing projects?
On the other hand, you cannot perform automated installs if it asks you anything. I'd rather come in to a log that said 'failed to install X' than it made a decision for you. IIRC, RPM will fail if it cannot resolve a dependancy. Its up to a package installer to resolve such issues (eg. one like Apt, or Yum)
I think you're confusing RPM (the package) with APT (the installer). You might as well compare RPM with YUM. RPM does come with a simple installer (obviously, you couldn't install anything otherwise) but it doesn't resolve dependancies, it only knows how to install itself.
again, another Linux poster starts complaining about something trivial and religious. Is it because RPM is a RedHat-defined thing, and RedHat 'sold out'?
Its this kind of b*ll*cks that has stopped Dell from supporting Linux, read what the he said about the community complaining if he picked a distro, and you have exactly demonstrated why he's right.
Maybe that's the point - Dell doesn't have the Linux community as a potential customer (because they want everything for free:-) )
Dell has to pander to the kind of custoemr he already has - businesses who don't mind paying for something as long as it works, and works well. So if he picked RedHat (for instance), shipped a support contract with each box, they'd be very happy and he'd sell loads of Linux boxes. The Linux community would probably complain that it wasn't Debian though and wouldn't buy the boxes anyway, so maybe he has grokked the community correctly.
I agree that have any distro would be a good thing (and I think RedHat EL4 woudl be a good choice given the demographic of Dell's target audience - they mosty run CentOS for their web-connected servers anyway).
Well, once you read this snippet from the article, they'll have enough ammo:
"There is one caveat: PHP, the popular programming language, is the only component in the LAMP stack that has a higher bug density than the baseline, Coverity said."
I assume he means the baseline of 0.434 bugs/1000 lines, and that if they removed PHP from the LAMP stack, that average bug count would go down even further.
Nope, its very old news. I implemented a location lookup system for a major UK roadside breakdown service (so if you've broken down in the middle of nowhere they can find out roughly where you are).
As for abuse... well, lets say that during testing, my location was repeatedly looked up whilst I travelled between the customer and my office, by my colleagues, so it is very easy. in fact, they had to add a audit trail to the lookups so that callcentre staff would stop looking up their boyfriend's (or whoever) locations.
On the good side, someone I know used it repeatedly to determine the location of his wife's handbag after it (and the phone inside) was stolen. I guess he had permission from his wife, though the thief obviously didn't consent.
The good news though, is that the location accuracy is quite poor. It is almost useless to determine the exact location of someone, and quite often the location returned is useful only to tell what town/village they are in.
Once Oracle own them, they can offer a free database to their low-end customers (who simply cannot afford Oracle licences), and then sell them other stuff they don't really need (like consultancy and support), and also suggest they migrate to an 'enterprise' database like Oracle when they start to outgrow MySQL.
They cannot reduce the Oracle licence as it would devalue the DB from a marketing point of view. MySQL is a kind of embrace-and-extend when they use it to get their hooks into you, and not let you go.
in comparison to C#, MS's C++ has the generational garbage collector, but you have to use its managed extensions to access it. On the other hand, C++ has so many garbage collectors (just google) that you can always find one that fits your needs exactly without taking the bundled general purpose version.
The guy is focussing on the fact that in both cases the driver can get himself killed
However, one road puts the driver at such a state of complacency that nothing can go wrong unless he's particularly stupid, that he is more likely to suffer. The dirt track road makes a driver more cautious and ready for things to go wrong.
ie. Linux user - install and go. Windows user - windows update.. check. firewall.. check, anti-virus.. check, anti-spyware.. check. Now as secure as you're going to get with any OS.:)
I have to say that a bad program will still leak memory, even in a GC environment. All you need to do is allocate objects in a container, the root of which is always kept live. One could say that this is not a memory leak i suppose, but I think that that's just hiding behind words.
In my experience, this kind of leak is the majority of problems, in a loop its quite easy to see where something is allocated, and you've forgotten to free it, and so its easy to fix that bug. With a container where you forget to remove the object, its not so obvious.
That's why these languages typically are used for scripting or for projects only done by an elite few of highly competent developers (fyi most web development work is basically scripting)
I almost agree with you - however these languages are used for projects that are a chaotic mess of code that could be considered throwaway. (ie most web development).
The elite developers I know tend to use statically typed, lower level languages, and are happy with the structure it imposes.
Personally, I'm having a hard time seeing how a language which makes a "Hello World" program take a tenth of a second of CPU time and 50 MB of VM size to execute could be considered un-bloated, whatever arguments you may have.
ah, well its not a good analogy is it - that little, do nothing program is 99% Java framework and 1% your app. Turn it into a larger scale, enterprise application and it'll be 20% framework, 80% app. Which is still totally unacceptable as some of the enterprise apps I have deployed already use gigs of RAM anyway (it wouldn't be a en enterprise scale application if it did little). Writing such things in Java would just make them un-deployable on servers with only 4Gig!
Imagine running 2 of these serious applications on the same server! Impossible. Quick! more hardware required!!
So yes, I agree - throwing memory at a problem doesn't solve the problem!!
From a paper written by Phil Dykstra, back in 1999.
"A recent example comes from the Pacific Northwest Gigapop in Seattle which is based on a collection of Foundry gigabit ethernet switches. At Supercomputing '99, Microsoft and NCSA demonstrated HDTV over TCP at over 1.2 Gbps from Redmond to Portland. In order to achieve that performance they used 9000 byte packets and thus had to bypass the switches at the NAP! Let's hope that in the future NAPs don't place 1500 byte packet limitations on applications."
Ok, forget it mentions the M word, this article is about using jumbo frames (9000 byte packets) instead of the 1500 byte ones that were originally specced in 1980 (back when ethernet was.. not quite as fast as it is today).
Seeing as how the internet as a whole is based on this packet size, and the article (http://sd.wareonearth.com/~phil/jumbo.html) describes the stunning performance gains that can be had with jumbo frames, the internet as a whole is actually being held back significantly by it (ie. increase the frame buffer by 6, you get about a 40 times throughput)(bigger frames than 9000 bytes are not practical due to other TCP design limitations).
His recommendations are - if you're on a LAN, enable jumbo frames today.
IPv6 will not have this restriction and so will be faster, maybe things like HDTV on demand will drive its adoption on the internet.
You're not married with kids and a huge weekly shopping bill then? Have you not seen people load up a shopping trolley so its practically overflowing, with bags hung off the side? Think how much they get back. If you also get loyalty rewards on your fuel purchases, then those little bits you and I get back add up over time.
Believe me, you *never* say 'no thanks' when the cashier offers to take £5 off your bill.
It does remind me of an article I read ages ago about a researcher who determined the effects of flushing.. the spray doesn't spread fecal matter onto the seat.. but practically everywhere.
The 2 points I took away from the article was a) he puts the lid down when flushing, and b) he keeps his toothbrush in the cabinet.
I wouldn't mind that - its not as if there's a lack of ego on/. but his comment Most of them are probably incompatible with eachother, so the code has to make sure those conflicts do not happen. tells me he doesn't know what he's talking about, so yes, you're quite right.
For what its worth, reading the other posts on this topic does suggest that OpenVZ is a good thing to have, and would not interfere with other virtualisation systems - OpenVZ is more about process separation than true virtualisation anyway, so would make a good security feature to the kernel, regardless of running multiple VMs on it.
Slashdot Mirror
Your argument made me think of qmail. The author wanted it to be more secure than sendmail, and designed it to be secure. I think he has a large cash reward to anyone who finds a bug in it. And to date, no-one has ever found a security bug in it.
.NET just prevents *some* security errors like buffer-overflows. Other issues are not fixable (eg. if you don't secure your user-input data, someone will try to inject code)
Similarly, Dovecot is a replacement pop3/imap server, similarly designed to be secure and it too has a monetary reward for anyone who can find a security bug.
So, the argument that even the best, most conscientious and meticulous coder will inadvertently introduce a security bug like a buffer overflow is just wrong. People have written code without these bugs (and these are publicly network-connected apps, written in C or C++) without security issues.
I think the problem is about design of the code - if you make it modular, you can better audit the smaller chunks to see how it works and where the flaws may be,m then you use better libraries to wrap around the parts you know may be problematic. You also handle data input and output with more care and you have a secure system even if you write it in the most low-level language.
Also, writing code in
from the linked article (not the inquirer crap) SWORD robots are more accurate than human soldiers; the gun is mounted on a stable platform and fired electronically, eliminating trigger recoil, anticipation problems and timing the breathing cycle when firing
:-)
I think breath control is less of an issue when firing 750rpm. Breathing after suffering the recoil.. now that's another matter
Apparently all the objects you create in their 'buckets' are encrypted and secure from everyone. So, fine with that.
I would like to see them implement rsync to get data to them, but as its primarily a data-storage service, and not a backup-service (ie its for your web app to hold and access data, not to dump nightly backups on), I doubt we'll see rsync ever, especially as rsync does require CPU time which I bet they have little of in comparison to the vast amounts of storage space.
Google are apparently working on a simialr storage system, so we'll have to see what they come up with. If you want backups.. bqinternet are very popular, and support rsync, and is roughly the same price as Amazon once you start storing a certain amount.
Why do you think that if code is compiled locally its inherently unstable? Debian package builders don't have a magical gcc which makes code crash less than my gcc.
Not that local compiled code is unstable, but it is less stable than a binary package. (* big difference).
The guy who compiles a binary for me (and everyone else) has it tested on thousands of machines, if there is a bug in his compile switches or *anything*, it will be found and fixed once. With a locally compiled version, I end up finding the bug first (and everyone else who compiles it too) and we reproduce the effort of working with the bug a hundredfold.
I refer particularly to my recent experiences with compiling a custom apache for a webserver control panel (one that has a good rep for reliability). In this case, compiling PHP 4.4.2 on my 64-bit box didn't work due to issues with compiling Pear. An rpm for this would have been a drop in and go issue, and I would have saved myself several hours compiling and reverting to the old version.
For some things, compiling is a good idea. But for many, many packages, especially very widely popular packages (such as Apache for instance), then binary distribution is definitely the superior solution. (doubly so with Apache and its loadable modules).
The performance issue, BTW, is another bit of FUD in this issue. All the binary packages I use come in several varieties for different platform, SMP, and processor varieties. Unlike Windows where you get the x86 version built with 'blend' processor options, the package builders compile in a sandbox with the different processor flags set so I get to install a 64-bit SMP version every time.
Why not 6 times, or 8 times? Is 7 a magic number?
well as it happens, yes it is.
... and are any other reporting tools available in other languages, eg. C++. I know Crystal comes packaged as a COM object in MS land which makes it a language independant component, but what about integrating these OSS reporting tools into existing projects?
On the other hand, you cannot perform automated installs if it asks you anything. I'd rather come in to a log that said 'failed to install X' than it made a decision for you. IIRC, RPM will fail if it cannot resolve a dependancy. Its up to a package installer to resolve such issues (eg. one like Apt, or Yum)
I think you're confusing RPM (the package) with APT (the installer). You might as well compare RPM with YUM. RPM does come with a simple installer (obviously, you couldn't install anything otherwise) but it doesn't resolve dependancies, it only knows how to install itself.
again, another Linux poster starts complaining about something trivial and religious. Is it because RPM is a RedHat-defined thing, and RedHat 'sold out'?
Its this kind of b*ll*cks that has stopped Dell from supporting Linux, read what the he said about the community complaining if he picked a distro, and you have exactly demonstrated why he's right.
Maybe that's the point - Dell doesn't have the Linux community as a potential customer (because they want everything for free :-) )
Dell has to pander to the kind of custoemr he already has - businesses who don't mind paying for something as long as it works, and works well. So if he picked RedHat (for instance), shipped a support contract with each box, they'd be very happy and he'd sell loads of Linux boxes. The Linux community would probably complain that it wasn't Debian though and wouldn't buy the boxes anyway, so maybe he has grokked the community correctly.
I agree that have any distro would be a good thing (and I think RedHat EL4 woudl be a good choice given the demographic of Dell's target audience - they mosty run CentOS for their web-connected servers anyway).
Well, once you read this snippet from the article, they'll have enough ammo:
"There is one caveat: PHP, the popular programming language, is the only component in the LAMP stack that has a higher bug density than the baseline, Coverity said."
I assume he means the baseline of 0.434 bugs/1000 lines, and that if they removed PHP from the LAMP stack, that average bug count would go down even further.
Anonymous posting is harmless,
You havn't seen the hundred posts on my forum saying what a great place http://www.online-poker-casino.com/ is. bastards.
Nope, its very old news. I implemented a location lookup system for a major UK roadside breakdown service (so if you've broken down in the middle of nowhere they can find out roughly where you are).
As for abuse... well, lets say that during testing, my location was repeatedly looked up whilst I travelled between the customer and my office, by my colleagues, so it is very easy. in fact, they had to add a audit trail to the lookups so that callcentre staff would stop looking up their boyfriend's (or whoever) locations.
On the good side, someone I know used it repeatedly to determine the location of his wife's handbag after it (and the phone inside) was stolen. I guess he had permission from his wife, though the thief obviously didn't consent.
The good news though, is that the location accuracy is quite poor. It is almost useless to determine the exact location of someone, and quite often the location returned is useful only to tell what town/village they are in.
Use google:
s ubversion/
http://www.redhat.com/magazine/010aug05/features/
If you plan to share the code in an Open Source project with many people
then look into something that they might actually have heard of and have client tools for, not the most obscure scc system you can find.
SVN and CVS are both excellent choices, free, and popular with lots of different clients.
Once Oracle own them, they can offer a free database to their low-end customers (who simply cannot afford Oracle licences), and then sell them other stuff they don't really need (like consultancy and support), and also suggest they migrate to an 'enterprise' database like Oracle when they start to outgrow MySQL.
They cannot reduce the Oracle licence as it would devalue the DB from a marketing point of view. MySQL is a kind of embrace-and-extend when they use it to get their hooks into you, and not let you go.
in comparison to C#, MS's C++ has the generational garbage collector, but you have to use its managed extensions to access it. On the other hand, C++ has so many garbage collectors (just google) that you can always find one that fits your needs exactly without taking the bundled general purpose version.
The guy is focussing on the fact that in both cases the driver can get himself killed
:)
However, one road puts the driver at such a state of complacency that nothing can go wrong unless he's particularly stupid, that he is more likely to suffer. The dirt track road makes a driver more cautious and ready for things to go wrong.
ie. Linux user - install and go. Windows user - windows update.. check. firewall.. check, anti-virus.. check, anti-spyware.. check. Now as secure as you're going to get with any OS.
Analogy's. Dontcha just love 'em.
I have to say that a bad program will still leak memory, even in a GC environment. All you need to do is allocate objects in a container, the root of which is always kept live. One could say that this is not a memory leak i suppose, but I think that that's just hiding behind words.
In my experience, this kind of leak is the majority of problems, in a loop its quite easy to see where something is allocated, and you've forgotten to free it, and so its easy to fix that bug. With a container where you forget to remove the object, its not so obvious.
That's why these languages typically are used for scripting or for projects only done by an elite few of highly competent developers (fyi most web development work is basically scripting)
I almost agree with you - however these languages are used for projects that are a chaotic mess of code that could be considered throwaway. (ie most web development).
The elite developers I know tend to use statically typed, lower level languages, and are happy with the structure it imposes.
Yes, his job title is probably something like "Professional Application Developer", not "Cowboy Who Plays With New Toys".
I don't like Java myself, but at the end of the day, you work on the systems your employer tells you to, using the tools and standards they demand.
Personally, I'm having a hard time seeing how a language which makes a "Hello World" program take a tenth of a second of CPU time and 50 MB of VM size to execute could be considered un-bloated, whatever arguments you may have.
ah, well its not a good analogy is it - that little, do nothing program is 99% Java framework and 1% your app. Turn it into a larger scale, enterprise application and it'll be 20% framework, 80% app. Which is still totally unacceptable as some of the enterprise apps I have deployed already use gigs of RAM anyway (it wouldn't be a en enterprise scale application if it did little). Writing such things in Java would just make them un-deployable on servers with only 4Gig!
Imagine running 2 of these serious applications on the same server! Impossible. Quick! more hardware required!!
So yes, I agree - throwing memory at a problem doesn't solve the problem!!
best for the internet as a whole
are you sure?
From a paper written by Phil Dykstra, back in 1999.
"A recent example comes from the Pacific Northwest Gigapop in Seattle which is based on a collection of Foundry gigabit ethernet switches. At Supercomputing '99, Microsoft and NCSA demonstrated HDTV over TCP at over 1.2 Gbps from Redmond to Portland. In order to achieve that performance they used 9000 byte packets and thus had to bypass the switches at the NAP! Let's hope that in the future NAPs don't place 1500 byte packet limitations on applications."
Ok, forget it mentions the M word, this article is about using jumbo frames (9000 byte packets) instead of the 1500 byte ones that were originally specced in 1980 (back when ethernet was.. not quite as fast as it is today).
Seeing as how the internet as a whole is based on this packet size, and the article (http://sd.wareonearth.com/~phil/jumbo.html) describes the stunning performance gains that can be had with jumbo frames, the internet as a whole is actually being held back significantly by it (ie. increase the frame buffer by 6, you get about a 40 times throughput)(bigger frames than 9000 bytes are not practical due to other TCP design limitations).
His recommendations are - if you're on a LAN, enable jumbo frames today.
IPv6 will not have this restriction and so will be faster, maybe things like HDTV on demand will drive its adoption on the internet.
You're not married with kids and a huge weekly shopping bill then? Have you not seen people load up a shopping trolley so its practically overflowing, with bags hung off the side? Think how much they get back.
If you also get loyalty rewards on your fuel purchases, then those little bits you and I get back add up over time.
Believe me, you *never* say 'no thanks' when the cashier offers to take £5 off your bill.
It does remind me of an article I read ages ago about a researcher who determined the effects of flushing.. the spray doesn't spread fecal matter onto the seat.. but practically everywhere.
The 2 points I took away from the article was a) he puts the lid down when flushing, and b) he keeps his toothbrush in the cabinet.
I wouldn't mind that - its not as if there's a lack of ego on /. but his comment Most of them are probably incompatible with eachother, so the code has to make sure those conflicts do not happen. tells me he doesn't know what he's talking about, so yes, you're quite right.
For what its worth, reading the other posts on this topic does suggest that OpenVZ is a good thing to have, and would not interfere with other virtualisation systems - OpenVZ is more about process separation than true virtualisation anyway, so would make a good security feature to the kernel, regardless of running multiple VMs on it.