How about some real images instead of some plug-in program? The web already supports image files, so there is no excuse for forcing flash on people. Once Firefox developers figure out how to display video, then we can finally get rid of flash.
... do the sharing connections through relay proxying. That way, the IP that has the shared content is not the same one connected to, to get it. In reality that's oversimplistic and the RIAA could pose as a relay to track the real source. But it would make things harder.
In addition to the reasons you listed, I also find that I can now "sample" the music, and figure out what I will, or will not, like ahead of time. BTI (before the internet), I would just have to buy a CD based on its cover art and music description in most cases. Now, I simply do not buy that which I know I will not like. That had cut my CD buying down to about 30% of what it used to be until I started doing the boycott of RIAA thing (which killed that last 30%).
While I don't fit in this category, and haven't for a long time, do keep in mind that teens tend to have less buying power than twenty-somethings, but are at least equally able to share. It's money the RIAA members would never have gotten, but might think (or wish) they would if they look at actual sharing activities levels.
I've already met a couple people that have downloaded more music than they could ever listen to in their lifetime (terabytes). They want the music not to listen to all of it, but rather, to have it on hand quickly in case they do want to, or just to beat out their peers in seeing who can download the most. It would not surprise me if the total amount of music downloaded by everyone in the USA, translated to actual purchases, were to approach or even exceed the US GDP.
What may be going on is that the substituted ads only appear on web sites that contract with NebuAD to do this. The advantage to those web sites is they can make the ads more focused on your interests, which lets them get more ad clicks, and they split some of that increased revenue with NebuAD, which in turn splits some of it with your ISP for their part in doing the tracking of your interests. It's the tracking that goes beyond the web sites using NebuAD. Otherwise they would not need to get your local ISP into the act. Without your local ISP involved, they can still track you to some degree by having the NebuAD partner web sites share the data about your visits within their site. But to track all of your web serfing, they have to do DPI via your ISP (or by the previous methods which involved spyware on your computer).
I don't know if they plan to go beyond that and actually insert or modify ads on other web sites. If they do, then we do need to get the DMCA hammer out and use it hard. Cable companies are already aware of Mona's hammer:-)
It might still be useful to use the DMCA on the privacy invasion aspect of this. Any content acquired through DPI, if passed on to another party, does represent real copying of that content. It would be a hard case to argue, but maybe a really skilled lawyer could make the case stick. Note that while what you send to a web site could be copyrighted by you (and imply a licensed to the web site you send it to, to use it to deliver requested results), what that web site sends back can be copyrighted by them. So they may need to be in on the legal case.
One possibility is that a web site that uses another service for ads may end up having more focused ads (instead of having them inserted by your ISP) simply by that ad provider partnering with NebuAD. What is important is for us to come to understand exactly what is going on with all of this.
I can understand their thinking that this enhances the user experience. Browsers alone have typically provided a poor description of problems when there is a DNS lookup failure. It's adequate, and quite technically correct, for us geeks. But for the masses, it does leave them confused. For similar reasons, mail servers send back elaborate bounce messages for non-deliverable email, rather than just give a standard SMTP rejection code with a text string (which then leads to so much backscatter). The fix for the mail server is for the sender's server that gets the SMTP rejection to be more descriptive in a dumbed-down way for the average user (while still including the exact string received, and the DNS lookup chain to get there, for us geeks). The fix for web site access failures is for the browser, or the proxy server in the case of access through a proxy that you (or your admin at work) chose to access, to provide a more descriptive result page explaining what happened, links to pages that explain the technology (like "what's this?" for "DNS"), and even a comparison for similar domain names in your browsing history (did you mean "slashdot.org" when you typed in "sllashdot.org"). It could even correct common misspellings and typos and offer those as links.
I can't see the result from Charter (and I guess it's not yet deployed). I'm curious if it will be helpful in ways described above.
I'm also curious if they will affect subdomain/hostnames of domains that otherwise do exist, but give an NXDOMAIN result. If so, then they can really get into hot water because there would be an identifiable owner of the non-existant name. But they might well blindly do this by substituting any NXDOMAIN result with the A record pointing to their site.
And... using cookies is a STUPID way to opt out. Lots of people already block cookies on all sites by default, and only allow them on specific sites. That would be asking them to make their web surfing LESS secure, and thus a DEGRADED experience. Us geeks know how to change the DNS servers we do lookups through (and if they intercept that traffic, that's more hot water for them). Web browsers should provide a way to change what DNS servers it uses, too, overriding the configuration on the machine (what the ISP provided in many cases).
I know that even a lot of geeks don't have this ability (yet). But if you have a dedicated server, or even a remote shell account with significant bandwidth rights, you can pipe all your web surfing that way (so it doesn't become web "serfing"). The OpenSSH client has a -D option, or DynamicForward in the config file, which tells it to listen locally on a port and use the SOCKS protocol with whatever connects to make a connection through the SSH session that will come out from that server. Then just configure your browser to use that SSH forwarded port as a local proxy, and SOCKS as the proxy protocol. The server hosting company could spy on you, now, but not your cable/telco provider. There are some cheap virtual dedicated server hosting (as in, your server is a virtual machine under VMware, Xen, or such) plans many companies offer that may be good enough. You may be able to use almost any shell account access that has SSH access (who doesn't anymore) and sufficient bandwidth for your web ser^H^Hurfing.
BTW, if you set up a dedicated server for this purpose, I suggest starting a 2nd SSH server on port 993 or 995 and use that one for forwarded web access. That way it will just look like you are reading email (a lot of it).
This means shared web sites can't make the switch to HTTPS just yet. However, those web sites that own a specific IP address can do it. The more that at least begin to use or allow HTTPS, the better.
Right now if you visit Slashdot's HTTPS URL it redirects you back to clear HTTP. That's where we need to start changing things. Someone who specifically wants their web requests in HTTPS where it can be delivered, should get it.
At least my page delivers in HTTPS, even if it is just a self-signed certificate that causes the browser to ask if you want to do this. I need to get a real signed certificate soon.
I can only hope that it pushes more of the web to https.
That or to IPsec, or maybe both. They'll still at least see what IP address the traffic is going to, so they could still try to hussle the other site for some bandwidth favoritism money.
Maybe it's because they want to do more than just monitor traffic volumes. One of the potential evils of this thing is that it can, for non-encrypted traffic like web access, track your web visits, see what you like, and report the top ten keywords for you to their spammer partners.
With IPsec, they won't even be able to see what protocol is being used. The more we use IPsec for everything, the less these things will look like an attractive way to spend money that would otherwise go to expanding capacity.
The 360 series used normal two's complement arithmetic. Subtracting a negative number from itself would always result in zero. I believe the original problem was that in the case of X'80000000' being subtracted from itself, the program could be interrupted due to an overflow condition. That could be intercepted, but it was easier to just change to SLR.
Back when I was working on those machines (programming in ASM/370), someone noticed that IEFBR14 had been changed to use SLR and asked me why. I jokingly said it was because SLR operated one cycle faster than SR due to the way it produced the condition code, which was true for the most of the 360 series and the early 370 series. Amazing how many people accepted that back then.
It would be possible to make a means to discover where the base is without the need to have something inside the tree. You start by having a parallel tree with the meta data over there. Of course you have to know where that parallel tree begins, and there could be many schemes to find it. One is to have a specific name somewhere along the path to the current directory. That specific name is not the project base; it's just how to jump over to the parallel tree. Then from there the same relative path has the "local" meta data. From there you can get the project base the usual way. So you could have/home/me/src/projects/utilities/ljbackup/database and put the parallel meta data in/home/me/src/.svn-meta/projects/utilities/ljbackup/database. You just scan the current directory path downward (/home then/home/me then/home/me/src) until you find the.svn-meta directory. That's not the project base; it's just the meta parallel base. Now you know where in the current path, and any path relative to the current path, to insert/.svn-meta to find the meta data, instead of in the current tree. So if you would have had/home/me/src/projects/utilities/.svn you will now instead have/home/me/src/.svn-meta/projects/utilities/.svn to find the same data. That might even make it easier for SVN to figure out when you do moves of whole directories, which it currently handles badly because that also moves the.svn directory which then gets confused because it now has a misperception of what the repository contains.
This is what I had in mind. I didn't say we can't have any meta info at all. Instead, I just want the tree itself to be completely clean, and hold the meta info somewhere else, such as another parallel tree. And it could be made easy enough to find it with a simple rule: search up the path of parent directories until a directory with a specific name (such as ".svn-meta" as in your example) is found. It might usually be placed in the user home directory. It would apply to all projects that have different bases. So if you have ~/project7 and ~/oldprojects/project2 as bases for two separate projects, and you create ~/.svn-meta for the meta tree, then ~/.svn-meta/project7 and ~/.svn-meta/oldprojects/project2 would be where to find the meta data.
There would still be issues with doing moves of directories in the project. But that has caused SVN to get confused even the way it does it now (I've had to revert projects several times just clear up issues from SVN getting confused). A better system would simply figure out what I've done to change my clean tree, and apply that when I check it back in. If I move stuff around, it can either waste the bandwidth and transfer it back to the repository all over again relative to the new place and "delete" the old location, or it can checksum all the files and initially tell the repository what checksum is where, and the repository can simply update references to reflect the new arrangement (and potentially even save space by not-duplicating duplicate files).
I also need symlink and hardlink support, which SVN does not have. And the symlinks might be lame/dangling (e.g. where they point to might not have anything there, and might even be invalid as a file name). And I need devices and pipes for some things I could use revision control for. I just don't (for now, anyway) need the highly de-centralized stuff.
If all the effort that has been put into x86 had instead been put into another architecture that was cleaner to begin with, and designed specifically for being able to migrate to 64 bit, who's to say we wouldn't be even better off than we are now with the x86 ancestry?
Sure, I agree, we've made x86 work well. But we are comparing a processor that has had a tremendous focus to a few alternatives that have had much less focus in terms of bringing them up to speed.
There is what I refer to as "the x86 cost". The "ugly" architecture often means that people have to spend more time figuring out things in it due to the many layers of improvements that have been done. It makes life far more complicated for those that have to work at the "bare metal" level.
One excuse often made to justify upgrading an architecture is the need for compatibility. The suggestion I made back when 64-bit was being talked about was to go with a dual processor compatibility setup, where you have both the old 32-bit processor, and an all new 64-bit processor, side-by-side in the same machine. The oldest operating systems would just ignore the new processor. New operating systems would run on the new processor and manage the old processor like a virtual machine (so you can still run the old OS at the same time). As this migration proceeds, hardware vendors would begin making the machines with the 32-bit CPU optional. Eventually, it would be gone and the space used for a 2nd 64-bit processor. There's your compatibility.
... management system right now. One problem is, Subversion won't work because I need to have totally clean checkout trees. Subversion inserts tracking files in the checkout trees. So I guess I have to look for something else.
And what of the legal process when that happens? Is it a void notice if it got returned? I know if something like that happened to me (in the USA), I would have not paid and just ignored it, regardless of who it came from (I don't know if they let you know who it came from before having to decide to pay).
The other thing is the time frame issue. At least here, any legal notice sent in the mail has to be sent recorded/certified, and any time frames to respond have to begin when the mail is delivered. If I refused to sign for that mail, it would eventually have been returned to them, and they would have had to retry or send a process server to give me their notice for it to be valid.
Is it ok to chastise Asus for denying customers the choice of OS independent of HDD size? Yes. Is it ok to wig out and claim that Microsoft is cutting deals with Asus to insure the downfall of Linux? No. You're wasting your time--spend it more constructively coding open source or lobbying for your company to use open source.
Why do you believe that Asus is not doing the OS choice denial on account of a deal with Microsoft? While I don't really know if there is such a deal or not, I must point out that virtually nobody knows what deals go on between corporations, legal or illegal. That means I will still consider that it is possible, and plausible, that such a deal took place. Is such a deal legal or illegal? IANAL so I can't say. I am in the USA, and I have no clue about AUS law. If this were an issue in the USA I might say "maybe it is legal".
Assuming there is such a deal (since we don't know there is not, assumption is about all way have to go on), and assuming it is legal (this is where I know less about it so I'm assuming worst case here), it is still something worthy of complaining about.
FYI, I already code open source and my company already uses it, as does my previous company. But, thanks for the tip on using Ubuntu 8.04 with an iPod Shuffle. All the more reason to hurry up and install it (I have all the ISOs downloaded, so I just need to get the other computer ready).
Slashdot Mirror
... you might want to read more here.
This kind.
And also high dynamic range.
How about some real images instead of some plug-in program? The web already supports image files, so there is no excuse for forcing flash on people. Once Firefox developers figure out how to display video, then we can finally get rid of flash.
If it's your content, and you offer it, then where is the violation if the anyone downloads it?
... do the sharing connections through relay proxying. That way, the IP that has the shared content is not the same one connected to, to get it. In reality that's oversimplistic and the RIAA could pose as a relay to track the real source. But it would make things harder.
In addition to the reasons you listed, I also find that I can now "sample" the music, and figure out what I will, or will not, like ahead of time. BTI (before the internet), I would just have to buy a CD based on its cover art and music description in most cases. Now, I simply do not buy that which I know I will not like. That had cut my CD buying down to about 30% of what it used to be until I started doing the boycott of RIAA thing (which killed that last 30%).
While I don't fit in this category, and haven't for a long time, do keep in mind that teens tend to have less buying power than twenty-somethings, but are at least equally able to share. It's money the RIAA members would never have gotten, but might think (or wish) they would if they look at actual sharing activities levels.
I've already met a couple people that have downloaded more music than they could ever listen to in their lifetime (terabytes). They want the music not to listen to all of it, but rather, to have it on hand quickly in case they do want to, or just to beat out their peers in seeing who can download the most. It would not surprise me if the total amount of music downloaded by everyone in the USA, translated to actual purchases, were to approach or even exceed the US GDP.
That depends.
What may be going on is that the substituted ads only appear on web sites that contract with NebuAD to do this. The advantage to those web sites is they can make the ads more focused on your interests, which lets them get more ad clicks, and they split some of that increased revenue with NebuAD, which in turn splits some of it with your ISP for their part in doing the tracking of your interests. It's the tracking that goes beyond the web sites using NebuAD. Otherwise they would not need to get your local ISP into the act. Without your local ISP involved, they can still track you to some degree by having the NebuAD partner web sites share the data about your visits within their site. But to track all of your web serfing, they have to do DPI via your ISP (or by the previous methods which involved spyware on your computer).
I don't know if they plan to go beyond that and actually insert or modify ads on other web sites. If they do, then we do need to get the DMCA hammer out and use it hard. Cable companies are already aware of Mona's hammer :-)
It might still be useful to use the DMCA on the privacy invasion aspect of this. Any content acquired through DPI, if passed on to another party, does represent real copying of that content. It would be a hard case to argue, but maybe a really skilled lawyer could make the case stick. Note that while what you send to a web site could be copyrighted by you (and imply a licensed to the web site you send it to, to use it to deliver requested results), what that web site sends back can be copyrighted by them. So they may need to be in on the legal case.
One possibility is that a web site that uses another service for ads may end up having more focused ads (instead of having them inserted by your ISP) simply by that ad provider partnering with NebuAD. What is important is for us to come to understand exactly what is going on with all of this.
I can understand their thinking that this enhances the user experience. Browsers alone have typically provided a poor description of problems when there is a DNS lookup failure. It's adequate, and quite technically correct, for us geeks. But for the masses, it does leave them confused. For similar reasons, mail servers send back elaborate bounce messages for non-deliverable email, rather than just give a standard SMTP rejection code with a text string (which then leads to so much backscatter). The fix for the mail server is for the sender's server that gets the SMTP rejection to be more descriptive in a dumbed-down way for the average user (while still including the exact string received, and the DNS lookup chain to get there, for us geeks). The fix for web site access failures is for the browser, or the proxy server in the case of access through a proxy that you (or your admin at work) chose to access, to provide a more descriptive result page explaining what happened, links to pages that explain the technology (like "what's this?" for "DNS"), and even a comparison for similar domain names in your browsing history (did you mean "slashdot.org" when you typed in "sllashdot.org"). It could even correct common misspellings and typos and offer those as links.
I can't see the result from Charter (and I guess it's not yet deployed). I'm curious if it will be helpful in ways described above.
I'm also curious if they will affect subdomain/hostnames of domains that otherwise do exist, but give an NXDOMAIN result. If so, then they can really get into hot water because there would be an identifiable owner of the non-existant name. But they might well blindly do this by substituting any NXDOMAIN result with the A record pointing to their site.
And ... using cookies is a STUPID way to opt out. Lots of people already block cookies on all sites by default, and only allow them on specific sites. That would be asking them to make their web surfing LESS secure, and thus a DEGRADED experience. Us geeks know how to change the DNS servers we do lookups through (and if they intercept that traffic, that's more hot water for them). Web browsers should provide a way to change what DNS servers it uses, too, overriding the configuration on the machine (what the ISP provided in many cases).
I know that even a lot of geeks don't have this ability (yet). But if you have a dedicated server, or even a remote shell account with significant bandwidth rights, you can pipe all your web surfing that way (so it doesn't become web "serfing"). The OpenSSH client has a -D option, or DynamicForward in the config file, which tells it to listen locally on a port and use the SOCKS protocol with whatever connects to make a connection through the SSH session that will come out from that server. Then just configure your browser to use that SSH forwarded port as a local proxy, and SOCKS as the proxy protocol. The server hosting company could spy on you, now, but not your cable/telco provider. There are some cheap virtual dedicated server hosting (as in, your server is a virtual machine under VMware, Xen, or such) plans many companies offer that may be good enough. You may be able to use almost any shell account access that has SSH access (who doesn't anymore) and sufficient bandwidth for your web ser^H^Hurfing.
BTW, if you set up a dedicated server for this purpose, I suggest starting a 2nd SSH server on port 993 or 995 and use that one for forwarded web access. That way it will just look like you are reading email (a lot of it).
Now it's web serfing.
This means shared web sites can't make the switch to HTTPS just yet. However, those web sites that own a specific IP address can do it. The more that at least begin to use or allow HTTPS, the better.
Right now if you visit Slashdot's HTTPS URL it redirects you back to clear HTTP. That's where we need to start changing things. Someone who specifically wants their web requests in HTTPS where it can be delivered, should get it.
At least my page delivers in HTTPS, even if it is just a self-signed certificate that causes the browser to ask if you want to do this. I need to get a real signed certificate soon.
That or to IPsec, or maybe both. They'll still at least see what IP address the traffic is going to, so they could still try to hussle the other site for some bandwidth favoritism money.
Maybe it's because they want to do more than just monitor traffic volumes. One of the potential evils of this thing is that it can, for non-encrypted traffic like web access, track your web visits, see what you like, and report the top ten keywords for you to their spammer partners.
OTOH, IPsec can deprive them of knowing the port number and few other things.
With IPsec, they won't even be able to see what protocol is being used. The more we use IPsec for everything, the less these things will look like an attractive way to spend money that would otherwise go to expanding capacity.
The 360 series used normal two's complement arithmetic. Subtracting a negative number from itself would always result in zero. I believe the original problem was that in the case of X'80000000' being subtracted from itself, the program could be interrupted due to an overflow condition. That could be intercepted, but it was easier to just change to SLR.
Back when I was working on those machines (programming in ASM/370), someone noticed that IEFBR14 had been changed to use SLR and asked me why. I jokingly said it was because SLR operated one cycle faster than SR due to the way it produced the condition code, which was true for the most of the 360 series and the early 370 series. Amazing how many people accepted that back then.
Is that supposed to be a pun :-)
I guess you mean this project. That does look interesting. Thanks!
It would be possible to make a means to discover where the base is without the need to have something inside the tree. You start by having a parallel tree with the meta data over there. Of course you have to know where that parallel tree begins, and there could be many schemes to find it. One is to have a specific name somewhere along the path to the current directory. That specific name is not the project base; it's just how to jump over to the parallel tree. Then from there the same relative path has the "local" meta data. From there you can get the project base the usual way. So you could have /home/me/src/projects/utilities/ljbackup/database and put the parallel meta data in /home/me/src/.svn-meta/projects/utilities/ljbackup/database. You just scan the current directory path downward (/home then /home/me then /home/me/src) until you find the .svn-meta directory. That's not the project base; it's just the meta parallel base. Now you know where in the current path, and any path relative to the current path, to insert /.svn-meta to find the meta data, instead of in the current tree. So if you would have had /home/me/src/projects/utilities/.svn you will now instead have /home/me/src/.svn-meta/projects/utilities/.svn to find the same data. That might even make it easier for SVN to figure out when you do moves of whole directories, which it currently handles badly because that also moves the .svn directory which then gets confused because it now has a misperception of what the repository contains.
This is what I had in mind. I didn't say we can't have any meta info at all. Instead, I just want the tree itself to be completely clean, and hold the meta info somewhere else, such as another parallel tree. And it could be made easy enough to find it with a simple rule: search up the path of parent directories until a directory with a specific name (such as ".svn-meta" as in your example) is found. It might usually be placed in the user home directory. It would apply to all projects that have different bases. So if you have ~/project7 and ~/oldprojects/project2 as bases for two separate projects, and you create ~/.svn-meta for the meta tree, then ~/.svn-meta/project7 and ~/.svn-meta/oldprojects/project2 would be where to find the meta data.
There would still be issues with doing moves of directories in the project. But that has caused SVN to get confused even the way it does it now (I've had to revert projects several times just clear up issues from SVN getting confused). A better system would simply figure out what I've done to change my clean tree, and apply that when I check it back in. If I move stuff around, it can either waste the bandwidth and transfer it back to the repository all over again relative to the new place and "delete" the old location, or it can checksum all the files and initially tell the repository what checksum is where, and the repository can simply update references to reflect the new arrangement (and potentially even save space by not-duplicating duplicate files).
I also need symlink and hardlink support, which SVN does not have. And the symlinks might be lame/dangling (e.g. where they point to might not have anything there, and might even be invalid as a file name). And I need devices and pipes for some things I could use revision control for. I just don't (for now, anyway) need the highly de-centralized stuff.
If all the effort that has been put into x86 had instead been put into another architecture that was cleaner to begin with, and designed specifically for being able to migrate to 64 bit, who's to say we wouldn't be even better off than we are now with the x86 ancestry?
Sure, I agree, we've made x86 work well. But we are comparing a processor that has had a tremendous focus to a few alternatives that have had much less focus in terms of bringing them up to speed.
There is what I refer to as "the x86 cost". The "ugly" architecture often means that people have to spend more time figuring out things in it due to the many layers of improvements that have been done. It makes life far more complicated for those that have to work at the "bare metal" level.
One excuse often made to justify upgrading an architecture is the need for compatibility. The suggestion I made back when 64-bit was being talked about was to go with a dual processor compatibility setup, where you have both the old 32-bit processor, and an all new 64-bit processor, side-by-side in the same machine. The oldest operating systems would just ignore the new processor. New operating systems would run on the new processor and manage the old processor like a virtual machine (so you can still run the old OS at the same time). As this migration proceeds, hardware vendors would begin making the machines with the 32-bit CPU optional. Eventually, it would be gone and the space used for a 2nd 64-bit processor. There's your compatibility.
... management system right now. One problem is, Subversion won't work because I need to have totally clean checkout trees. Subversion inserts tracking files in the checkout trees. So I guess I have to look for something else.
And what of the legal process when that happens? Is it a void notice if it got returned? I know if something like that happened to me (in the USA), I would have not paid and just ignored it, regardless of who it came from (I don't know if they let you know who it came from before having to decide to pay).
The other thing is the time frame issue. At least here, any legal notice sent in the mail has to be sent recorded/certified, and any time frames to respond have to begin when the mail is delivered. If I refused to sign for that mail, it would eventually have been returned to them, and they would have had to retry or send a process server to give me their notice for it to be valid.
You get what you pay for ... right?
Is it ok to wig out and claim that Microsoft is cutting deals with Asus to insure the downfall of Linux? No. You're wasting your time--spend it more constructively coding open source or lobbying for your company to use open source.
Why do you believe that Asus is not doing the OS choice denial on account of a deal with Microsoft? While I don't really know if there is such a deal or not, I must point out that virtually nobody knows what deals go on between corporations, legal or illegal. That means I will still consider that it is possible, and plausible, that such a deal took place. Is such a deal legal or illegal? IANAL so I can't say. I am in the USA, and I have no clue about AUS law. If this were an issue in the USA I might say "maybe it is legal".
Assuming there is such a deal (since we don't know there is not, assumption is about all way have to go on), and assuming it is legal (this is where I know less about it so I'm assuming worst case here), it is still something worthy of complaining about.
FYI, I already code open source and my company already uses it, as does my previous company. But, thanks for the tip on using Ubuntu 8.04 with an iPod Shuffle. All the more reason to hurry up and install it (I have all the ISOs downloaded, so I just need to get the other computer ready).