Desktop users may like the pre-emption patch
on
Linux Kernel 2.4.10
·
· Score: 5, Interesting
Those of you who use Linux as a desktop may be interested in the pre-emptible kernel patch for 2.4.10, available from here.
This patch allows the rescheduling of in-flight kernel syscalls if a higher-priority process than the process calling the syscalls becomes eligible to run.
What it means in practice for the typical desktop user is a major enhancement to interactive performance under Linux, especially when under heavy load. Your X pointer will never freeze with this patch. Using this patch, I have played skip-free mp3's whilst my system has had a loadavg of 20, and my KDE desktop was still usable. I could never hope to achieve this with ordinary Linux. It's a really impressive bit of work. Go try it out.
Of course, people with the need for proper real-time response out of Linux (musicians, for example) will love it even more... maximum latencies for me with this patch are under 4ms - again, very impressive.
It's slated for inclusion in the mainline kernel early in 2.5, but could do with lots of testing first... you know what to do.
The VM has been totally rewritten by Andrea Arcangeli using his idea of 'classzone' balancing, and was merged in at 2.4.10-pre11.
I've been using 2.4.10-pre13 for a couple of days and... it's AMAZING! All your swap problems will disappear, and for me at least, the VM system is ~3x faster than any 2.4 kernel before it, adn faster than any 2.2 kernel as well by some distance.
Go get it whilst it's hot! No longer must we look enviously at FreeBSD!
I think the major technical stumbling block to allowing applets or scripting in any language is finding a language-neutral way of restricting execution along the lines of Java's security model.
That's a really hard thing to achieve correctly - and if you don't get it right then your browser is swiss-cheese. Even harder is to get it right, cross-platform. Under a *NIX you could run whatever external code in a chroot environment to stop it from messing with any of your files... but what's to stop the code DoS'ing you by opening thousands of windows?
Individual languages have their own security models and restricted execution environments (Python has the Bastion module for instance) but it would be a veritable Tower of Babel trying to support every security model that every language implements (and of course, many languages don't even have the concept).
You could create a standard security model that is implemented through a very restricted set of APIs that are all that's exposed to foreign code, and attempt to disallow any other access (a la COM) but experience with COM tells us that this is not really tremendously secure at all without a generally more robust security model in the OS. You could achieve it using the Linux capabilities model and it would be secure, but then it would be impossible to implement cross-platform, and you'd probably still have to extend capabilities further in order to prevent external code from DoS'ing you with new windows.
All in all, it's just too fraught with difficulties to really make it worthwhile.
Then there's the question of support - implement a fantastic new security model that allows you to run any language within a completely foolproof sandbox, great. Now, how many IE/Windows users will download your plugin? How many of them have Perl or Python installed? I'd put the number at something approaching zero, and with 80%+ or whatever of the browser market being IE these days, I can't see this ever taking off, even if it became a standard feature in every other browser on the planet.
Maybe it could work on an intranet, where everything is secure and controlled. But in an environment like that, you're probably better off writing a simple browser plugin that's installed on every machine anyway rather than having the machine download and then execute the code.
On the open internet, I think it would probably be either a complete non-event or a security disaster.
To top it all off, the kernel tarball has a 7.6M core dump from "netscape-commun" in it.
Give them a break. In today's tech climate, even the big, rich guys are having difficulties with funding. God knows how difficult it must be to be a tiny little, previously unheard-of startup trying to get into a fiercely competitive market (and yes, the PDA market is really very cut-throat these days).
As for the core dump in the tarball... heck, even Linus and Alan have made that or similar mistakes in the past. In fact, as recently as 2.4.9-ac10 there were a couple of weird extraneous files in Alan's kernel. At least they are actually releasing the source as they should be...
Distributed computing? Automatically deciding if a program should run locally or on a remote machine? Fault-tolerance? Dynamic load-balancing? Resource controls? Near-infinite scalability?
Sorry Microsoft, but you're the one playing catch-up here. Linux already has, working, today, 98% of your vision.
Frankly it's the most jaw-dropping bit of Linux development I've ever seen. On a local network, create your own supercomputer out of idle workstations. Across the internet - well,.NET should go hang its head in shame. As a programmer, all you have to do is write ordinary, threaded applications, and magically benefit from the processing power of tens, hundreds, even thousands of machines. MOSIX does all the hard stuff.
Truly an amazing piece of work.
You've plainly not tried recently
on
Linux on the Desktop
·
· Score: 3, Insightful
What about printing? Did he test with all the printer types in his office? If he is 100% Postscript that he has some chance, but if there are any low-end Epson color printers, his users could be in for a big surprise.
You chose utterly the wrong argument here. I have an Epson Stylus Photo 1290 and previously had an Epson Stylus Color 850, and the GIMP-Print drivers for these have totally blown me away - the output I get from them is simply stunning, and considerably better than the official Windows drivers. They also support every feature and resolution of my Stylus Photo, even doing colour matching using Postscript.
Also, they don't crash, unlike the Win2k drivers...
Better yet, I'm using these drivers with CUPS as the print spooler and the KDE2.2 print framework. Using this combination, it is just as easy to add, manage and remove printers as it is under Windows. In fact, for networked printers, it is even easier, as I can also configure CUPS through a web browser from anywhere. The print dialog in KDE apps is fully comprehensive, easily customizable by each app and supports things that Windows doesn't - for instance, post-processing of print data through arbitrary commands, which means every print driver has the capability to print multiple pages per sheet, and every app can print straight to a PDF file. Truly, it is a joy to use. I haven't seen a comparable print framework anywhere else.
Remember, last time Netscape found itself in a war, their product went from the really rather good Netscape 3.0 to errr... Confusicator 4.0. Only since they basically admitted defeat did Mozilla start getting reasonable again.
Hey, maybe whoever suggested the relicensing is a TrollTech saboteur? I mean, Konqueror and Opera both use Qt, and Qt already has like 3 licenses. Makes sense, doesn't it?
Mmmm, on second thoughts, maybe I should leave those toadstools in the garden alone in future...
I can give you a quick run down of the basic differences, at least wrt to Linux vs. FreeBSD - the other BSD's have a slightly different set of pros and cons but are largely similar to FreeBSD:
Licensing - FreeBSD uses the BSD license for its core, which allows incorporation of the code into proprietary, binary-only products. The Linux core components use the GPL or LGPL licenses, which disallow such incorporation.
Distribution and development - the FreeBSD core is developed and distributed as a complete OS. There is only a single FreeBSD distro, and it comes straight from the FreeBSD team. Linux is developed piecemeal by lots of different groups - the kernel group is quite separate from the libc group, which is quite separate from the group that develops the standard command-line utilities. With Linux, it is up to each individual distributor (of which there are many) to integrate all the various pieces into a coherent OS.
Maturity - the BSDs have a history that goes all the way back to the 70's, and in some places it shows - notably in the virtual memory subsystem, which takes a long time and a lot of fiddling and testing to get right. Currently the FreeBSD VM system is much better than that in Linux. However, Linux gets a lot more active development due to its popularity. Only two or three years ago, Linux was far behind FreeBSD in terms of its TCP/IP stack. Things change very fast in the Linux world however, and it is arguable that Linux 2.4 now equals or surpasses FreeBSD in this department.
SMP scalability - this is an area that FreeBSD is working on heavily, but currently Linux is far in the lead with this, scaling well up to 8 processors, whilst FreeBSD does relatively poorly even with just 2 processors. This will change when FreeBSD 5.0 is released, which incorporates much of the very good BSDi SMP code.
Packaging systems, ports vs. apt - the BSD ports tree is an exceptionally powerful way of automatically distibuting and updating software, far in advance of anything commercially available. Debian's (and now Conectiva's and Mandrake's) apt system rivals or surpasses it, but it is not standard in all Linux distros. Plus, in Linux, there is still a great divide over which back-end packaging system to use - either RPM or deb, and the overall layout of the filesystem, which, despite standardization efforts, still varies from distro to distro.
Portability - Linux has been ported to just about every architecture you could think of, and can be used on everything from a wristwatch all the way up to a big IBM mainframe. FreeBSD has... not, preferring to concentrate almost entirely on the Intel architecture. NetBSD rivals or surpasses Linux in terms of its portability, but is quite distinct from FreeBSD and has its own set of pros and cons in other areas.
Ease of installation - the commercial Linux distributors have it here. With some, it is as simple as powering up, inserting a CD, and getting a fully-working desktop or server system 20 minutes later. FreeBSD requires a significant amount more work to install it. However, this is no more difficult than the noncommercial Linux distros (Debian or Slackware).
Well, that's just a quick list off the top of my head, anyone care to add more?
The IA-64 port of Linux was mostly developed by.... Intel and HP, not too surprising given that Intel and HP are the people behind the IA-64 and Linux support is crucial for new architectures these days, especially in the server market that IA-64 is targetting.
Of course, they could have been talking about HP-UX on IA-64, but be honest, I don't see HP-UX going anywhere but gradually downhill.
But I don't see anything that the Qt Palmtop Environment doesn't do already, and with similar style and panache.
Not to mention that QPE has a web-browser available FAR in advance of anything on any other handheld platform - Konqueror/embedded which has the full KHTML rendering engine that normal desktop Konqueror has, but with a UI optimized for a handheld's screen.
Of course, I shouldn't have to mention that both QPE and Konq/e are fully-fledged GPL'ed projects, which I'm pretty sure QNX isn't, last time I looked...
This is not flamebait, Slashdot, this is what happened to me. I realize it's not a pretty story, but there you go. It wasn't a pretty time for me either.
Perhaps I should stress that I do not blame the games. I know from experiences elsewhere in my life that I am prone to addiction. I smoke. I have, in the past, drunk too much regularly. I find bad habits easy to pick up. I don't want restrictions on games either - to do so would restrict people's liberties for the sake of a few for whom it might turn into a problem. It hasn't worked on drink or drugs, so I don't think it would be any use here either.
But that still doesn't change the fact that I ended up genuinely hooked, to the severe detriment of the rest of my life, on computer games. The sooner that people realize that computer gaming is both addictive and potentially destructive for some, the better. Once people have realized that, then strides can be made towards harm reduction and everyone can go about their gaming without fear of it taking over their lives.
I've been playing computer games on and off since I was 4 (the first game I got really badly hooked on was Joust on my Atari 2600, back in 1984 or therabouts), so I like to think I'm reasonably well qualified to comment. I grew up with computer games all around me, first with my Ataris (2600 & 400), through Amigas (an A500 and an A1200) and far too many hours spent in arcades, and then into the PC world.
Do you know what? I really do think, looking back on it now, that computer games stunted my emotional and intellectual growth. Not because of anything insidious about the games themselves, not that they were necessarily ultra-violent (be fair, realistic ultra-violence in computer games has only been around since Doom or maybe Wolfenstein - certainly Doom was the first game that made me twitch uneasily when I shot someone), but because they were an addiction. Even when I didn't feel addicted, it was something I could easily slide into, and completely forget about more important things that I had to do. Much more effective at that than TV, because a good computer game involves your brain completely. TV programs just don't do that, no matter how good they are.
Case in point: I started learning to play the piano when I was 4. I made good progress to begin with, I didn't have much in the of distraction. It wasn't long, however, until I would find myself playing computer games instead, rather than practising my piano. Eventually, aged 8, my piano teacher gave up on me because I was making no progress at all. I rue that day now. To me, being able to play a musical instrument would be a far more useful skill to have than being able to set high scores (not that I could much even at the height of my gaming skills - I was always crap, despite my addiction - indeed, perhaps that's what fed it).
Case in point 2: girls and social skills. When everyone else was learning how to interact with each other, I was.... inside learning how to shoot stuff in Xenon II. When, aged 11, 12, 13, they were learning about the opposite sex, I was... inside learning how to play Civilisation. Now, I wasn't completely unaware of girls at the time - hormones start flowing around that age and there's nothing you can do about it. But because I was no good at interacting with people, hormonal urges turned into frustration, and frustration turned into anger. For me, that anger turned into anger at myself and self-hate, leading to a spiral of low self-esteem and depression that I have struggled to get out of ever since. I can understand how for some people that turns into outward violence, they just deal with the same problem in a different way. I don't think it's the games themselves that turn people violent, but the reaction to feeling excluded because they have been playing games instead of interacting with other humans.
Case in point 3: exams and university. I dropped out of uni because of games. Whilst everyone was going to lectures and tutorials, I was.... at home learning how to play Quake and Descent. I would beat myself up about not going in that day, but the feelings only lasted as long as it took to fire up Quake and start getting involved. Once I had done that, I was just too absorbed to remember what I ought to have been doing. Somehow I managed to struggle through my first year (my uni wasn't at all strict about people turning up) but it came to the end-of-year exams and... well inevitably I didn't get the marks. Out I went. That was the final straw for me. I descended into a living hell of depression and apathy for a year, but eventually I began to sort myself out. That year was also the year I realized where one of my biggest problems was - and I finally gave up serious gaming for good.
I don't think I'd mind so much if I actually learnt something about computers whilst gaming - but you don't. You learn what computer you should have, you get hold of it, you learn to boot it and you learn how to load a game. That's it. My computer knowledge only started really advancing past the 'point, click, play' stage once I gave up gaming. The fact that it develops hand/eye co-ordination is all very well, but there are plenty of other activities that develop those skills too, and don't involve cutting yourself off from humanity. Maybe a few hardcore gamers will go on to write their own games... but what about the 99% who don't?
I realise it's probably not very politically correct on Slashdot to point out some of the human and social problems with some types of computing, but that's the way it is. Computer gaming can easily lead to addiction (the games are designed to be addictive!), and unchecked, any addiction is very hazardous. The fact that it's an addiction that affects kids and teenagers more than anyone else, people who are at crucial points of social and intellectual development, only makes it all the more insidious.
A CGI written in C is almost certainly vastly slower than simiar code writen as a Java servlet. Deal with it.
Unless you use FastCGI (supported by Apache with mod_fastcgi)... an extension to the CGI spec that, amongst other things, allows persistent processes. Being a simple extension to CGI, it's also completely language-agnostic and cares not whether you use threading, or, for the real gurus and speed demons, asynchronous programming.
Of course, if you want to lock yourself in to a vendor-controlled, language-specific server-side architecture, that's your business. Why limit yourself though?
Actually, it's [DX8 API] devised by several companies that make chipsets, who Microsoft works with closely to ensure that (a) desired, and (b) feasible.
So how do you explain the fact that the DX8 pixel shading API doesn't support everything the GeForce3 does? Surely if Microsoft had really worked that closely with NVidia there would not be this difference?
Or perhaps Microsoft dumbed down the API to only support what it thought would be common features to all procedural pixel shaders?
Either way, it sure doesn't sound like NVidia designed it.
Remember, no matter who is involved with Direct3D, in the end, the only entity actually controlling it is Microsoft. They have the last word on what goes in and what stays out. They're the people who write and distribute the code that forms the DX8 APIs. If they don't like it, you don't get to use it.
With OpenGL, the people with the real power are the developers of end-user software. It's them who get to decide what vendor extensions to take or leave, not Microsoft. Further down the line, once an extension becomes popular... well, every OpenGL ARB member has the same rights as every other regarding choosing what becomes part of the standard spec.
I thought most of us had decided that governance by consensus amongst equals was superior to dictatorship?
If you go with OpenGL you have to write your program for each different vendor extension that comes out. Honestly, what are the chances of ATI or PowerVR ever supporting NV_texture_shader or NV_texture_shader2?
I'd put the chances quite high if it's a decent spec. Perhaps it might not be called NV_texture_shader in a year's time, it'll be ARB_texture_shader, and as an ARB-mandated extension will end up being supported by every sane driver with the required hardware support. You can bet that the NVidia drivers will still support the old NV_texture_shader as well though.
This is the way the OpenGL spec grows. Manufacturers are free to go ahead and implement whatever features they'd like or need in OpenGL, and they implement them as vendor-specific extensions. If someone else needs that functionality for their driver, well, before you know it the vendor-specific extension will become ARB-mandated, and probably pored over and refined a little by all the OpenGL board in the process - a board which consists of all the major 3D hardware and software manufacturers. Shortly after, most drivers will support that. Eventually the ARB extensions will probably be integrated into the next OpenGL base spec, as just happened with OpenGL 1.3.
So, there's no one single vendor controlling the spec. 3D vendors can be as creative as they want. Only if a feature becomes used on several different 3D architectures does it become a standard. Your code will continue to run fine on architectures where you used the vendor-specific extensions, as the vendor will almost certainly keep the original functionality around indefinitely as well as supporting the ARB-mandated version of it. If you want, you can go back a little later and use the ARB extension instead in your code, and the functionality becomes available to everyone.
By using DX8 instead of OpenGL you know that effects designed for the NVidia pixel shader will magically just work on the next-generation Radeons. At the same time, you're handing over control of the whole API to Microsoft, which does not make 3D chipsets, and you're stuck with their idea of how the pixel shader ought to work, as opposed to an API for it designed by the company that makes the chipsets, and then later (if it's successful), reviewed and revised by everyone important in the industry. I won't even start on the cross-platform issues.
I don't think there are any un-patented 5.1 channel codecs around.
Actually, if you look at the last answer on the Vorbis FAQ you'll see that Ogg Vorbis already supports encoding of up to 255 channels per stream, so, theoretically at least, it ought to be a cinch to use Vorbis for 5.1 audio.
This could be a real opportunity for Ogg to become the first mainstream audio codec to support 5.1 explicitly. It would be a real leg-up for Ogg's chances if it gets accepted as the choice of audiophiles, and having 5.1 supported before MP3 and WMA can only help with that. Those who have experimented with DVD Audio would finally have a format worth considering for ripping purposes, and it helps that Vorbis sounds very musical.
Ew! You play your music off a 16 bit Sound Blaster? Those things have the WORST transient signals I have ever heard come out of a DAC! All the gold coated cables in the world won't eliminate the hiss from your fans and the snap every time the memory bus is called!
Actually the AWE64Gold (which is what he will have if the card has gold-plated connecters) isn't too bad, a lot of work was done on the card to shield the DACs and reduce some of the SB16's interference problems - I measured my old AWE64Gold's noise floor at a respectable (but not great) -77dB, unweighted. The converters are also reasonably musical sounding, but tail off a bit at the edges of their frequency range - the sub-100Hz bass is a bit incoherent and the high-end is a little muffled.
However, if you don't fancy the onboard converters... it already has an S/PDIF out, so no need to upgrade the hardware. I eventually found a use for my old portable DCC recorder (yes, I was one of the suckers that bought one back in 1996;) as an external DAC for my AWE64Gold, and it sounds superb - the Philips Bitstream DACs on the DCC are really sweet, easily worth the asking price for the DCC alone.
Or at least, that's how I thought the distinction went.
No, both the running-Linux-as-a-process and kernel pre-emption techniques offer the same 'hard' real-time guarantees of scheduling latency. Obviously, they differ in their approach.
The Linux-as-a-process technique that Yodaiken has patented is both simpler to understand and implement. A small, new real-time kernel (the RTLinux kernel) runs the standard Linux kernel as a normal process. Real-time applications are written for the RTLinux kernel (there is a thunking layer which allows Linux processes to use RTLinux syscalls), and when a realtime application needs to service an event, the RTLinux kernel can interrupt Linux and schedule the realtime application instead. The major downside of this approach is that calling RTLinux syscalls from a Linux application involves this thunking layer, which is by its nature, somewhat costly and slow. It also means realtime programmers have an extra API to worry about.
The pre-emptible kernel approach, on the other hand, does away with an external kernel, by making the Linux scheduler itself able to interrupt and reschedule kernel code as well as the normal userspace code. If an event arrives that must be serviced within a certain timeframe, then the Linux scheduler simply stops whatever else the Linux kernel is doing and services the request. This is a much harder approach to get right, especially as it involves some significant redesign of the way kernel-space code is treated. However, ultimately, I think it is the more elegant solution, and it means that there need not be a thunking layer or extra API - existing realtime applications suddenly become able to do 'hard' realtime.
Note that 'hard' realtime is not necessarily about responding to events quickly, but merely that these events can be dealt with in a guaranteed time frame, which could range from microseconds to seconds. In practice, 'hard' realtime does usually mean fast however. 'Soft' realtime scheduling, such as what the standard Linux kernel offers, makes a best-effort attempt to reduce scheduling latency to a minimum, but does not provide a guarantee that an event will be dealt with within a certain time. In 'soft' realtime, a realtime event is ignored until any kernel code that is currently running reaches its next instruction to deliberately yield - rather like the way userspace code is treated under a co-operative multitasking OS.
Perhaps you were getting confused with the low-latency patches for the Linux kernel? These attempt to reduce realtime scheduling latency in the Linux kernel by adding extra points where the currently-running code is told to yield back to the scheduler (and also by tweaking some of the kernel algorithms). However, this does not mean that the scheduler can interrupt kernel code. Thus it represents merely an improvement on Linux's normal 'soft' realtime scheduling and not 'hard' realtime at all.
The problem is the PS2 has only a 294 MHz CPU and very high-latency RAMBUS RAM, so portable emulators will not run well on it.
My old Cyrix 166-based PC had a lot less processor power than the PS2, much slower memory (remember 70ns FPM DRAM?) and less of it (only 16MB), quite apart from the fact that it had a video card that is prehistoric by comparison (an S3 Virge).
Yet it played ~95% of all MAME games absolutely flawlessly, at full speed.
Portable != Slow, as anyone who has used Linux on a MIPS box will tell you (it runs rings around the MIPS-only IRIX)
You're not an assembler guru that's feeling hard done by optimizing compilers are you?
If these attacks used spoofed IP packets, there would be no easy defense.
Except for if every damn net admin would WAKE UP and SMELL THE COFFEE and IMPLEMENT EGRESS FILTERING or SOURCE ROUTE VERIFICATION or whatever your router calls it.
If you have a router built within the last 5 years, I can pretty much guarantee you it supports it. So turn it on already!
If every border router on the internet used it, we could stamp out IP address spoofing overnight. No magic about it. All the border router has to do is check that the source address of the packet is within the range of addresses that it 'owns'. If it isn't, drop it, and log the MAC address so that it can be traced.
Easy huh? Any router worth its salt can do it, so...
That's a bit disingenuous. JavasCrypt is enabled by default in all graphical browsers.
Actually that's not quite true. Konqueror very deliberately keeps JavaScript, Java and Netscape plugins off by default. If you need them, then it's a cinch to enable them (very obvious in the Konqui settings dialog, or, if you have the extra plugins that are in the kdenonbeta package, it's even simpler, select a menu item or a toolbar button).
If you're concerned about turning JavaScript on globally, then you can enable/disable JavaScript (and Java) on a per-site basis.
Sigh... If only every graphical browser put security first...
I don't recall which Intel executive (one of the chief architects of the Pentium IV architecture) it was that lead to this common misconception, but he later refuted that this was what he meant.
This isn't a common misconception... it is, in essence, true.
The P4, as it stands today, has very small on-chip caches, certainly by comparison with, say, the Athlon, and the primary reason why that is is because of memory latency. Smaller caches have lower access latencies, mitigating the effects of RDRAM's high access latency. RDRAM also has very high bandwidth, significantly higher than even DDR SDRAM, which means that keeping these small caches filled is less of a problem.
Consider also the very long, 20-stage pipelines found in the P4. These also require very large memory bandwidth to keep them filled, and what memory technology does that better than RDRAM? Conversely, a branch-prediction miss by the P4 takes a long time to work its way through this 20-stage pipeline before the P4 can restart its work. This gives RDRAM breathing space to refill the P4's small caches from elsewhere in memory that it would not have if the P4's pipeline was shorter.
Cynics might argue that perhaps the P4's branch-prediction isn't as good as it could be, in order to make up for some of the access latency that RDRAM suffers from...
Don't forget the benchmarks either: where does the P4 really shine, and convincingly beat the Athlon? That'll be benchmarks where the data set that is being processed is large and (mostly) sequential. Why? Well, it's obvious, isn't it? It's down to RDRAM's massive bandwidth. Other tests which do not hammer the memory bandwidth as hard, or where the data set is scattered around memory, show the Athlon coming out on top.
All of this points to the fact that the P4 was at least designed with RDRAM in mind. If not specifically for RDRAM, then at least for a memory technology with large bandwidth and high latency, and how many types of memory do we know that fit that description?
I suspect that future revs of the P4, designed to work better with DDR SDRAM, will have larger on-chip caches, and (possibly) better branch prediction. The larger L1 and/or L2 caches will be necessary in order for the P4 to have competitive performance when using SDRAM. However, this will come at a price - a lot more transistors on the die. More transistors == larger die size, higher power requirements, and, worst of all for Intel, means that they will not be able to scale the clock speed up as fast as they would like to, which leaves me wondering whether they will genuinely be able to keep up with the Athlon in terms of performance.
Just a nit-pick, but actually both the UK and France have well-known submarine-launched ICBM capabilities. Indeed, the UK system is Trident, which is exactly the same as the US sub-launched ICBMs. The warhead/MIRV design is different, but of roughly equivalent capabilities, accuracy and megatonnage (up to 500 kilotonnes per warhead). The French system is entirely of their own design but again, has similar capabilities, payload and range.
But still, your point holds - it seems unlikely that any country would launch an ICBM-based nuclear attack against the US - to do so would mean complete annihilation for that country. Indeed, the only country capable these days of launching a crippling nuclear strike against the US would be the US itself - no other country has the weight of numbers of nuclear devices to be able to effectively knock out most of the US ICBM's...
You cannot pick up a phone and call a responsible person. You have no second avenue to contact a person, say, if someone was forging their domain name. If someone from your domain is spamming and blocking traffic, you cannot be easily contacted to do the right thing.
Except that you do have all these avenues still available to you, because that information is available via RIPE. If you have a problem, find the IP of the host that is causing the problem, look it up, see who owns the netblock, contact them instead, let them deal with it - it's their responsibility.
Now, should detailed contact info be available for the IP registries through WHOIS lookup? I think so, and this is why:
The way it's setup assumes that the owners of netblocks allocated by RIPE are significantly-sized Internet-savvy bodies with their own technical staff, who do not mind being easily-contactable. I think that's a reasonable assumption to make. How many of you own your own personal netblocks?
Now, how many of you own your own personal domain? How many of your non-technical friends own a personal domain?
See the difference? Domains have a very large public ownership. Netblocks do not.
It seems eminently sensible to me that only the contact information that is actually required for the Internet to function should be available via WHOIS, whilst maximizing personal privacy for those who have no day-to-day bearing on the running of the Internet.
Slashdot Mirror
Those of you who use Linux as a desktop may be interested in the pre-emptible kernel patch for 2.4.10, available from here.
This patch allows the rescheduling of in-flight kernel syscalls if a higher-priority process than the process calling the syscalls becomes eligible to run.
What it means in practice for the typical desktop user is a major enhancement to interactive performance under Linux, especially when under heavy load. Your X pointer will never freeze with this patch. Using this patch, I have played skip-free mp3's whilst my system has had a loadavg of 20, and my KDE desktop was still usable. I could never hope to achieve this with ordinary Linux. It's a really impressive bit of work. Go try it out.
Of course, people with the need for proper real-time response out of Linux (musicians, for example) will love it even more... maximum latencies for me with this patch are under 4ms - again, very impressive.
It's slated for inclusion in the mainline kernel early in 2.5, but could do with lots of testing first... you know what to do.
The VM has been totally rewritten by Andrea Arcangeli using his idea of 'classzone' balancing, and was merged in at 2.4.10-pre11.
I've been using 2.4.10-pre13 for a couple of days and... it's AMAZING! All your swap problems will disappear, and for me at least, the VM system is ~3x faster than any 2.4 kernel before it, adn faster than any 2.2 kernel as well by some distance.
Go get it whilst it's hot! No longer must we look enviously at FreeBSD!
I think the major technical stumbling block to allowing applets or scripting in any language is finding a language-neutral way of restricting execution along the lines of Java's security model.
That's a really hard thing to achieve correctly - and if you don't get it right then your browser is swiss-cheese. Even harder is to get it right, cross-platform. Under a *NIX you could run whatever external code in a chroot environment to stop it from messing with any of your files... but what's to stop the code DoS'ing you by opening thousands of windows?
Individual languages have their own security models and restricted execution environments (Python has the Bastion module for instance) but it would be a veritable Tower of Babel trying to support every security model that every language implements (and of course, many languages don't even have the concept).
You could create a standard security model that is implemented through a very restricted set of APIs that are all that's exposed to foreign code, and attempt to disallow any other access (a la COM) but experience with COM tells us that this is not really tremendously secure at all without a generally more robust security model in the OS. You could achieve it using the Linux capabilities model and it would be secure, but then it would be impossible to implement cross-platform, and you'd probably still have to extend capabilities further in order to prevent external code from DoS'ing you with new windows.
All in all, it's just too fraught with difficulties to really make it worthwhile.
Then there's the question of support - implement a fantastic new security model that allows you to run any language within a completely foolproof sandbox, great. Now, how many IE/Windows users will download your plugin? How many of them have Perl or Python installed? I'd put the number at something approaching zero, and with 80%+ or whatever of the browser market being IE these days, I can't see this ever taking off, even if it became a standard feature in every other browser on the planet.
Maybe it could work on an intranet, where everything is secure and controlled. But in an environment like that, you're probably better off writing a simple browser plugin that's installed on every machine anyway rather than having the machine download and then execute the code.
On the open internet, I think it would probably be either a complete non-event or a security disaster.
To top it all off, the kernel tarball has a 7.6M core dump from "netscape-commun" in it.
Give them a break. In today's tech climate, even the big, rich guys are having difficulties with funding. God knows how difficult it must be to be a tiny little, previously unheard-of startup trying to get into a fiercely competitive market (and yes, the PDA market is really very cut-throat these days).
As for the core dump in the tarball... heck, even Linus and Alan have made that or similar mistakes in the past. In fact, as recently as 2.4.9-ac10 there were a couple of weird extraneous files in Alan's kernel. At least they are actually releasing the source as they should be...
Distributed computing? Automatically deciding if a program should run locally or on a remote machine? Fault-tolerance? Dynamic load-balancing? Resource controls? Near-infinite scalability?
Sorry Microsoft, but you're the one playing catch-up here. Linux already has, working, today, 98% of your vision.
It's called MOSIX.
Frankly it's the most jaw-dropping bit of Linux development I've ever seen. On a local network, create your own supercomputer out of idle workstations. Across the internet - well, .NET should go hang its head in shame. As a programmer, all you have to do is write ordinary, threaded applications, and magically benefit from the processing power of tens, hundreds, even thousands of machines. MOSIX does all the hard stuff.
Truly an amazing piece of work.
What about printing? Did he test with all the printer types in his office? If he is 100% Postscript that he has some chance, but if there are any low-end Epson color printers, his users could be in for a big surprise.
You chose utterly the wrong argument here. I have an Epson Stylus Photo 1290 and previously had an Epson Stylus Color 850, and the GIMP-Print drivers for these have totally blown me away - the output I get from them is simply stunning, and considerably better than the official Windows drivers. They also support every feature and resolution of my Stylus Photo, even doing colour matching using Postscript.
Also, they don't crash, unlike the Win2k drivers...
Better yet, I'm using these drivers with CUPS as the print spooler and the KDE2.2 print framework. Using this combination, it is just as easy to add, manage and remove printers as it is under Windows. In fact, for networked printers, it is even easier, as I can also configure CUPS through a web browser from anywhere. The print dialog in KDE apps is fully comprehensive, easily customizable by each app and supports things that Windows doesn't - for instance, post-processing of print data through arbitrary commands, which means every print driver has the capability to print multiple pages per sheet, and every app can print straight to a PDF file. Truly, it is a joy to use. I haven't seen a comparable print framework anywhere else.
For more information, check out the GIMP-Print, CUPS and KDE Print framework websites.
Printing under Linux has finally come of age - and it is better than Windows!
Not sure this is a good idea for Mozilla.
Remember, last time Netscape found itself in a war, their product went from the really rather good Netscape 3.0 to errr... Confusicator 4.0. Only since they basically admitted defeat did Mozilla start getting reasonable again.
Hey, maybe whoever suggested the relicensing is a TrollTech saboteur? I mean, Konqueror and Opera both use Qt, and Qt already has like 3 licenses. Makes sense, doesn't it?
Mmmm, on second thoughts, maybe I should leave those toadstools in the garden alone in future...
I can give you a quick run down of the basic differences, at least wrt to Linux vs. FreeBSD - the other BSD's have a slightly different set of pros and cons but are largely similar to FreeBSD:
Well, that's just a quick list off the top of my head, anyone care to add more?
Linux? "developed by Intel and Hewlett-Packard"?
I'm still confused
The IA-64 port of Linux was mostly developed by.... Intel and HP, not too surprising given that Intel and HP are the people behind the IA-64 and Linux support is crucial for new architectures these days, especially in the server market that IA-64 is targetting.
Of course, they could have been talking about HP-UX on IA-64, but be honest, I don't see HP-UX going anywhere but gradually downhill.
QNX on iPAQ looks sweet...
But I don't see anything that the Qt Palmtop Environment doesn't do already, and with similar style and panache.
Not to mention that QPE has a web-browser available FAR in advance of anything on any other handheld platform - Konqueror/embedded which has the full KHTML rendering engine that normal desktop Konqueror has, but with a UI optimized for a handheld's screen.
Of course, I shouldn't have to mention that both QPE and Konq/e are fully-fledged GPL'ed projects, which I'm pretty sure QNX isn't, last time I looked...
This is not flamebait, Slashdot, this is what happened to me. I realize it's not a pretty story, but there you go. It wasn't a pretty time for me either.
Perhaps I should stress that I do not blame the games. I know from experiences elsewhere in my life that I am prone to addiction. I smoke. I have, in the past, drunk too much regularly. I find bad habits easy to pick up. I don't want restrictions on games either - to do so would restrict people's liberties for the sake of a few for whom it might turn into a problem. It hasn't worked on drink or drugs, so I don't think it would be any use here either.
But that still doesn't change the fact that I ended up genuinely hooked, to the severe detriment of the rest of my life, on computer games. The sooner that people realize that computer gaming is both addictive and potentially destructive for some, the better. Once people have realized that, then strides can be made towards harm reduction and everyone can go about their gaming without fear of it taking over their lives.
I've been playing computer games on and off since I was 4 (the first game I got really badly hooked on was Joust on my Atari 2600, back in 1984 or therabouts), so I like to think I'm reasonably well qualified to comment. I grew up with computer games all around me, first with my Ataris (2600 & 400), through Amigas (an A500 and an A1200) and far too many hours spent in arcades, and then into the PC world.
Do you know what? I really do think, looking back on it now, that computer games stunted my emotional and intellectual growth. Not because of anything insidious about the games themselves, not that they were necessarily ultra-violent (be fair, realistic ultra-violence in computer games has only been around since Doom or maybe Wolfenstein - certainly Doom was the first game that made me twitch uneasily when I shot someone), but because they were an addiction. Even when I didn't feel addicted, it was something I could easily slide into, and completely forget about more important things that I had to do. Much more effective at that than TV, because a good computer game involves your brain completely. TV programs just don't do that, no matter how good they are.
Case in point: I started learning to play the piano when I was 4. I made good progress to begin with, I didn't have much in the of distraction. It wasn't long, however, until I would find myself playing computer games instead, rather than practising my piano. Eventually, aged 8, my piano teacher gave up on me because I was making no progress at all. I rue that day now. To me, being able to play a musical instrument would be a far more useful skill to have than being able to set high scores (not that I could much even at the height of my gaming skills - I was always crap, despite my addiction - indeed, perhaps that's what fed it).
Case in point 2: girls and social skills. When everyone else was learning how to interact with each other, I was.... inside learning how to shoot stuff in Xenon II. When, aged 11, 12, 13, they were learning about the opposite sex, I was... inside learning how to play Civilisation. Now, I wasn't completely unaware of girls at the time - hormones start flowing around that age and there's nothing you can do about it. But because I was no good at interacting with people, hormonal urges turned into frustration, and frustration turned into anger. For me, that anger turned into anger at myself and self-hate, leading to a spiral of low self-esteem and depression that I have struggled to get out of ever since. I can understand how for some people that turns into outward violence, they just deal with the same problem in a different way. I don't think it's the games themselves that turn people violent, but the reaction to feeling excluded because they have been playing games instead of interacting with other humans.
Case in point 3: exams and university. I dropped out of uni because of games. Whilst everyone was going to lectures and tutorials, I was.... at home learning how to play Quake and Descent. I would beat myself up about not going in that day, but the feelings only lasted as long as it took to fire up Quake and start getting involved. Once I had done that, I was just too absorbed to remember what I ought to have been doing. Somehow I managed to struggle through my first year (my uni wasn't at all strict about people turning up) but it came to the end-of-year exams and... well inevitably I didn't get the marks. Out I went. That was the final straw for me. I descended into a living hell of depression and apathy for a year, but eventually I began to sort myself out. That year was also the year I realized where one of my biggest problems was - and I finally gave up serious gaming for good.
I don't think I'd mind so much if I actually learnt something about computers whilst gaming - but you don't. You learn what computer you should have, you get hold of it, you learn to boot it and you learn how to load a game. That's it. My computer knowledge only started really advancing past the 'point, click, play' stage once I gave up gaming. The fact that it develops hand/eye co-ordination is all very well, but there are plenty of other activities that develop those skills too, and don't involve cutting yourself off from humanity. Maybe a few hardcore gamers will go on to write their own games... but what about the 99% who don't?
I realise it's probably not very politically correct on Slashdot to point out some of the human and social problems with some types of computing, but that's the way it is. Computer gaming can easily lead to addiction (the games are designed to be addictive!), and unchecked, any addiction is very hazardous. The fact that it's an addiction that affects kids and teenagers more than anyone else, people who are at crucial points of social and intellectual development, only makes it all the more insidious.
A CGI written in C is almost certainly vastly slower than simiar code writen as a Java servlet. Deal with it.
Unless you use FastCGI (supported by Apache with mod_fastcgi)... an extension to the CGI spec that, amongst other things, allows persistent processes. Being a simple extension to CGI, it's also completely language-agnostic and cares not whether you use threading, or, for the real gurus and speed demons, asynchronous programming.
Of course, if you want to lock yourself in to a vendor-controlled, language-specific server-side architecture, that's your business. Why limit yourself though?
Actually, it's [DX8 API] devised by several companies that make chipsets, who Microsoft works with closely to ensure that (a) desired, and (b) feasible.
So how do you explain the fact that the DX8 pixel shading API doesn't support everything the GeForce3 does? Surely if Microsoft had really worked that closely with NVidia there would not be this difference?
Or perhaps Microsoft dumbed down the API to only support what it thought would be common features to all procedural pixel shaders?
Either way, it sure doesn't sound like NVidia designed it.
Remember, no matter who is involved with Direct3D, in the end, the only entity actually controlling it is Microsoft. They have the last word on what goes in and what stays out. They're the people who write and distribute the code that forms the DX8 APIs. If they don't like it, you don't get to use it.
With OpenGL, the people with the real power are the developers of end-user software. It's them who get to decide what vendor extensions to take or leave, not Microsoft. Further down the line, once an extension becomes popular... well, every OpenGL ARB member has the same rights as every other regarding choosing what becomes part of the standard spec.
I thought most of us had decided that governance by consensus amongst equals was superior to dictatorship?
If you go with OpenGL you have to write your program for each different vendor extension that comes out. Honestly, what are the chances of ATI or PowerVR ever supporting NV_texture_shader or NV_texture_shader2?
I'd put the chances quite high if it's a decent spec. Perhaps it might not be called NV_texture_shader in a year's time, it'll be ARB_texture_shader, and as an ARB-mandated extension will end up being supported by every sane driver with the required hardware support. You can bet that the NVidia drivers will still support the old NV_texture_shader as well though.
This is the way the OpenGL spec grows. Manufacturers are free to go ahead and implement whatever features they'd like or need in OpenGL, and they implement them as vendor-specific extensions. If someone else needs that functionality for their driver, well, before you know it the vendor-specific extension will become ARB-mandated, and probably pored over and refined a little by all the OpenGL board in the process - a board which consists of all the major 3D hardware and software manufacturers. Shortly after, most drivers will support that. Eventually the ARB extensions will probably be integrated into the next OpenGL base spec, as just happened with OpenGL 1.3.
So, there's no one single vendor controlling the spec. 3D vendors can be as creative as they want. Only if a feature becomes used on several different 3D architectures does it become a standard. Your code will continue to run fine on architectures where you used the vendor-specific extensions, as the vendor will almost certainly keep the original functionality around indefinitely as well as supporting the ARB-mandated version of it. If you want, you can go back a little later and use the ARB extension instead in your code, and the functionality becomes available to everyone.
By using DX8 instead of OpenGL you know that effects designed for the NVidia pixel shader will magically just work on the next-generation Radeons. At the same time, you're handing over control of the whole API to Microsoft, which does not make 3D chipsets, and you're stuck with their idea of how the pixel shader ought to work, as opposed to an API for it designed by the company that makes the chipsets, and then later (if it's successful), reviewed and revised by everyone important in the industry. I won't even start on the cross-platform issues.
Your choice.
I don't think there are any un-patented 5.1 channel codecs around.
Actually, if you look at the last answer on the Vorbis FAQ you'll see that Ogg Vorbis already supports encoding of up to 255 channels per stream, so, theoretically at least, it ought to be a cinch to use Vorbis for 5.1 audio.
This could be a real opportunity for Ogg to become the first mainstream audio codec to support 5.1 explicitly. It would be a real leg-up for Ogg's chances if it gets accepted as the choice of audiophiles, and having 5.1 supported before MP3 and WMA can only help with that. Those who have experimented with DVD Audio would finally have a format worth considering for ripping purposes, and it helps that Vorbis sounds very musical.
Ew! You play your music off a 16 bit Sound Blaster? Those things have the WORST transient signals I have ever heard come out of a DAC! All the gold coated cables in the world won't eliminate the hiss from your fans and the snap every time the memory bus is called!
Actually the AWE64Gold (which is what he will have if the card has gold-plated connecters) isn't too bad, a lot of work was done on the card to shield the DACs and reduce some of the SB16's interference problems - I measured my old AWE64Gold's noise floor at a respectable (but not great) -77dB, unweighted. The converters are also reasonably musical sounding, but tail off a bit at the edges of their frequency range - the sub-100Hz bass is a bit incoherent and the high-end is a little muffled.
However, if you don't fancy the onboard converters... it already has an S/PDIF out, so no need to upgrade the hardware. I eventually found a use for my old portable DCC recorder (yes, I was one of the suckers that bought one back in 1996 ;) as an external DAC for my AWE64Gold, and it sounds superb - the Philips Bitstream DACs on the DCC are really sweet, easily worth the asking price for the DCC alone.
Or at least, that's how I thought the distinction went.
No, both the running-Linux-as-a-process and kernel pre-emption techniques offer the same 'hard' real-time guarantees of scheduling latency. Obviously, they differ in their approach.
The Linux-as-a-process technique that Yodaiken has patented is both simpler to understand and implement. A small, new real-time kernel (the RTLinux kernel) runs the standard Linux kernel as a normal process. Real-time applications are written for the RTLinux kernel (there is a thunking layer which allows Linux processes to use RTLinux syscalls), and when a realtime application needs to service an event, the RTLinux kernel can interrupt Linux and schedule the realtime application instead. The major downside of this approach is that calling RTLinux syscalls from a Linux application involves this thunking layer, which is by its nature, somewhat costly and slow. It also means realtime programmers have an extra API to worry about.
The pre-emptible kernel approach, on the other hand, does away with an external kernel, by making the Linux scheduler itself able to interrupt and reschedule kernel code as well as the normal userspace code. If an event arrives that must be serviced within a certain timeframe, then the Linux scheduler simply stops whatever else the Linux kernel is doing and services the request. This is a much harder approach to get right, especially as it involves some significant redesign of the way kernel-space code is treated. However, ultimately, I think it is the more elegant solution, and it means that there need not be a thunking layer or extra API - existing realtime applications suddenly become able to do 'hard' realtime.
Note that 'hard' realtime is not necessarily about responding to events quickly, but merely that these events can be dealt with in a guaranteed time frame, which could range from microseconds to seconds. In practice, 'hard' realtime does usually mean fast however. 'Soft' realtime scheduling, such as what the standard Linux kernel offers, makes a best-effort attempt to reduce scheduling latency to a minimum, but does not provide a guarantee that an event will be dealt with within a certain time. In 'soft' realtime, a realtime event is ignored until any kernel code that is currently running reaches its next instruction to deliberately yield - rather like the way userspace code is treated under a co-operative multitasking OS.
Perhaps you were getting confused with the low-latency patches for the Linux kernel? These attempt to reduce realtime scheduling latency in the Linux kernel by adding extra points where the currently-running code is told to yield back to the scheduler (and also by tweaking some of the kernel algorithms). However, this does not mean that the scheduler can interrupt kernel code. Thus it represents merely an improvement on Linux's normal 'soft' realtime scheduling and not 'hard' realtime at all.
Does everything you require, plus a whole bunch more, and it's portable.
Plus it has a sexy case :)
It's perhaps not the cheapest option, but then, you do get a free, very powerful PDA thrown in with your MP3/Vorbis player...
The problem is the PS2 has only a 294 MHz CPU and very high-latency RAMBUS RAM, so portable emulators will not run well on it.
My old Cyrix 166-based PC had a lot less processor power than the PS2, much slower memory (remember 70ns FPM DRAM?) and less of it (only 16MB), quite apart from the fact that it had a video card that is prehistoric by comparison (an S3 Virge).
Yet it played ~95% of all MAME games absolutely flawlessly, at full speed.
Portable != Slow, as anyone who has used Linux on a MIPS box will tell you (it runs rings around the MIPS-only IRIX)
You're not an assembler guru that's feeling hard done by optimizing compilers are you?
If these attacks used spoofed IP packets, there would be no easy defense.
Except for if every damn net admin would WAKE UP and SMELL THE COFFEE and IMPLEMENT EGRESS FILTERING or SOURCE ROUTE VERIFICATION or whatever your router calls it.
If you have a router built within the last 5 years, I can pretty much guarantee you it supports it. So turn it on already!
If every border router on the internet used it, we could stamp out IP address spoofing overnight. No magic about it. All the border router has to do is check that the source address of the packet is within the range of addresses that it 'owns'. If it isn't, drop it, and log the MAC address so that it can be traced.
Easy huh? Any router worth its salt can do it, so...
Please!?!? What does it take to convince you?
That's a bit disingenuous. JavasCrypt is enabled by default in all graphical browsers.
Actually that's not quite true. Konqueror very deliberately keeps JavaScript, Java and Netscape plugins off by default. If you need them, then it's a cinch to enable them (very obvious in the Konqui settings dialog, or, if you have the extra plugins that are in the kdenonbeta package, it's even simpler, select a menu item or a toolbar button).
If you're concerned about turning JavaScript on globally, then you can enable/disable JavaScript (and Java) on a per-site basis.
Sigh... If only every graphical browser put security first...
I don't recall which Intel executive (one of the chief architects of the Pentium IV architecture) it was that lead to this common misconception, but he later refuted that this was what he meant.
This isn't a common misconception... it is, in essence, true.
The P4, as it stands today, has very small on-chip caches, certainly by comparison with, say, the Athlon, and the primary reason why that is is because of memory latency. Smaller caches have lower access latencies, mitigating the effects of RDRAM's high access latency. RDRAM also has very high bandwidth, significantly higher than even DDR SDRAM, which means that keeping these small caches filled is less of a problem.
Consider also the very long, 20-stage pipelines found in the P4. These also require very large memory bandwidth to keep them filled, and what memory technology does that better than RDRAM? Conversely, a branch-prediction miss by the P4 takes a long time to work its way through this 20-stage pipeline before the P4 can restart its work. This gives RDRAM breathing space to refill the P4's small caches from elsewhere in memory that it would not have if the P4's pipeline was shorter.
Cynics might argue that perhaps the P4's branch-prediction isn't as good as it could be, in order to make up for some of the access latency that RDRAM suffers from...
Don't forget the benchmarks either: where does the P4 really shine, and convincingly beat the Athlon? That'll be benchmarks where the data set that is being processed is large and (mostly) sequential. Why? Well, it's obvious, isn't it? It's down to RDRAM's massive bandwidth. Other tests which do not hammer the memory bandwidth as hard, or where the data set is scattered around memory, show the Athlon coming out on top.
All of this points to the fact that the P4 was at least designed with RDRAM in mind. If not specifically for RDRAM, then at least for a memory technology with large bandwidth and high latency, and how many types of memory do we know that fit that description?
I suspect that future revs of the P4, designed to work better with DDR SDRAM, will have larger on-chip caches, and (possibly) better branch prediction. The larger L1 and/or L2 caches will be necessary in order for the P4 to have competitive performance when using SDRAM. However, this will come at a price - a lot more transistors on the die. More transistors == larger die size, higher power requirements, and, worst of all for Intel, means that they will not be able to scale the clock speed up as fast as they would like to, which leaves me wondering whether they will genuinely be able to keep up with the Athlon in terms of performance.
Just a nit-pick, but actually both the UK and France have well-known submarine-launched ICBM capabilities. Indeed, the UK system is Trident, which is exactly the same as the US sub-launched ICBMs. The warhead/MIRV design is different, but of roughly equivalent capabilities, accuracy and megatonnage (up to 500 kilotonnes per warhead). The French system is entirely of their own design but again, has similar capabilities, payload and range.
But still, your point holds - it seems unlikely that any country would launch an ICBM-based nuclear attack against the US - to do so would mean complete annihilation for that country. Indeed, the only country capable these days of launching a crippling nuclear strike against the US would be the US itself - no other country has the weight of numbers of nuclear devices to be able to effectively knock out most of the US ICBM's...
You cannot pick up a phone and call a responsible person. You have no second avenue to contact a person, say, if someone was forging their domain name. If someone from your domain is spamming and blocking traffic, you cannot be easily contacted to do the right thing.
Except that you do have all these avenues still available to you, because that information is available via RIPE. If you have a problem, find the IP of the host that is causing the problem, look it up, see who owns the netblock, contact them instead, let them deal with it - it's their responsibility.
Now, should detailed contact info be available for the IP registries through WHOIS lookup? I think so, and this is why:
The way it's setup assumes that the owners of netblocks allocated by RIPE are significantly-sized Internet-savvy bodies with their own technical staff, who do not mind being easily-contactable. I think that's a reasonable assumption to make. How many of you own your own personal netblocks?
Now, how many of you own your own personal domain? How many of your non-technical friends own a personal domain?
See the difference? Domains have a very large public ownership. Netblocks do not.
It seems eminently sensible to me that only the contact information that is actually required for the Internet to function should be available via WHOIS, whilst maximizing personal privacy for those who have no day-to-day bearing on the running of the Internet.