To avoid micrometiorites you would need to move them away from your path. Exert some sort of (virtual) force (gravity, electromagnetic,...). Maybe blast them all away with lasers? Now we have to create a plot with sharks.
There is one USP of OSS: The source is open and can therefore be seen, inspected, improved and reused by anyone.
What do we want from future software (maybe not the full list):
-less bugs
-more security
-better integration options between software A on location X and B on location C.
-easier functional design & testing, especially of a set of applications working together.
-Solve the problems that result in remarks like: 'I want applications to do what I want them to do', 'why are computers so dumb',...
So how do you get more without an exploding code base (and exploding bug count and reduced security): code reuse. Therefore OSS is the future. Maybe current situation will hold for a while (question: how large can the world codebase become for it te become unmanageable?).
The question then is how to do it. We currently use libraries and api's to reuse code, mainly. Some intelligent thinking should go into that. Thoughts?
Patents are a two way deal: exclusivity in exchange for telling us the process of how you achieved it. I don't see how that is true with software; it is just a one way deal.
A computer should do what it is good at: compute. The fact that the only thing we can come up with is emulate neurons shows we don't know how they work and what the objective is.
He does have a point (besides the other BS he is making). It is getting harder and harder to deliver email from valid sources to valid receivers with valid content. Example: We have a web application and it generates reports with a notification to our users. The emails just started to get dropped this December at Hotmail (no bounce, nothing). Until we send the emails from our production IP addresses (which sends high volume mail). Then the mail is accepted and delivered. We solved the issue by 'optimizing' the html.
We see more and more people coming to us (ESP) for application mail delivery. I kidd you not.
I do not see any other orgs, e.g. Tier1 providers or internet exchanges, providing any relevant and coherent data (maybe I am missing some interesting stuff). Maybe these guys have a stroke of luck/DDoSses (which they can market as well). It does not make the data invalid (hard to validate; yes). They have a reputation to keep up (must be pretty clean).
Now that I think of it: Tier1 family is awfull quiet about DDoS. Good for their business.
True. Issue is that what was once handily placed on one server, speaking year 2000 here, now needs to be torn apart. Things have history: Early developers are not always good at admin work. Too easy to get it wrong.
iotop. A VM only makes this problem harder.
We use iotop of course. It was an example of one of many resources: file descriptors, connections, memory, io, bandwidth,... I agree that a VM can make things harder.
Of course we do not start a new kernel for that. We just keep adding cruft after cruft on a machine, no matter how small the cruft. But that is the point. We do that and you end up with a lot of cruft.
From what I was reading there is not much interesting in it... I already included the torrent in the TBL (torrent blacklist). Noone will be seeding it anymore.
There are a couple of issues that arise on production systems I find:
-config files and adhoc installed libraries are impossible to link to the application that actually needs it (given the fact that my time is scarce). Nightmare when upgrading, creating new instances or when pulling apart a system (for e.g. performance/HA).
-if an application uses resources, e.g. I/O, too much you want to know about it, point fingers and restrict its usage (and maybe give it its own). Nightmare when you want to find out 'what causes it to grind to a halt during Xmas'.
-applications has 'resources' they should not have, because another application needed that 'resources'. Example: Qmail needed compiler and afterwards a cracked PHPMyadmin used that to compile malware.
Some of it can be avoided by automation, e.g. Puppet, good administration of all systems (which people hate and 'forget' or do not get the time for). But it is not simple as it should be.
Slashdot Mirror
To avoid micrometiorites you would need to move them away from your path. Exert some sort of (virtual) force (gravity, electromagnetic, ...). Maybe blast them all away with lasers? Now we have to create a plot with sharks.
All video should be uploaded to a vault where it is supervised by court (why else would you need evidence).
You first taze the camera and then the rest.
There is one USP of OSS: The source is open and can therefore be seen, inspected, improved and reused by anyone.
...
What do we want from future software (maybe not the full list):
-less bugs
-more security
-better integration options between software A on location X and B on location C.
-easier functional design & testing, especially of a set of applications working together.
-Solve the problems that result in remarks like: 'I want applications to do what I want them to do', 'why are computers so dumb',
So how do you get more without an exploding code base (and exploding bug count and reduced security): code reuse. Therefore OSS is the future. Maybe current situation will hold for a while (question: how large can the world codebase become for it te become unmanageable?).
The question then is how to do it. We currently use libraries and api's to reuse code, mainly. Some intelligent thinking should go into that. Thoughts?
So even good snippets of code, combined, will form malware.
Patents are a two way deal: exclusivity in exchange for telling us the process of how you achieved it. I don't see how that is true with software; it is just a one way deal.
A computer should do what it is good at: compute. The fact that the only thing we can come up with is emulate neurons shows we don't know how they work and what the objective is.
And I've always wanted to use something like that to identify and localize mosquitos in my room. All you need then is a laser.
try code re-use.
He does have a point (besides the other BS he is making). It is getting harder and harder to deliver email from valid sources to valid receivers with valid content. Example: We have a web application and it generates reports with a notification to our users. The emails just started to get dropped this December at Hotmail (no bounce, nothing). Until we send the emails from our production IP addresses (which sends high volume mail). Then the mail is accepted and delivered. We solved the issue by 'optimizing' the html.
We see more and more people coming to us (ESP) for application mail delivery. I kidd you not.
Robtex says that Dimenoc contains part of an anti-spam outfit too.
I don't want to pay 10.000$ to my doctor... Sometimes you just do.
I would turn off caches as well..
And who else is the specialist on the planet?
I do not see any other orgs, e.g. Tier1 providers or internet exchanges, providing any relevant and coherent data (maybe I am missing some interesting stuff). Maybe these guys have a stroke of luck/DDoSses (which they can market as well). It does not make the data invalid (hard to validate; yes). They have a reputation to keep up (must be pretty clean).
Now that I think of it: Tier1 family is awfull quiet about DDoS. Good for their business.
If someone is 50% wrong all the time I call him incompetent and fire his ass.
So we need FPGA versions of hardware so we can prove other aspects? Only way to verify besides physical inspection.
Or the possibility to block the IP at the source AS.
Maybe you get privileges with specific data.
un
chroot
True. Issue is that what was once handily placed on one server, speaking year 2000 here, now needs to be torn apart. Things have history: Early developers are not always good at admin work. Too easy to get it wrong.
iotop. A VM only makes this problem harder.
We use iotop of course. It was an example of one of many resources: file descriptors, connections, memory, io, bandwidth, ... I agree that a VM can make things harder.
chroot with linux-vserver enforcement.
We use OpenVZ, at the moment.
Of course we do not start a new kernel for that. We just keep adding cruft after cruft on a machine, no matter how small the cruft. But that is the point. We do that and you end up with a lot of cruft.
It seems someone just did learn that aspect...
From what I was reading there is not much interesting in it... I already included the torrent in the TBL (torrent blacklist). Noone will be seeding it anymore.
There are a couple of issues that arise on production systems I find:
-config files and adhoc installed libraries are impossible to link to the application that actually needs it (given the fact that my time is scarce). Nightmare when upgrading, creating new instances or when pulling apart a system (for e.g. performance/HA).
-if an application uses resources, e.g. I/O, too much you want to know about it, point fingers and restrict its usage (and maybe give it its own). Nightmare when you want to find out 'what causes it to grind to a halt during Xmas'.
-applications has 'resources' they should not have, because another application needed that 'resources'. Example: Qmail needed compiler and afterwards a cracked PHPMyadmin used that to compile malware.
Some of it can be avoided by automation, e.g. Puppet, good administration of all systems (which people hate and 'forget' or do not get the time for). But it is not simple as it should be.
+1 in my book.