IP4 done that way would require routing files of several billion lines.
Not necessarily. Sure, if you hand out the IP addresses in alphabetical order it might (although even then you'd probably have people with the same names tend to live in the same countries). But handing out IP addresses that way would be stupid.
Fundamentally, any ISP conversion to IPv6 now will appear (in terms of functionality gained/lost) almost exactly the same as if they had NATed...
So why bother with IPv6 at all?
Yes, in the long run, its adding functionality for their customers, but right now, it leads to the same "my friend joe can't see my computer on the internet anymore" problem.
Not if both you and your friend joe both upgraded your computers to IPv6. If the ISP upgrades, then you have that option. If they don't, then you don't.
NATs seriously reduce the usability of the internet - in many cases, either you forward (thus making it so only one computer behind a NAT of many may serve a certain content) or you don't use that on your computer.
Forwarding does not make it so only one computer behind a NAT of many may serve a certain content. Different computers may serve the same content using different ports. Sure this requires reconfiguration and sometimes a few programming changes, but so does IPv6.
Presumably with these fancy beer mugs, waitstaff will be coming around to your table to check on you less often. So what if you need something other than beer? After waiting for half an hour should you just dump the beer on the floor and take the cost of it out of the tip?
If you had to first pay for the complete design of your car before buying a new one, you probably would be pretty happy owning your old one for a few more years.
Not if I had to send a shuttle into space just to fix it.
Hubble is a unique device, not a commodity item.
I wasn't trying to prove anything by using the example of a car. I was just showing that it doesn't always make sense to fix something rather than throw it away.
That's an argument for putting the filesystem itself in userspace, not for the ugly filesystem-in-a-filesystem hacks that you seem to want.
I don't want a filesystem in a filesystem. I just think that general purpose databases are different from filesystems.
If the system provides a filesystem that doesn't suck, whatever the state of the supervisor bit may be when its code executes, why not use it?
Ext3 doesn't suck, and I do use it.
As for shared libraries, as opposed to some sort of server task, that removes the ability to have reasonable concurrent access to the data in question by multiple processes, and increases the odds of corruption if the app crashes.
There could still be locking at any level you want, block, file, row, whatever. That would obviously have to involve a system call, at least on SMP.
But "we should not put a good filesystem in the kernel because we already have a worse one there, put your good filesystem in a shared library instead" is just a conservatist statement against any change, not constructive.
I've never said that we shouldn't put a good filesystem in the kernel.
Along those lines you may just as well argue that the kernel should only provide access to block devices, and that a filesystem does not belong in the kernel because it can be done in a shared library.
Well, there are permissions issues which can only be done in the kernel. But other than that, I agree with that statement. The filesystem should be a shared library to the extent that is possible.
We spent so much time, money and effort fixing it, why not spend some more and upgrade it for another decade of use?
Same reason many people will junk an old car which they've spent lots of time, money, and effort fixing. It's nearly the same cost to just buy a new one as to fix the old one, and the new one comes with more features.
Apparently your belief is that every program should be on its own to do all its data management.
Sort of. Data management should be done in shared libraries, in user space, not in the kernel.
Others, including me, believe that the operating system should be there to help perform these tasks by providing suitable services.
I agree. But shared libraries are part of the operating system too, you know. Just because something should be in the OS doesn't mean it should be in the kernel.
I have converted machines from ext2 to reiser, using tar and going partition by partition.
Well, I only have one partition so it would be significantly more difficult than that in my situation...
Is it worth it for you? Only you can make that decision. It has been worth it for me.
So far the only real benefit I would receive immediately is slightly better performance. If that's all I'm going to get, is a few milliseconds here and there, it's certainly not worth it.
I probably will start playing around with it at some point. It would be nice to be able to use vi and grep on everything.
No. I'm serious. You convinced me. The ability to use standard tools like vi and ls on what are essentially general-purpose databases is a good thing.
Hmm... There is one problem though. Every single file access requires a separate system call. That seems like it would be a problem if you were trying to access many files at once. "grep Metallica/mp3/*/artist" is nice to type, but it's a hell of a lot less efficient than if you were using a database file, say/mp3/artist.db.
Slashdot Mirror
IP4 done that way would require routing files of several billion lines.
Not necessarily. Sure, if you hand out the IP addresses in alphabetical order it might (although even then you'd probably have people with the same names tend to live in the same countries). But handing out IP addresses that way would be stupid.
Fundamentally, any ISP conversion to IPv6 now will appear (in terms of functionality gained/lost) almost exactly the same as if they had NATed...
So why bother with IPv6 at all?
Yes, in the long run, its adding functionality for their customers, but right now, it leads to the same "my friend joe can't see my computer on the internet anymore" problem.
Not if both you and your friend joe both upgraded your computers to IPv6. If the ISP upgrades, then you have that option. If they don't, then you don't.
What would that solve? The shortage primarily affects client devices, not servers.
It solves the IP address shortage. The IPv4 address given to the client devices can be an internal only (10.x.x.x) address.
The short answer is that there's no good engineering reason to introduce IPv6 in a IPv4-to-IPv4 network.
Maybe it's not an engineering reason, but there is an IP address shortage reason.
Yes, but that means that your clients have to connect to a non-standard port. This becomes a headache on their part, as its extra configuration.
Not nearly as much headache as switching to IPv6!
And nothing to do with the fact that they would have to spend even more resources on technical support for their customers
ISPs could/should just provide an IPv6 to IPv4 tunnel for users unless they specifically ask for direct IPv6 access.
Enable your box with IPv6 today, Freenet6 provides free IPv6 connectivity over IPv4.
Unfortunately, Freenet6 doesn't work behind NAT.
NATs seriously reduce the usability of the internet - in many cases, either you forward (thus making it so only one computer behind a NAT of many may serve a certain content) or you don't use that on your computer.
Forwarding does not make it so only one computer behind a NAT of many may serve a certain content. Different computers may serve the same content using different ports. Sure this requires reconfiguration and sometimes a few programming changes, but so does IPv6.
In general*, I'd say Americans don't become too concerned with change until it becomes necessary for THEM.
Doesn't that make sense? If you want us to switch to IPv6, you gotta do something for us. Give us some cheap oil or something.
Better not tell PETA.
What percent of the email sent to bruce@hams.com is spam?
Buttons and sensors isn't the answer here; it's well trained people we need.
You're probably right. But buttons are still better than sensors. :)
More importantly what are the implications for our society as we move out of an age of scarcity to an age of plenty?
Unemployment
Presumably with these fancy beer mugs, waitstaff will be coming around to your table to check on you less often. So what if you need something other than beer? After waiting for half an hour should you just dump the beer on the floor and take the cost of it out of the tip?
If the waiter no longer had to constantly monitor drinks, it would free them up to handle more customers and/or provide better service.
So give people a button they can press when they need *anything*. It'd probably be cheaper than the RFID device, and a lot more useful too.
If you had to first pay for the complete design of your car before buying a new one, you probably would be pretty happy owning your old one for a few more years.
Not if I had to send a shuttle into space just to fix it.
Hubble is a unique device, not a commodity item.
I wasn't trying to prove anything by using the example of a car. I was just showing that it doesn't always make sense to fix something rather than throw it away.
That's an argument for putting the filesystem itself in userspace, not for the ugly filesystem-in-a-filesystem hacks that you seem to want.
I don't want a filesystem in a filesystem. I just think that general purpose databases are different from filesystems.
If the system provides a filesystem that doesn't suck, whatever the state of the supervisor bit may be when its code executes, why not use it?
Ext3 doesn't suck, and I do use it.
As for shared libraries, as opposed to some sort of server task, that removes the ability to have reasonable concurrent access to the data in question by multiple processes, and increases the odds of corruption if the app crashes.
There could still be locking at any level you want, block, file, row, whatever. That would obviously have to involve a system call, at least on SMP.
But "we should not put a good filesystem in the kernel because we already have a worse one there, put your good filesystem in a shared library instead" is just a conservatist statement against any change, not constructive.
I've never said that we shouldn't put a good filesystem in the kernel.
Along those lines you may just as well argue that the kernel should only provide access to block devices, and that a filesystem does not belong in the kernel because it can be done in a shared library.
Well, there are permissions issues which can only be done in the kernel. But other than that, I agree with that statement. The filesystem should be a shared library to the extent that is possible.
There's no reason to not use separate files, unless you're working around a crappy filesystem.
Isn't that reason enough?
The moon race isn't the only example, SSI, public education, medicade/medicare are all drastic and sorry failures.
Yeah, not like the shining examples of Amtrak, Worldcom, and Enron.
We spent so much time, money and effort fixing it, why not spend some more and upgrade it for another decade of use?
Same reason many people will junk an old car which they've spent lots of time, money, and effort fixing. It's nearly the same cost to just buy a new one as to fix the old one, and the new one comes with more features.
Apparently your belief is that every program should be on its own to do all its data management.
Sort of. Data management should be done in shared libraries, in user space, not in the kernel.
Others, including me, believe that the operating system should be there to help perform these tasks by providing suitable services.
I agree. But shared libraries are part of the operating system too, you know. Just because something should be in the OS doesn't mean it should be in the kernel.
I have converted machines from ext2 to reiser, using tar and going partition by partition.
Well, I only have one partition so it would be significantly more difficult than that in my situation...
Is it worth it for you? Only you can make that decision. It has been worth it for me.
So far the only real benefit I would receive immediately is slightly better performance. If that's all I'm going to get, is a few milliseconds here and there, it's certainly not worth it.
I probably will start playing around with it at some point. It would be nice to be able to use vi and grep on everything.
Oops that should be "find /mp3 -name Metallica", of course. Maybe that would be less than one system call per file...
No. I'm serious. You convinced me. The ability to use standard tools like vi and ls on what are essentially general-purpose databases is a good thing.
Hmm... There is one problem though. Every single file access requires a separate system call. That seems like it would be a problem if you were trying to access many files at once. "grep Metallica /mp3/*/artist" is nice to type, but it's a hell of a lot less efficient than if you were using a database file, say /mp3/artist.db.
OK, I'm not convinced yet. But I'm getting there.
Maybe not you yourself, but some programs will certainly do that. E.g. a cache directory of a browser or proxy server.
That's poor design. There's no reason to use more than a single file for the cache.
Programs have to be handling the deficiencies in filesystem directories by adding extra directory levels, which complicates them more than necessary.
That's where shared libraries come into place. I'm sure there are already libraries written to handle such databases.
Because it is more efficient [to use separate files] when deleting mail messages or moving them between folders.
Not if your program is written properly.
It works on all filesystems, but performs better on some than on others.
If it's slow as hell, I wouldn't say it works.