In much the same way as 6 degrees of kevin bacon works, I'd venture to say that you can find more than half of all useful web sites within six degrees of web linking. The interesting thing will be that blogs do form their own little distinct cluster. This also applies to other aspects of computer networks, as well as certain human beings.
And what's the reason Cisco routers can't cope with the entire world being/24? It's a routing architecture design that can't scale. And it's an architecture that is still fundamentally the same, and still as limited in scalability, in IPv6.
ARIN should go ahead and make direct, permanent, portable, IPv6 space assignments to the companies that already have such assignments in the IPv4 space. Don't wait... hand them out now. That way, when an ISP does decide they might try IPv6, there won't be any of the excuses about dealing with ARIN in getting address assignments.
BTW, NAT routers can be used to avoid having to enable IPv6 on everything in the LAN. One new NAT box and the whole LAN is on IPv6.
As for brushing up on IPv6, the April 2003 issue of ";login:", the magazine of USENIX and SAGE, has an excellent jump start article on understanding and deploying IPv6.
The need for IPv6 is in the future. Way in the future. But we can go ahead and use it today if we solve some issues (some technical, like routing, and some political). But taking address space back from early adopters is not going to encourage them to use IPv6 directly. Hopefully the universal reachability of it will.
The reason is policy of address assignments. In order to get a permanent, portable, address assignment, you have to eat the 8192 address of a/19 reservation (sure you can get just a/20 with 4096 addresses initially, now, but the full/19 is reserved). There are thousands of businesses in the USA doing web hosting right now. They could use virtual by name for all non-HTTPS sites, and only need one address per customer for the few HTTPS sites needed by customers. A typical web hoster can easily get by with 1024 or even just 256 addresses. What they can't do at that level is get permanent, portable, address assignments. But many end up padding their customer base, and using other tricks like building the appearance of banks of dialup servers to give the appearance of also doing that business (even though they don't)... all to justify to ARIN to get the minimum/20 (with/19 reservation). This kind of thing is part of what is wasting address space (that and some companies that are sitting on/8 assignments with maybe a handful actually connected to the public internet).
The problem is not an issue of address space availability. While IPv4 is a bit cramped, we can deal with it for at least 10 to 20 more years. The real problem is routing. Our existing public routing infrastructure technology is based on BGP4, which requires each router to store and process a massive amount of details about things it really should not concern itself with. What BGP4 does is takes what should be viewed as a hierarchical and cyclical network, and flattens it inefficiently. Now, doing something better won't be easy, but many ideas do exist. The shame of IETF is they scaled up the addressing in IPv6 but didn't even try to scale up the routing technology to go with it.
He is obviously not talking about routing as it is designed and implemented in today's network. He is not talking about BGP4 or OSPF, which are routing technologies that do not scale well, and are based on heavy workloads for the individual routers. Instead, he is envisioning what I have also done (with slightly different details) and trying to come up with something better that would allow things like everyone getting portable address space without routers having to load up millions of prefixes and AS's in its memory. What if I told you that your router needed to handle a network with 200,000,000 portable address assignments? If you really do know much about routers (which is in doubt), you'd know that the current methods involve storing all that information in each router, even though almost everything will be routed to a small handful of different interfaces. But routing can be made to work without doing that. It's just not done that way in the IPv4 networks now. But had it been a completed design made in conjunction with IPv6, then it would have made IPv6 all the more attractive. Every business could have had a portable, permanent IP space assignment without having to load every assignment prefix or autonomous system ID in every router.
Of course the topic would be laughed off of NANOG. That's because NANOG is about operating current networks. It's not about designing new technology. The parent of your post would simply be off topic there, and probably confuse 90% of the subscribers, anyway.
What is wrong with SMTP is that it did not force implementations to do what it is we need for mail transfers today. When it was created, it was the right thing at the time. But for today, we need to shed SMTP primarily to shed implementations that deviate, in many cases radically, from what even the original SMTP designs could not have envisioned.
What is needed is a whole new protocol, but not so much for what technology that protocol can provide, but rather, for what it can prohibit. Getting people to actually switch to this new protocol and abandon SMTP would be next to impossible, except that had this been integrated into IPv6, it might be possible to do.
Had IETF chosen to set aside of chunk of address space to permanently and portably allocate to serious deployers... space that would not ever be taken back... that could be kept forever as the payment for helping to make IPv6 happen... then I think a lot of ISPs and businesses would have done this. Instead, what we have are 6bone addresses that will not be routable on the real IPv6, and tunnels that will be taken down soon, making those addresses useless. Sure, there is a routing scalability problem still in IPv6. The only benefit IPv6 has over IPv4 in routing is that there hopefully won't be a case of single companies advertising dozens of unaggregated prefixes... or at least no more than one per major location. So shame on the IETF for not having solved that problem with a fundamentally new way to do routing in conjunction with the development of an addressing technology that now way overscales the ability to route it.
It's now a chicken and egg problem. ISPs simply will not, not in this economy, and not for years even after it gets better, make an investment in deploying IPv6 unless there is customer demand for it. Customers won't demand it until there is some real need for it, which is not the case, especially with so many businesses now running big LANs via one NAT'd IPv4 address. If some web site goes online with both IPv4 and IPv6, everyone will access it via IPv4 and that won't create any demand for IPv6. If they go online with IPv6 only, no one can reach them for a while, and they will probably not really make it.
But there are some possible ways to make IPv6 happen:
Select 4096 portable address prefixes and offer them on a permanent basis to 4096 ISPs that will deploy it within 90 days over their entire infrastructure and their borders (if their upstream does not have it, a tunnel from there will still qualify as deployment).
Create a new email protocol that will be effective in eliminating spam (just how to do that is still to be determined) and make it require IPv6 to work.
New appliance products, such as Tivos, that are built to be IPv6 only.
The dot-edu networks (which led the way to mass deployment of IPv4 in the first place) should lead the pack and go IPv6. The dot-com's will soon follow.
What's in it for me? I got IP addresses already. Maybe if some day I need more I might have to get IPv6 ones. But only if I can get portable ones. Of course that brings up the critical issue that during the development of IPv6, while that scaled up the address space massively, they didn't do so with the routing issue.
Just to elaborate on the dynamic linking issue a little more, when a program that needs the "cos" function ends up being linked to libm, then at the time that program is executed, the libm.so file has to be memory mapped. At first that does not read any pages. But it does add another bunch of map entries to the VM structure. Then the dynamic linker has to resolve for "cos" and other symbols. That forces it to read the symbol table parts of the libm.so file. So now those do get read in. It's not as bad as reading in the whole file, but it's not a zero effort, either. And when "cos" is called, at least one page of code is loaded, maybe 2 or more. For small functions, a whole page is loaded for each function when dynamically linked if those functions are scattered around. Had it been statically linked, "cos" would be sharing a page with some other functions, and less VM working set would result, in addition to less I/O work to get loaded.
I'm not opposed to having shared libraries. Sharing the code is valuable when the sharing factor is high. But the judgement needs to be made on that basis. We know it will be high for libc. The question is what other libraries qualify.
Now I do consider libm to be a borderline case. I'm satisfied to leave it be dynamically linked since many programs do use it. Same for the core libraries of graphical systems like GTK+ and Qt. But lesser libraries really should be considered for static linking by packagers. And source developers should make their configure files to understand options to control whether to link statically or dynamically (with static being the default for perhaps all but libc). Even better would be to further include options for explicit control per library (including libc). That doesn't mean to not include the dynamic libraries, but it will help end users avoid problems if they, due to not being experts about what libraries every program needs, end up with certain libraries not installed that a dynamic program needs.
True. For well behaved packages it isn't needed. But I've encountered enough that are not (usually lacking support for DESTDIR= or INSTALLPREFIX= or such) that make it necessary to have this tool. So now that I have it, just using it universally anyway reduces the convolution level of my work.
They should do that to statically link certain libraries. But judgement needs to be made as to which ones. Certainly libc is a bad choice for static linking (except for certain system tools that need to work while libraries are under maintenance). I'd say libm, gtk+, glib, and a few others that are big and commonly used are bad choices for static linking since you'll really have to have them around, anyway. But at the other extreme, specialty libraries just for one or two applications are more hassle than they are worth. Those should be statically linked in most cases (there are a few certain scenarios where doing run time dynamic linking is still a good thing, such as run time modularity).
GTK+ is probably not a good example because of it's general usability. And GLIB is probably even more so because its usability goes even further. And we wouldn't suggest statically linking libc (or at least I wouldn't). The point is more of concern to library writers (besides those who do libc, GLIB, etc) who do libraries that are either smaller, or are used in fewer applications, or both. How likely are you to have several different applications loaded at the same time that need the 84K of, say, libext2? More likely only a small few tools will need it, and you'll probably be using only one of them at a time. Statically linking to that library would be a plus for those few applications (while still dynamically linking to libc, etc).
Basically your suggestion amounts to building a binary package from a source package as a stage to having it actually installed. While that is something I actually do (using Slackware package.tgz format), and even recommend it to many people, it's not necessarily suitable for everyone or every purpose. I still run an experimental machine where everything I install beyond the distribution is installed from source. That's good for quickly checking out some new package to see if it really does what the blurbs imply (quite often this is not the case).
Building your own binary packages in whatever is your preferred package format is definitely a plus when managing lots of computers. And this way you have the plus that the MD5 checksum of all the binary files will be the same across multiple computers, making it easy to check for trojans.
As for making the recipe or spec file, I've actually figured out a way to do that when I build source packages into binary packages. It's slow but it works. I first construct a subdirectory consisting of a copy (never a hard link or bind mount) of the system root tree (or just enough to accompish the building). Then I scan that directory modifying every file object to some weird date way in the past. For symlinks which cannot have their date changed, I just note the current time as all new symlinks will have a timestamp after this. Then the installation is executed under chroot and thus will be installed within the subdirectory (as long as the package author didn't slip in some program to crack out of the chroot, which can be done easily). A rescan compares everything against the previous scan. Every file and every symlink changed or created will be detected. It's not perfect in theory (if the source package elects to not install something because it already exists in your root template, then you'll miss it), but so far I've been totally successful with it.
If a bunch of Linux geeks want to have a hard to install Linux system in order to raise the leetness level, they can always put together their own "LeetLinux" distribution. We can't (and shouldn't) stop them. There shouldn't be a requirement that all distributions be "easy". This even applies to the BSD's. I personally find the command line install of OpenBSD more flexible (and even easier anyway) than the menu driven install of FreeBSD. But as I use Linux mostly, my preferred leetness distro is Slackware. Many will also find Gentoo and Linux From Scratch suits their desires.
The following numbers are hypothetical and do not represent the true tradeoff, but they should serve well enough to make the point. If libthingy is 5K, and your application launches a maximum of 10 instances, all of which are statically linked with libthingy, you would only save about 45K by linking to libthingy dynamically. In normal environments, that is hardly worth the risk of having your application break because some other build or package overwrites the shared version of libthingy.
Linking libthingy statically into application foo does not preclude the sharing. Each of the instances of application foo will still share all the code of that executable. So if libthingy takes up 5K, and you launch 10 instances, that does not mean the other 9 will take up separate memory. Even statically linked, as long as the executable is in a shared linking format like ELF, which generally will be the case, each process VM will be mapped from the same file. So we're still looking at around 5K of real memory occupancy for even 1000 instances of application foo. The exact details will depend on how many pages get hit by the run-time linker when it has to make some address relocations. With static linking there is less of that, anyway. Of course if libthingy has its own static buffers space it modified (bad programming practice in the best case, a disaster waiting to happen in multithreading) then the affected pages will be copied-on-write and no longer be shared (so don't do that when developing any library code).
Where a shared library gives an advantage is when there are many different applications all using the same library. So the "shared" part of "shared library" means sharing between completely different executable files. Sharing between multiple instances of the same executable file is already done by the virtual memory system (less any CoW).
The author's next point about sharing between other applications is where the size of libthingy becomes relevant. His point being that if libthingy is only 5K, you're only saving 45K by making it a shared (between different executables) library. So that's 45K more disk space used up and 45K more RAM used up when loading those 10 different applications in memory. The idea is the hassle savings trumps the disk and memory savings. The situation favors the author's position to use static linking for smaller less universal libraries even more than he realized (or at least wrote about).
For a desktop computer, you're going to see more applications, and fewer instances of each, loaded. So here, the issue really is sharing between applications. But the point remains valid regarding small specialty libraries that get used by only a few (such as 10) applications. However, on a server computer, there may well be hundreds of instances of the same application, and perhaps very few applications. It might be a mail server running 1000 instances of the SMTP daemon trying to sift through a spam attack. Even if the SMTP code is built statically, those 1000 instances still share unmodified memory mapped from the executable file.
While the RIAA will be aiming for the pirates, it's bound to happen that they hit someone who wasn't pirating anything. If damage is caused, then the concept that the person suing the RIAA for those damages being a pirate won't be a valid defense. They will have to be very very careful to avoid that.
In order for such a list to be effective, it would have to be available. If it's available, it would also end up in the hands of foreign spammers whould would use it as a source of higher percentage real working addresses. Of course the simple solution to that is that the list has to be distributed in the form of list of cryptographically strong (unreversable) checksums. To see if the next email address to be spammed is on the list, calculate the checksum of the canonical form of the address (e.g. lower case), and look up the checksum in the list. But even this won't do very well as the foreign spammers, while not having a direct list of all these working addresses, can at least use it to select known working addresses from the lists they do have.
Another issue with a "do not email list" is how to handle things like tagged email addresses (e.g. foo-alpha@example.com and foo-beta@example.com go to the same mail box, where "-" might be "+" on some systems). If the law says that the tags and their separators have to be stripped off before checksumming and lookup, maybe that won't be so much of a problem.
Yet another problem is that many people have vanity domain names where anything on the left when addressed at their domain will be delivered (or forwarded) into their mailbox. Some form of wildcarding is essential, such as "*@example.net". If this isn't done, you can expect people with such domains to try to register every possible address. If there is any cost to the list, these same people will be suing the government for trying to charge them billions of dollars to register. Of course you can bet that "*@aol.com" will then be registered. And just about any business with a domain will do likewise for theirs.
Unless these things are done, the list won't really work.
BTW, these "do not call" lists in various states are for residential phones only. Businesses phones, at least in several states (Texas and California I know for sure), cannot be listed. There might be a move to gut a "do not email" list by placing the same demands on it, too.
By holding off until court to present what specific parts of Linux are claimed to be violating their copyrights, they will be causing the court to have to be delayed while allowing IBM to research the specifics. This is the kind of thing that should be divulged during discovery. I would think the judge will not be happy about this tactic.
The only thing I can see SCO is doing in this is trying to drag out the case. By dragging it out, they are probably trying to get IBM and/or other businesses to just pay them royalties to shut the thing up, or buy them out. I hope they don't get bought out so we can have a boycott target.
My understanding of this is, since they are playing games by not telling anyone what the specific violation is, they are losing their rights to claim past damages (unless they can prove the party they are suing knew of the violation). The usual way a copyright or trade secret violation is handled is by contacting the violating party and asking for the matter to be corrected. If the violating party does correct the problem in a timely manner, courts will generally treat past violations as innocent violations, and awards would not be more than the profits involved. But SCO hasn't done this. Instead they are refusing to saw what the violation is. They are only referring to "Linux" and it isn't even clear if they mean the kernel, some driver, or userland code. There's nothing any party can do to remove any violating code until they know what it is.
Since SCO is playing games like not simply telling Linus what code needs to be removed from the Linux kernel, then that is enough to earn all the dissing they are getting. In a normal case, they would say what it is they are concerned about, instead of trying to destroy the overall credibility. If their complaint is legitimate, they could show it, and have the code removed. It's almost like Microsoft put them up to this. That's why SCO's name is forever known as mud to me and millions of others, now.
Apple is missing a marketing opportunity. Surely they know they have a miniscule part of the desktop market (Linux passed Mac over two years ago in number of deployed units). Obviously tying this service to the Mac is part of the strategy to bolster that market share. But the one thing that is missing is the ability to let those who don't (yet) own a Mac to browse. By making the web site so that everyone else can see what is available... e.g. what they are missing by not having a Mac... they could end up selling more Macs.
Of course a marketing droid would never think of the obvious.
And be sure to boycott any business or ISP that refuses to take all the appropriate steps. And don't listen to their whining about collateral damage, since they can avoid that by doing the right things with their mail servers.
Re:Will DRM even work in Linux?
on
Linus on DRM
·
· Score: 1
(I suspect that more people would've read and responded if that post had been, oh, 20% of it's length)
Including trolls. I really wouldn't worry too much about it. Those who don't consider it important enough to read it all wouldn't contribute much, anyway. But thank you for doing so.
By a "hardware model", are you proposing that key validation and decryption is done on the output hardware (videocard), rather than the computer software being allowed to view the content in the clear? (That is, encrypted file is loaded from the DVD-ROM, copied to memory as an unintelligble bag of bits, and pushed to the videocard which decrypts and sends down the VGA port)
Basically
That removed many of the advantages computer software can provide, or at least make software (and hardware) developer's lives much more difficult. Because no software can see the data in the clear, it has absolutely no chance to perform any kind of useful transformation on the data. In ordinary use, many transformations are absolutely required- which means that the videocard will need to have an interface built so it can be instructed to perform those commands.
I'm sure the content provider industry would want it that way. Of course I'd prefer to be able to process the video and audio in software and do some clever things, too. But the more you can do this, the more likely the chance it can leak a copy. And the industry would surely know this by now. So based on their motivations, having everything in hardware would be a sweet deal.
Individually, none of those features is very hard They include repositioning, flipping, rotation, gamma correction, clipping, scaling, and the like. (Audio files would need their own set of effects) But put them all together, and the complexity of interacting with a videocard has increased substantially.
Most of those features are things you need to do on your own creations, as opposed to the latest blockbuster movie, or the number one hit song, which the content provider would rather you not touch.
(The MacOSX feature of genielike warping a running video down into a dock icon will be completely out of there)
I think a video card could be instructed to insert the video into specified coordinates or under an alpha mask.
True, existing videocards already do most of those things in the form of accelerator functions... but those are a concern for the driver author at the hardware vendor.
I would expect the DRM decoder would just be another source for the "mixer" component of the system. The only catch is it would be at a point where you would not be able to capture the results. That might mean two mixers, the first of which allows a buffer re-capture, but then that is fed to the 2nd one which does not, and only feeds to the DACs.
As a GUI author, I'm scared to think of what these further restrictions could bring to my code- it's an enforced layer of extra redirection. Imagine writing a 3d videogame whose visual and audio resources are protected by DRM (they'll at least want to do this for the soundtrack).
Your need an API that allows you to play the sound components. The game company would perhaps have to get a distributable license that allows that particularly encrypted version of the sound to be played (obtained by the usualy channels via the Harry Fox Agency). Or perhaps the game itself might be forced to issue time licenses by the content industry. Or buy all the rights to that music and own it yourself (expensive). I'm not saying I like these things, but rather, that this is a model they could do which I think would be the lesser of evils.
As time passes, and more and more data transformations need to be performed on the trusted outp
Will DRM even work in Linux?
on
Linus on DRM
·
· Score: 4, Interesting
What the media content providers want to ensure is that you, the human being, can hear/see the content, without there being a way for you to actually copy it to allow others to hear/see that content, or even for you to hear/see it at some later time frame or more than a specified (e.g. paid for) number of times. Whether we agree with their right to do that or not, that is a general description of their goal (or at least for many of them).
No protection will be perfect, of course. If you can hear it, you can record it from a microphone. If you can see it, you can record it from a camera. But as we know from past articles on Slashdot and elsewhere, even these techniques of copying are targets of efforts to prevent recordability. If you succeed at such recording, perhaps at least these methods will have forced a degradation of quality in that recording (e.g. while working to strip out any watermarking, you also damage the quality).
What the content providers particularly loath, however, is the ability to have direct access to the content digitally. If you have that, you can copy that as is, and play it back at a different time or place or in front of a different audience or multiple times. The primary means of preventing this is encryption. But at some point it has to be decrypted. At that point you then find the content in the clear. One aspect of DRM is to deploy a "sealed box" wherein the decryption can take place, yet the user cannot get access to the clear content. Windows can potentially do this due to its closed and proprietary nature. It won't be perfect, but most people will not have any idea how to bypass DRM. There is the potential to distribute software to do it that anyone can use, but certainly we can expect DRM in cooperation with Windows itself to make it hard for unsigned (by Microsoft) software to have access at the level needed to get at the clear content. For example, Windows with DRM will probably refuse to allow you to install your own sound card driver since that is one place where the clear content will be going through.
Linux could certainly have DRM code integrated into it. But because it is open source, and you can build your own kernel, this is a much harder black box to implement. From the point of view of content providers, Linux is a hazardous environment (so is BSD).
Linux supports loading modules which might be available only in object form. There are such modules already available commercially, such as for certain video cards. Some of us love them (because the cards are awesome) or hate them (because the modules are buggy, perhaps with new kernel versions, and cause crashes that would otherwise not be the norm in Linux). But when it comes right down to it, we can add new code to the kernel to work around all the interfaces the module is using. For a device driver, the hard aspect will be seeing what it actually does with the device at the register level. But a DRM black box would be something quite different, since it would need to be able to use existing sound card or video/TV card drivers. That opens the potential to wedge a tap in between DRM and the drivers (or even replace the driver with your own), which Linux would allow and Windows would not so easily. And don't think the media content providers don't know this (they have been getting a lot of hard technical lessons the past few years).
But it can still be possible to have DRM with Linux. One approach is to put the DRM directly in the device driver. That would help, but wouldn't be perfect since other code can be present in the kernel to get cozy with what the DRM is doing. The big problem is getting all the device manufacturers to make a Linux driver.
Perhaps the best (from a practical perspective, were the content providers ever to realize this) way is to put DRM directly in the hardware. That's about as sealed up as you can get. I'll explain how this can work in terms of music in an encrypted MP3 format, but you can extrapolate it in terms of other media or
Thanks for the info. I'm not sure yet what form those fixes are in, but personally I would prefer a kernel patch. If I don't find what I like, I'll probably make my own. The ability to set the default TTL certainly should be an administrator choice. Being able to do so for NAT-ted packets would, in my opinion, all be part of the intent to present a different appearance than would actually exist. My preference in Linux would be for some/proc entries to do this, one for default TTL of packets originating locally, one for NAT-ted packets, one for routed packets, and finally even one for bridged packets recognized as IP. The latter 3 should also allow a + or - designator to simply allow adding or subtracting a specified amount to the TTL. I don't believe such a thing should require a process running to do, and I don't see why/proc can't be used to set the policy, as it already can do for many other things, like turning on routing.
Slashdot Mirror
In much the same way as 6 degrees of kevin bacon works, I'd venture to say that you can find more than half of all useful web sites within six degrees of web linking. The interesting thing will be that blogs do form their own little distinct cluster. This also applies to other aspects of computer networks, as well as certain human beings.
And what's the reason Cisco routers can't cope with the entire world being /24? It's a routing architecture design that can't scale. And it's an architecture that is still fundamentally the same, and still as limited in scalability, in IPv6.
ARIN should go ahead and make direct, permanent, portable, IPv6 space assignments to the companies that already have such assignments in the IPv4 space. Don't wait ... hand them out now. That way, when an ISP does decide they might try IPv6, there won't be any of the excuses about dealing with ARIN in getting address assignments.
BTW, NAT routers can be used to avoid having to enable IPv6 on everything in the LAN. One new NAT box and the whole LAN is on IPv6.
As for brushing up on IPv6, the April 2003 issue of ";login:", the magazine of USENIX and SAGE, has an excellent jump start article on understanding and deploying IPv6.
The need for IPv6 is in the future. Way in the future. But we can go ahead and use it today if we solve some issues (some technical, like routing, and some political). But taking address space back from early adopters is not going to encourage them to use IPv6 directly. Hopefully the universal reachability of it will.
I just hope spammers stay on IPv4.
The reason is policy of address assignments. In order to get a permanent, portable, address assignment, you have to eat the 8192 address of a /19 reservation (sure you can get just a /20 with 4096 addresses initially, now, but the full /19 is reserved). There are thousands of businesses in the USA doing web hosting right now. They could use virtual by name for all non-HTTPS sites, and only need one address per customer for the few HTTPS sites needed by customers. A typical web hoster can easily get by with 1024 or even just 256 addresses. What they can't do at that level is get permanent, portable, address assignments. But many end up padding their customer base, and using other tricks like building the appearance of banks of dialup servers to give the appearance of also doing that business (even though they don't) ... all to justify to ARIN to get the minimum /20 (with /19 reservation). This kind of thing is part of what is wasting address space (that and some companies that are sitting on /8 assignments with maybe a handful actually connected to the public internet).
The problem is not an issue of address space availability. While IPv4 is a bit cramped, we can deal with it for at least 10 to 20 more years. The real problem is routing. Our existing public routing infrastructure technology is based on BGP4, which requires each router to store and process a massive amount of details about things it really should not concern itself with. What BGP4 does is takes what should be viewed as a hierarchical and cyclical network, and flattens it inefficiently. Now, doing something better won't be easy, but many ideas do exist. The shame of IETF is they scaled up the addressing in IPv6 but didn't even try to scale up the routing technology to go with it.
He is obviously not talking about routing as it is designed and implemented in today's network. He is not talking about BGP4 or OSPF, which are routing technologies that do not scale well, and are based on heavy workloads for the individual routers. Instead, he is envisioning what I have also done (with slightly different details) and trying to come up with something better that would allow things like everyone getting portable address space without routers having to load up millions of prefixes and AS's in its memory. What if I told you that your router needed to handle a network with 200,000,000 portable address assignments? If you really do know much about routers (which is in doubt), you'd know that the current methods involve storing all that information in each router, even though almost everything will be routed to a small handful of different interfaces. But routing can be made to work without doing that. It's just not done that way in the IPv4 networks now. But had it been a completed design made in conjunction with IPv6, then it would have made IPv6 all the more attractive. Every business could have had a portable, permanent IP space assignment without having to load every assignment prefix or autonomous system ID in every router.
Of course the topic would be laughed off of NANOG. That's because NANOG is about operating current networks. It's not about designing new technology. The parent of your post would simply be off topic there, and probably confuse 90% of the subscribers, anyway.
What is wrong with SMTP is that it did not force implementations to do what it is we need for mail transfers today. When it was created, it was the right thing at the time. But for today, we need to shed SMTP primarily to shed implementations that deviate, in many cases radically, from what even the original SMTP designs could not have envisioned.
What is needed is a whole new protocol, but not so much for what technology that protocol can provide, but rather, for what it can prohibit. Getting people to actually switch to this new protocol and abandon SMTP would be next to impossible, except that had this been integrated into IPv6, it might be possible to do.
Had IETF chosen to set aside of chunk of address space to permanently and portably allocate to serious deployers ... space that would not ever be taken back ... that could be kept forever as the payment for helping to make IPv6 happen ... then I think a lot of ISPs and businesses would have done this. Instead, what we have are 6bone addresses that will not be routable on the real IPv6, and tunnels that will be taken down soon, making those addresses useless. Sure, there is a routing scalability problem still in IPv6. The only benefit IPv6 has over IPv4 in routing is that there hopefully won't be a case of single companies advertising dozens of unaggregated prefixes ... or at least no more than one per major location. So shame on the IETF for not having solved that problem with a fundamentally new way to do routing in conjunction with the development of an addressing technology that now way overscales the ability to route it.
It's now a chicken and egg problem. ISPs simply will not, not in this economy, and not for years even after it gets better, make an investment in deploying IPv6 unless there is customer demand for it. Customers won't demand it until there is some real need for it, which is not the case, especially with so many businesses now running big LANs via one NAT'd IPv4 address. If some web site goes online with both IPv4 and IPv6, everyone will access it via IPv4 and that won't create any demand for IPv6. If they go online with IPv6 only, no one can reach them for a while, and they will probably not really make it.
But there are some possible ways to make IPv6 happen:
What's in it for me? I got IP addresses already. Maybe if some day I need more I might have to get IPv6 ones. But only if I can get portable ones. Of course that brings up the critical issue that during the development of IPv6, while that scaled up the address space massively, they didn't do so with the routing issue.
Just to elaborate on the dynamic linking issue a little more, when a program that needs the "cos" function ends up being linked to libm, then at the time that program is executed, the libm.so file has to be memory mapped. At first that does not read any pages. But it does add another bunch of map entries to the VM structure. Then the dynamic linker has to resolve for "cos" and other symbols. That forces it to read the symbol table parts of the libm.so file. So now those do get read in. It's not as bad as reading in the whole file, but it's not a zero effort, either. And when "cos" is called, at least one page of code is loaded, maybe 2 or more. For small functions, a whole page is loaded for each function when dynamically linked if those functions are scattered around. Had it been statically linked, "cos" would be sharing a page with some other functions, and less VM working set would result, in addition to less I/O work to get loaded.
I'm not opposed to having shared libraries. Sharing the code is valuable when the sharing factor is high. But the judgement needs to be made on that basis. We know it will be high for libc. The question is what other libraries qualify.
Now I do consider libm to be a borderline case. I'm satisfied to leave it be dynamically linked since many programs do use it. Same for the core libraries of graphical systems like GTK+ and Qt. But lesser libraries really should be considered for static linking by packagers. And source developers should make their configure files to understand options to control whether to link statically or dynamically (with static being the default for perhaps all but libc). Even better would be to further include options for explicit control per library (including libc). That doesn't mean to not include the dynamic libraries, but it will help end users avoid problems if they, due to not being experts about what libraries every program needs, end up with certain libraries not installed that a dynamic program needs.
True. For well behaved packages it isn't needed. But I've encountered enough that are not (usually lacking support for DESTDIR= or INSTALLPREFIX= or such) that make it necessary to have this tool. So now that I have it, just using it universally anyway reduces the convolution level of my work.
They should do that to statically link certain libraries. But judgement needs to be made as to which ones. Certainly libc is a bad choice for static linking (except for certain system tools that need to work while libraries are under maintenance). I'd say libm, gtk+, glib, and a few others that are big and commonly used are bad choices for static linking since you'll really have to have them around, anyway. But at the other extreme, specialty libraries just for one or two applications are more hassle than they are worth. Those should be statically linked in most cases (there are a few certain scenarios where doing run time dynamic linking is still a good thing, such as run time modularity).
GTK+ is probably not a good example because of it's general usability. And GLIB is probably even more so because its usability goes even further. And we wouldn't suggest statically linking libc (or at least I wouldn't). The point is more of concern to library writers (besides those who do libc, GLIB, etc) who do libraries that are either smaller, or are used in fewer applications, or both. How likely are you to have several different applications loaded at the same time that need the 84K of, say, libext2? More likely only a small few tools will need it, and you'll probably be using only one of them at a time. Statically linking to that library would be a plus for those few applications (while still dynamically linking to libc, etc).
Basically your suggestion amounts to building a binary package from a source package as a stage to having it actually installed. While that is something I actually do (using Slackware package.tgz format), and even recommend it to many people, it's not necessarily suitable for everyone or every purpose. I still run an experimental machine where everything I install beyond the distribution is installed from source. That's good for quickly checking out some new package to see if it really does what the blurbs imply (quite often this is not the case).
Building your own binary packages in whatever is your preferred package format is definitely a plus when managing lots of computers. And this way you have the plus that the MD5 checksum of all the binary files will be the same across multiple computers, making it easy to check for trojans.
As for making the recipe or spec file, I've actually figured out a way to do that when I build source packages into binary packages. It's slow but it works. I first construct a subdirectory consisting of a copy (never a hard link or bind mount) of the system root tree (or just enough to accompish the building). Then I scan that directory modifying every file object to some weird date way in the past. For symlinks which cannot have their date changed, I just note the current time as all new symlinks will have a timestamp after this. Then the installation is executed under chroot and thus will be installed within the subdirectory (as long as the package author didn't slip in some program to crack out of the chroot, which can be done easily). A rescan compares everything against the previous scan. Every file and every symlink changed or created will be detected. It's not perfect in theory (if the source package elects to not install something because it already exists in your root template, then you'll miss it), but so far I've been totally successful with it.
If a bunch of Linux geeks want to have a hard to install Linux system in order to raise the leetness level, they can always put together their own "LeetLinux" distribution. We can't (and shouldn't) stop them. There shouldn't be a requirement that all distributions be "easy". This even applies to the BSD's. I personally find the command line install of OpenBSD more flexible (and even easier anyway) than the menu driven install of FreeBSD. But as I use Linux mostly, my preferred leetness distro is Slackware. Many will also find Gentoo and Linux From Scratch suits their desires.
Nicholas Petreley writes:
Linking libthingy statically into application foo does not preclude the sharing. Each of the instances of application foo will still share all the code of that executable. So if libthingy takes up 5K, and you launch 10 instances, that does not mean the other 9 will take up separate memory. Even statically linked, as long as the executable is in a shared linking format like ELF, which generally will be the case, each process VM will be mapped from the same file. So we're still looking at around 5K of real memory occupancy for even 1000 instances of application foo. The exact details will depend on how many pages get hit by the run-time linker when it has to make some address relocations. With static linking there is less of that, anyway. Of course if libthingy has its own static buffers space it modified (bad programming practice in the best case, a disaster waiting to happen in multithreading) then the affected pages will be copied-on-write and no longer be shared (so don't do that when developing any library code).
Where a shared library gives an advantage is when there are many different applications all using the same library. So the "shared" part of "shared library" means sharing between completely different executable files. Sharing between multiple instances of the same executable file is already done by the virtual memory system (less any CoW).
The author's next point about sharing between other applications is where the size of libthingy becomes relevant. His point being that if libthingy is only 5K, you're only saving 45K by making it a shared (between different executables) library. So that's 45K more disk space used up and 45K more RAM used up when loading those 10 different applications in memory. The idea is the hassle savings trumps the disk and memory savings. The situation favors the author's position to use static linking for smaller less universal libraries even more than he realized (or at least wrote about).
For a desktop computer, you're going to see more applications, and fewer instances of each, loaded. So here, the issue really is sharing between applications. But the point remains valid regarding small specialty libraries that get used by only a few (such as 10) applications. However, on a server computer, there may well be hundreds of instances of the same application, and perhaps very few applications. It might be a mail server running 1000 instances of the SMTP daemon trying to sift through a spam attack. Even if the SMTP code is built statically, those 1000 instances still share unmodified memory mapped from the executable file.
While the RIAA will be aiming for the pirates, it's bound to happen that they hit someone who wasn't pirating anything. If damage is caused, then the concept that the person suing the RIAA for those damages being a pirate won't be a valid defense. They will have to be very very careful to avoid that.
In order for such a list to be effective, it would have to be available. If it's available, it would also end up in the hands of foreign spammers whould would use it as a source of higher percentage real working addresses. Of course the simple solution to that is that the list has to be distributed in the form of list of cryptographically strong (unreversable) checksums. To see if the next email address to be spammed is on the list, calculate the checksum of the canonical form of the address (e.g. lower case), and look up the checksum in the list. But even this won't do very well as the foreign spammers, while not having a direct list of all these working addresses, can at least use it to select known working addresses from the lists they do have.
Another issue with a "do not email list" is how to handle things like tagged email addresses (e.g. foo-alpha@example.com and foo-beta@example.com go to the same mail box, where "-" might be "+" on some systems). If the law says that the tags and their separators have to be stripped off before checksumming and lookup, maybe that won't be so much of a problem.
Yet another problem is that many people have vanity domain names where anything on the left when addressed at their domain will be delivered (or forwarded) into their mailbox. Some form of wildcarding is essential, such as "*@example.net". If this isn't done, you can expect people with such domains to try to register every possible address. If there is any cost to the list, these same people will be suing the government for trying to charge them billions of dollars to register. Of course you can bet that "*@aol.com" will then be registered. And just about any business with a domain will do likewise for theirs.
Unless these things are done, the list won't really work.
BTW, these "do not call" lists in various states are for residential phones only. Businesses phones, at least in several states (Texas and California I know for sure), cannot be listed. There might be a move to gut a "do not email" list by placing the same demands on it, too.
By holding off until court to present what specific parts of Linux are claimed to be violating their copyrights, they will be causing the court to have to be delayed while allowing IBM to research the specifics. This is the kind of thing that should be divulged during discovery. I would think the judge will not be happy about this tactic.
The only thing I can see SCO is doing in this is trying to drag out the case. By dragging it out, they are probably trying to get IBM and/or other businesses to just pay them royalties to shut the thing up, or buy them out. I hope they don't get bought out so we can have a boycott target.
IANAL
My understanding of this is, since they are playing games by not telling anyone what the specific violation is, they are losing their rights to claim past damages (unless they can prove the party they are suing knew of the violation). The usual way a copyright or trade secret violation is handled is by contacting the violating party and asking for the matter to be corrected. If the violating party does correct the problem in a timely manner, courts will generally treat past violations as innocent violations, and awards would not be more than the profits involved. But SCO hasn't done this. Instead they are refusing to saw what the violation is. They are only referring to "Linux" and it isn't even clear if they mean the kernel, some driver, or userland code. There's nothing any party can do to remove any violating code until they know what it is.
Since SCO is playing games like not simply telling Linus what code needs to be removed from the Linux kernel, then that is enough to earn all the dissing they are getting. In a normal case, they would say what it is they are concerned about, instead of trying to destroy the overall credibility. If their complaint is legitimate, they could show it, and have the code removed. It's almost like Microsoft put them up to this. That's why SCO's name is forever known as mud to me and millions of others, now.
Apple is missing a marketing opportunity. Surely they know they have a miniscule part of the desktop market (Linux passed Mac over two years ago in number of deployed units). Obviously tying this service to the Mac is part of the strategy to bolster that market share. But the one thing that is missing is the ability to let those who don't (yet) own a Mac to browse. By making the web site so that everyone else can see what is available ... e.g. what they are missing by not having a Mac ... they could end up selling more Macs.
Of course a marketing droid would never think of the obvious.
And be sure to boycott any business or ISP that refuses to take all the appropriate steps. And don't listen to their whining about collateral damage, since they can avoid that by doing the right things with their mail servers.
Including trolls. I really wouldn't worry too much about it. Those who don't consider it important enough to read it all wouldn't contribute much, anyway. But thank you for doing so.
Basically
I'm sure the content provider industry would want it that way. Of course I'd prefer to be able to process the video and audio in software and do some clever things, too. But the more you can do this, the more likely the chance it can leak a copy. And the industry would surely know this by now. So based on their motivations, having everything in hardware would be a sweet deal.
Most of those features are things you need to do on your own creations, as opposed to the latest blockbuster movie, or the number one hit song, which the content provider would rather you not touch.
I think a video card could be instructed to insert the video into specified coordinates or under an alpha mask.
I would expect the DRM decoder would just be another source for the "mixer" component of the system. The only catch is it would be at a point where you would not be able to capture the results. That might mean two mixers, the first of which allows a buffer re-capture, but then that is fed to the 2nd one which does not, and only feeds to the DACs.
Your need an API that allows you to play the sound components. The game company would perhaps have to get a distributable license that allows that particularly encrypted version of the sound to be played (obtained by the usualy channels via the Harry Fox Agency). Or perhaps the game itself might be forced to issue time licenses by the content industry. Or buy all the rights to that music and own it yourself (expensive). I'm not saying I like these things, but rather, that this is a model they could do which I think would be the lesser of evils.
What the media content providers want to ensure is that you, the human being, can hear/see the content, without there being a way for you to actually copy it to allow others to hear/see that content, or even for you to hear/see it at some later time frame or more than a specified (e.g. paid for) number of times. Whether we agree with their right to do that or not, that is a general description of their goal (or at least for many of them).
No protection will be perfect, of course. If you can hear it, you can record it from a microphone. If you can see it, you can record it from a camera. But as we know from past articles on Slashdot and elsewhere, even these techniques of copying are targets of efforts to prevent recordability. If you succeed at such recording, perhaps at least these methods will have forced a degradation of quality in that recording (e.g. while working to strip out any watermarking, you also damage the quality).
What the content providers particularly loath, however, is the ability to have direct access to the content digitally. If you have that, you can copy that as is, and play it back at a different time or place or in front of a different audience or multiple times. The primary means of preventing this is encryption. But at some point it has to be decrypted. At that point you then find the content in the clear. One aspect of DRM is to deploy a "sealed box" wherein the decryption can take place, yet the user cannot get access to the clear content. Windows can potentially do this due to its closed and proprietary nature. It won't be perfect, but most people will not have any idea how to bypass DRM. There is the potential to distribute software to do it that anyone can use, but certainly we can expect DRM in cooperation with Windows itself to make it hard for unsigned (by Microsoft) software to have access at the level needed to get at the clear content. For example, Windows with DRM will probably refuse to allow you to install your own sound card driver since that is one place where the clear content will be going through.
Linux could certainly have DRM code integrated into it. But because it is open source, and you can build your own kernel, this is a much harder black box to implement. From the point of view of content providers, Linux is a hazardous environment (so is BSD).
Linux supports loading modules which might be available only in object form. There are such modules already available commercially, such as for certain video cards. Some of us love them (because the cards are awesome) or hate them (because the modules are buggy, perhaps with new kernel versions, and cause crashes that would otherwise not be the norm in Linux). But when it comes right down to it, we can add new code to the kernel to work around all the interfaces the module is using. For a device driver, the hard aspect will be seeing what it actually does with the device at the register level. But a DRM black box would be something quite different, since it would need to be able to use existing sound card or video/TV card drivers. That opens the potential to wedge a tap in between DRM and the drivers (or even replace the driver with your own), which Linux would allow and Windows would not so easily. And don't think the media content providers don't know this (they have been getting a lot of hard technical lessons the past few years).
But it can still be possible to have DRM with Linux. One approach is to put the DRM directly in the device driver. That would help, but wouldn't be perfect since other code can be present in the kernel to get cozy with what the DRM is doing. The big problem is getting all the device manufacturers to make a Linux driver.
Perhaps the best (from a practical perspective, were the content providers ever to realize this) way is to put DRM directly in the hardware. That's about as sealed up as you can get. I'll explain how this can work in terms of music in an encrypted MP3 format, but you can extrapolate it in terms of other media or
Thanks for the info. I'm not sure yet what form those fixes are in, but personally I would prefer a kernel patch. If I don't find what I like, I'll probably make my own. The ability to set the default TTL certainly should be an administrator choice. Being able to do so for NAT-ted packets would, in my opinion, all be part of the intent to present a different appearance than would actually exist. My preference in Linux would be for some /proc entries to do this, one for default TTL of packets originating locally, one for NAT-ted packets, one for routed packets, and finally even one for bridged packets recognized as IP. The latter 3 should also allow a + or - designator to simply allow adding or subtracting a specified amount to the TTL. I don't believe such a thing should require a process running to do, and I don't see why /proc can't be used to set the policy, as it already can do for many other things, like turning on routing.