If you're near the south of the UK, it's also being shown at the Science Museum in London on a regular basis. With all of the other material there, it's a fantastic place to take a day trip to.
Space and heat dissipation are becoming very serious limiting factors in the scalability of supercomputing clusters.
In theory, you could just keep adding more and more nodes to an existing system, and as long as your interconnects were good enough, you could scale.
But in practice energy consumption (and getting rid of the waste heat afterwards) will hit you before you can get much futher that we are today. The Big Mac G5 cluster in VA, for example, required custom cooling systems because conventional aircon units simply couldn't handle the load.
As a result, IBM's work is *vital* for making faster supercomputers -- and the improvements they're claiming are very impressive indeed.
One random idea I had yesterday -- use them at a protest rally.
Having every protester bring a laser pointer and point it at the source of their ire as they go past could make the point quite well. Particularly if they're just watching silently with banners saying something like "We're watching you" or similar.
You'd have to make sure that you wouldn't injure the target with that many beams in the same place, of course - would getting 20 of those in the eye at once be harmful?
And it might not be a good idea if you tried it against a high-profile person -- for example, George is currently visiting here in London at the moment; the reaction from the police and Secret Service is unlikely to be favourable..
Yes, but you have to be very, very careful. Otherwise, someone could deliberately (manually) attack your honeypot on a critical service port and trigger a firewall update... that knocks all of your critical systems offline.
The advantage here is that the server would *only* counter-attack a box with a fix if it was attacked first.
Although decidedly risky legally-speaking, it would mean that only vulnerable hosts would get contacted and have fixes forcably deployed on them -- meaning that as the original infection dies down then so too will the number of forced deployments.
The key problem with the Welchia worm is that it simply didn't go away. It continues to actively probe and scan for vulnerable machines indefinitely -- and enumerating IP addresses and attempting connections to each one generates a lot of traffic.
No, technically speaking this could be a far better solution than a self-propagating worm. Although not necessarily suitable for the 'net at large, it's definitely viable for, say, a deployment within an organisation which would therefore -- by definition -- own and be permitted to patch all the machines on the local network.
You still have to be very careful that the forced patch deployment doesn't break something else -- but that's not a new problem.
The plan is to continue development. Up to this point, due to the nature of an individual project, development had to be done solo -- although we had various discussions regarding the design of the system.
Hopefully, when Mark gets back from holiday and gets settled at his new job, we'll be able to get going again.
Regarding auto-detection; I agree with you completely that X configuration is just hopelessly broken. (Having had to automate X configuration for the department, I've experienced some pain in this area.)
I was tentatively nominated configuration guru, so when I get some free time from work I'm going to have a go at making a config system for Y that sucks much less than XFree86.
You clearly haven't read the project report, because it says nothing of the kind. Network transparency is NOT the problem. Project Berlin is not, necessarily, the future.
There is plenty wrong with X at a design level. Driver qualily has little to do with it.
Forget your misconceptions, discard your existing agenda, and go back and re-read the report and come back once you've understood.
1. The widget component system is designed so that you could create native widgets for, say, a video renderer. In this manner, you could send it a raw MPEG-2/DiVX/whatever stream and have it rendered and controlled properly with minimal effort. And if you're operating over a network, you don't have to render it client-side and send each frame; you can simply use the compressed stream.
Similar widgets could be implemented for audio, OpenGL-based 3D, etc.
2. This is not a well-substantiated argument. There is no clear reason why Y could not scale up or down.
3. Wrong. So long as the kernel can understand the device, present a/dev/input/eventX handle for it, and a driver exists in Y to support it, it'll work.
4. This will be an extension. Or you could just tunnel it over SSH, much like X does now.
5. Flat-out-wrong. I've seen this run over a slow link, and it works just fine, thankyouverymuch.
6. ``Smooth integration`` is ill defined. If you mean GUI tools for managing a machine, well -- that's an applications, not a windowing system, issue.
7. It doesn't need a window manager -- it *is* one. If you don't like it, you can write a new backend driver to provide the one you want.
8. You can always gzip the stream; that could be an extension. But you already get a lot of benefit from the from the design of the widget system over, for example, X.
1. Y has been designed so that an X compatibility layer would be possible to implement. You wouldn't get many of the benefits from using Y, but it would provide backwards compatibility. I'm pretty sure that's mentioned in the project report.
2. Wrong. Hardware interfaces for new drivers can always be derived from the X source code (where available); if it becomes big enough, then the companies may well be willing to describe their specs for a Y developer, too.
3. The KDE and GNOME desktop projects have a lot of code which is no-longer needed if adapted to run under Y. The applications could probably be adapted to Y with relatively little effort. (I'm not an X/GNOME/KDE coder; the above may be an exaggeration one way or the other.)
4. ``this guy`` is a friend of mine. I know him, he's smart. He aced a first at one of best university's in the UK and got a prize for this project.
You are clearly only questioning the fact that an undergrad could develop something worthwhile when nobody else did. I'd much rather you'd debate the quality of the work rather than baselessly disparaging the person who created it.
Oh, and it wasn't a year of work, it was 9 months, tops. And he still had 8 other courses to do at the same time along with a break to do the requisite 8 final exams.:-)
IIRC, libSDL is used for running Y within an X-Windows session. It made development of the system a lot easier until the Y-specific Radeon backend driver was implemented.
Read the paper. (I went to his project presentation and helped review the paper before it was submitted, so I don't need to.:) All of the details you want are clearly presented there.
And development has stalled until November because he's just finished his 4-yr Masters degree and is taking a well-deserved holiday before starting his new job.:-)
... is to redirect all web accesses from compromised machines to an automatically generated webpage with the patches they need to install.
The department techs are planning to roll out an unattended mechanism whereby we security scan everyone's machine - any box we find to be vulnerable will have all web page requests redirected to our server, which will give them the precise set of patches / AV tools they need to apply to close the hole.
All other network connectivity bar DHCP and DNS will be dropped. When the spider notices the box is secure again, it re-enables connectivity.
DoC don't actually look after dorm connections; this system was designed to handle unmanaged machines that might get plugged into the department network, use VPN, or connect over wireless. But it could be used to solve this problem, too.
The best feature is that it's completely unattended. (Well, apart from updating the signatures and answering questions from the two people who can't work out how to fix their machine. But you'd rather do that than go through level after level of applying security boxes to PCs, wouldn't you?
It also doesn't put any constraints on what students can put on their PCs; we just make network access conditional apon not being rootable.:)
The VIC tool, which provides peer-to-peer video streaming via multicast or unicast can be used to transmit video images to others whilst RAT handles the audio side.
It's free, there's source, and it works. We use it here regularly for conference calls with other institutions in the UK and the US.
If Microsoft's software is as inferior as we, the open source software community, say it is, then it should not be difficult to compete against that software based on quality, features, and usability.
You do not understand. It is difficult to compete because we cannot provide our services on an equal footing with Microsoft because they won't tell us how to interoperate with their systems. If we can't interoperate with MS systems, and everyone else is using MS systems, then open source options aren't really viable, are they?
(Well, in some cases we are viable -- but only because MS wasn't able to stop all the open standards. Look where all of the major open-source successes have been:
Apache, made possible because TCP/IP and HTTP was not a Microsoft invention.
Mozilla, for the same reasons.
GCC, because the Intel processor specifications -- and the languages which build on them -- were not Microsoft inventions.
Linux, because Unix was not a Microsoft invention.
.. and so on. Don't you see? Everywhere Micrsoft go, they conquer. And they don't want to share their spoils with anyone. This is not what a free market is about.
In any case, supporting litigation against Microsoft is a waste of valuable resources that could be better spent [...] educating users so they can make informed choices
If you substituted ``Microsoft`` with ``Big Tobacco``, would you change your mind?
You're missing the fact that people have been locked into using MS-only systems and *even if they wanted to* would find it very hard to stop. Think about it: they, in effect, provide a significant proportion of our computing infrastructure -- and are preventing anyone from competing with them by not disclosing the vital inferface information about the systems they built that others would need to compete.
They work very hard to maintain the monopoly stranglehold they have created. They bombard the young and impressionable with advertising in print, on television, on billboards. They push ``cheap`` versions of their product on impressional students in schools and universities.
They lobby govenments around the world to say "You should let project leaders make their own choice!" when it comes to choosing between a MS or OSS deployment -- whilst simultaneously doing their utmost to prevent any OSS option from becoming viable.
"Just educate people to do something else" you say. If only it were that easy. To stop smoking is a painful and difficult task at the best of times; divorcing yourself of the MS infrastructure that entangles everything we do is no different.
Microsoft has a monopoly. Nobody disputes that fact. They are using their monopoly position to extend their influence and take control of new markets. This is also not in dispute.
If the United States refuses to take substantive action, then that's their choice. But you're starting to hurt *us* now, we will not stand idly by. The EU, our representatives, have asked Microsoft nicely, patiently, to cease their damaging practices. Three times, they told them stop! And yet they persist, relentlessly.
Well, the reports simply state that, in the 360 files they checked (most of them header files) they found 29 cases of a potential NULL pointer dereference and 2 potentially uninitialized variables. This is from the Apache 2.1 codebase as of 31st Jan this year, about 58k lines of code.
Their automated checker also searched for out-of-bounds array accesses, memory leaks, and bad deallocations. It found none.
They also state that they ran the same checks against other codebases, and found that they did marginally better, on average.
In short, this report says that OLD development code for an unreleased opensource project is nearly as good as current commercial offerings. That's at best, when you consider the huge gamut of possible defects that this checker won't pick up. That margin probably disappears in the +/- of the sampling if you were to do a proper statistical analysis.
The report is fairly useless. It certainly should not be taken as a reason to not trust Apache; to do so would be foolhardy particularly given Apache's track record.
Oh, and Reasoning's webserver is being pounded into the ground. You can get my local copy of the reports from here.
Umm, Apache 2.1 hasn't been released yet. Current latest stable is 2.0.46.
I can only assume that they're looking through the current DEVELOPMENT codebase -- finding a higher ``defect density'' in such a development codebase compared with commercial offerings is not exactly unexpected.
They're also some automated code inspection product; the press release doesn't go into details as to the severity of the defects found or the testing methodology.
It'll be necessary to read through the full report before drawing any sound conclusions.
Bear in mind that this a transcript of what Linus said; it has been coerced into written form. It probably sounded a lot more readable when it was spoken.
Slashdot Mirror
If you're near the south of the UK, it's also being shown at the Science Museum in London on a regular basis. With all of the other material there, it's a fantastic place to take a day trip to.
I hate to break it to you, but right now you're reading Slashdot. No calculus here, nuh-uh.
Space and heat dissipation are becoming very serious limiting factors in the scalability of supercomputing clusters.
In theory, you could just keep adding more and more nodes to an existing system, and as long as your interconnects were good enough, you could scale.
But in practice energy consumption (and getting rid of the waste heat afterwards) will hit you before you can get much futher that we are today. The Big Mac G5 cluster in VA, for example, required custom cooling systems because conventional aircon units simply couldn't handle the load.
As a result, IBM's work is *vital* for making faster supercomputers -- and the improvements they're claiming are very impressive indeed.
One random idea I had yesterday -- use them at a protest rally.
Having every protester bring a laser pointer and point it at the source of their ire as they go past could make the point quite well. Particularly if they're just watching silently with banners saying something like "We're watching you" or similar.
You'd have to make sure that you wouldn't injure the target with that many beams in the same place, of course - would getting 20 of those in the eye at once be harmful?
And it might not be a good idea if you tried it against a high-profile person -- for example, George is currently visiting here in London at the moment; the reaction from the police and Secret Service is unlikely to be favourable..
Yes, but you have to be very, very careful. Otherwise, someone could deliberately (manually) attack your honeypot on a critical service port and trigger a firewall update... that knocks all of your critical systems offline.
The advantage here is that the server would *only* counter-attack a box with a fix if it was attacked first.
Although decidedly risky legally-speaking, it would mean that only vulnerable hosts would get contacted and have fixes forcably deployed on them -- meaning that as the original infection dies down then so too will the number of forced deployments.
The key problem with the Welchia worm is that it simply didn't go away. It continues to actively probe and scan for vulnerable machines indefinitely -- and enumerating IP addresses and attempting connections to each one generates a lot of traffic.
No, technically speaking this could be a far better solution than a self-propagating worm. Although not necessarily suitable for the 'net at large, it's definitely viable for, say, a deployment within an organisation which would therefore -- by definition -- own and be permitted to patch all the machines on the local network.
You still have to be very careful that the forced patch deployment doesn't break something else -- but that's not a new problem.
I'm going to go read the article now..
Not really. I've chatted to Mark about Y's design, but it's predominately his own work. T'would be wrong for me to claim but a tentative affiliation.
Cheers,
David
Yeah, I know, I'm kinda ticked off too.
Maybe I can sue Darl for defamation of character by assosciation. *shrug*
Cheers,
David
Slight correction: Not a BSc, an MEng.
Mark, like myself, took the 4-year course.
Cheers,
David
The plan is to continue development. Up to this point, due to the nature of an individual project, development had to be done solo -- although we had various discussions regarding the design of the system.
Hopefully, when Mark gets back from holiday and gets settled at his new job, we'll be able to get going again.
Cheers,
David
Regarding auto-detection; I agree with you completely that X configuration is just hopelessly broken. (Having had to automate X configuration for the department, I've experienced some pain in this area.)
I was tentatively nominated configuration guru, so when I get some free time from work I'm going to have a go at making a config system for Y that sucks much less than XFree86.
Cheers,
David
You clearly haven't read the project report, because it says nothing of the kind. Network transparency is NOT the problem. Project Berlin is not, necessarily, the future.
There is plenty wrong with X at a design level. Driver qualily has little to do with it.
Forget your misconceptions, discard your existing agenda, and go back and re-read the report and come back once you've understood.
This is clearly a troll, but whatever:
/dev/input/eventX handle for it, and a driver exists in Y to support it, it'll work.
1. The widget component system is designed so that you could create native widgets for, say, a video renderer. In this manner, you could send it a raw MPEG-2/DiVX/whatever stream and have it rendered and controlled properly with minimal effort. And if you're operating over a network, you don't have to render it client-side and send each frame; you can simply use the compressed stream.
Similar widgets could be implemented for audio, OpenGL-based 3D, etc.
2. This is not a well-substantiated argument. There is no clear reason why Y could not scale up or down.
3. Wrong. So long as the kernel can understand the device, present a
4. This will be an extension. Or you could just tunnel it over SSH, much like X does now.
5. Flat-out-wrong. I've seen this run over a slow link, and it works just fine, thankyouverymuch.
6. ``Smooth integration`` is ill defined. If you mean GUI tools for managing a machine, well -- that's an applications, not a windowing system, issue.
7. It doesn't need a window manager -- it *is* one. If you don't like it, you can write a new backend driver to provide the one you want.
8. You can always gzip the stream; that could be an extension. But you already get a lot of benefit from the from the design of the widget system over, for example, X.
1. Y has been designed so that an X compatibility layer would be possible to implement. You wouldn't get many of the benefits from using Y, but it would provide backwards compatibility. I'm pretty sure that's mentioned in the project report.
:-)
2. Wrong. Hardware interfaces for new drivers can always be derived from the X source code (where available); if it becomes big enough, then the companies may well be willing to describe their specs for a Y developer, too.
3. The KDE and GNOME desktop projects have a lot of code which is no-longer needed if adapted to run under Y. The applications could probably be adapted to Y with relatively little effort.
(I'm not an X/GNOME/KDE coder; the above may be an exaggeration one way or the other.)
4. ``this guy`` is a friend of mine. I know him, he's smart. He aced a first at one of best university's in the UK and got a prize for this project.
You are clearly only questioning the fact that an undergrad could develop something worthwhile when nobody else did. I'd much rather you'd debate the quality of the work rather than baselessly disparaging the person who created it.
Oh, and it wasn't a year of work, it was 9 months, tops. And he still had 8 other courses to do at the same time along with a break to do the requisite 8 final exams.
Cheers,
David
IIRC, libSDL is used for running Y within an X-Windows session. It made development of the system a lot easier until the Y-specific Radeon backend driver was implemented.
Cheers,
David
Read the paper. (I went to his project presentation and helped review the paper before it was submitted, so I don't need to. :) All of the details you want are clearly presented there.
:-)
And development has stalled until November because he's just finished his 4-yr Masters degree and is taking a well-deserved holiday before starting his new job.
Cheers,
David
That's no moon.
[Fired. -Ed]
... is to redirect all web accesses from compromised machines to an automatically generated webpage with the patches they need to install.
:)
The department techs are planning to roll out an unattended mechanism whereby we security scan everyone's machine - any box we find to be vulnerable will have all web page requests redirected to our server, which will give them the precise set of patches / AV tools they need to apply to close the hole.
All other network connectivity bar DHCP and DNS will be dropped. When the spider notices the box is secure again, it re-enables connectivity.
DoC don't actually look after dorm connections; this system was designed to handle unmanaged machines that might get plugged into the department network, use VPN, or connect over wireless. But it could be used to solve this problem, too.
The best feature is that it's completely unattended. (Well, apart from updating the signatures and answering questions from the two people who can't work out how to fix their machine. But you'd rather do that than go through level after level of applying security boxes to PCs, wouldn't you?
It also doesn't put any constraints on what students can put on their PCs; we just make network access conditional apon not being rootable.
University College London have been developing a number of multimedia applications -- see http://www-mice.cs.ucl.ac.uk/multimedia/software/.
The VIC tool, which provides peer-to-peer video streaming via multicast or unicast can be used to transmit video images to others whilst RAT handles the audio side.
It's free, there's source, and it works. We use it here regularly for conference calls with other institutions in the UK and the US.
You do not understand. It is difficult to compete because we cannot provide our services on an equal footing with Microsoft because they won't tell us how to interoperate with their systems. If we can't interoperate with MS systems, and everyone else is using MS systems, then open source options aren't really viable, are they?
(Well, in some cases we are viable -- but only because MS wasn't able to stop all the open standards. Look where all of the major open-source successes have been:
If you substituted ``Microsoft`` with ``Big Tobacco``, would you change your mind?
You're missing the fact that people have been locked into using MS-only systems and *even if they wanted to* would find it very hard to stop. Think about it: they, in effect, provide a significant proportion of our computing infrastructure -- and are preventing anyone from competing with them by not disclosing the vital inferface information about the systems they built that others would need to compete.
They work very hard to maintain the monopoly stranglehold they have created. They bombard the young and impressionable with advertising in print, on television, on billboards. They push ``cheap`` versions of their product on impressional students in schools and universities.
They lobby govenments around the world to say "You should let project leaders make their own choice!" when it comes to choosing between a MS or OSS deployment -- whilst simultaneously doing their utmost to prevent any OSS option from becoming viable.
"Just educate people to do something else" you say. If only it were that easy. To stop smoking is a painful and difficult task at the best of times; divorcing yourself of the MS infrastructure that entangles everything we do is no different.
Microsoft has a monopoly. Nobody disputes that fact. They are using their monopoly position to extend their influence and take control of new markets. This is also not in dispute.
If the United States refuses to take substantive action, then that's their choice. But you're starting to hurt *us* now, we will not stand idly by. The EU, our representatives, have asked Microsoft nicely, patiently, to cease their damaging practices. Three times, they told them stop! And yet they persist, relentlessly.
Well, no more. We're done asking.
Hmm, an infinite loop.
If you ran it on a linux box, it should complete within about 5 seconds or so..
Well, the reports simply state that, in the 360 files they checked (most of them header files) they found 29 cases of a potential NULL pointer dereference and 2 potentially uninitialized variables. This is from the Apache 2.1 codebase as of 31st Jan this year, about 58k lines of code.
Their automated checker also searched for out-of-bounds array accesses, memory leaks, and bad deallocations. It found none.
They also state that they ran the same checks against other codebases, and found that they did marginally better, on average.
In short, this report says that OLD development code for an unreleased opensource project is nearly as good as current commercial offerings. That's at best, when you consider the huge gamut of possible defects that this checker won't pick up. That margin probably disappears in the +/- of the sampling if you were to do a proper statistical analysis.
The report is fairly useless. It certainly should not be taken as a reason to not trust Apache; to do so would be foolhardy particularly given Apache's track record.
Oh, and Reasoning's webserver is being pounded into the ground. You can get my local copy of the reports from here.
The above link wants your email address. Bah.
The direct URLs for the reports are:
Defect Report
Metric Report
Umm, Apache 2.1 hasn't been released yet. Current latest stable is 2.0.46.
I can only assume that they're looking through the current DEVELOPMENT codebase -- finding a higher ``defect density'' in such a development codebase compared with commercial offerings is not exactly unexpected.
They're also some automated code inspection product; the press release doesn't go into details as to the severity of the defects found or the testing methodology.
It'll be necessary to read through the full report before drawing any sound conclusions.
Bear in mind that this a transcript of what Linus said; it has been coerced into written form. It probably sounded a lot more readable when it was spoken.