My major concern with such a system (besides the obvious privacy ones touched on in the article) is what happens when some other user sits at my comptuter uses it for a while. Would the "adaptive engine" or whatever be smart enough to figure out that there was someone else there or would I have to reset my settings and have it relearn everything?
Another interesting aspect would be as a constant check to make sure the allowed user is the one at tthe keyboard. Different enough input stats and the password box pops up.
Some usefull information (although not as clearly laid out as I would like) can be found at on x.org's freedesktoppage.
Basically, they say that it started out as XFree86 4.4 RC2, and was started because the new XFree86 license may possibly be incompatible with the GPL. Since then, they have continued to improve the code, so it should be better than the version it split from. Of course, I can only imagine that xfree has been developed to about the same amount, but I don't know the exact differences. There is a changelog at the link I gave.
I don't think there are drastic performance differences between the two versions yet, although aparently work is underway to improve performance in some things that were badly implimented in xf86-4.3.
At this point, I would say that unless you are obsessed about having the latest version of everything, want to try out the new, or have run into one of the specific bugs that is fixed, I wouldn't recommend updating. But the next time you would otherwise update to a new version of XF86, I would go ahead and switch to x.org. It's definately not worse, and it seems to be the future of X on linux for time being. For all new installs I would install x.org.
That said, I just ran "emerge -C xfree" "emerge xorg-x11" so I guess I'll find out if it's worth it (in about a day when it finally finishes compiling).
The article clearly states that you have to have the same version of GCC. For some reason I read it as distCC, hence the comment about different versions of GCC causing problems.
While distCC is a great tool, there are a couple things to mention. First, the article blurb states that distCC is "a distributed compiler based on GCC." It is actually a method of passing files to GCC on a remote computer in such a way that the build scripts think it was done locally.
The article also says that other than distCC, the computers need not have anything in common; this is not strictly true. Different major versions of GCC can cause problems if you are trying to compile with optimization flags that are only on the newer version. I have run into this on my gentoo box, trying to use an outdated version of GCC on a redhat box.
Another thing is that some very large packages have trouble with distributed building of any sort (either multiple threads on the same machine, or over a network like with distCC). As far as I know, at least parts of xfree86, KDE and the kernel turn off distributed compiling during the build. Some of this might just be in the gentoo ebuilds, but I tink some of it is in the actual Makefiles. If a program has trouble compiling, it's always worth a shot to turn off distCC.
A good resource for setting up distCC on a gentoo system (since compiling is so large of gentoo, this is particularly important) is gentoo.org's own distCC guide
When I was at college you could fire up iTunes and easily discover 50 other people with it running at any time. The network wasn't negatively affected.
In a network of that size (2000+ computers), the traffic generated by both zeroconf and UPnP and was neglegible, much more was generated by the popular DirectConnect hub (although admittadly, most of that was unicast, and thus switched) or regular web traffic.
I would regularly watch incoming packets with ethereal, and since the network was fully switched, the only packets that came through were either for me or were multicast. There was always a fair amount of traffic, however, the only time there was a very large amount of packets (and also the only time the network slowed down noticably) was when the latest virus hit all the windows boxes that people hadn't updated.
I should have specified that I raise POP, because we have very limited bandwidth, and when it gets maxed out, the users get much more angry about having their email say it cannot find the server than anything else being a bit slower. Mail coming and going to/from the mail server has lowish priority, but extenal POP and SMTP have higher because dropped email connections was the bigest complaint by far.
While MAC addresses would provide a way for ISPs to uniquely ID servers, it wouldn't prove was using the service. All the manufacturer ID would tell them is for example, that the server was using an Intel network card. Certain MAC addresses could be given lower priority, but if a large infrastructure company were providing the connectivity on a round-robin system, there is no gaurentee that such action wouldn't also downgrade a bunch of unrelated sites/services. Also, the overhead required to do this could quite quickly become cost prohibitive. Think how many more resources it would take to inspect each packet for several different criteria and prioritize it differently based on the results than just letting most things through unchecked, and perhaps lowering the priority of things that are easily flagged.
Some priority checking is already in wide use; I use it on the LAN I run to raise the priority of email and DNS queries over web traffic/FTP-data, and SSH/Telnet/FTP-control over both. This type of prioritizing is actually a Good Thing, because it makes letency-sensitive services run better without noticably hurting other traffic. But that's a far cry from deliberately making your competitors's services run badly.
Of course, the best way to keep companies from doing this is to speak with our money. But the truth of the matter is that the average user won't know enough to realize why their fancy new VoIP isn't working well. They'll just write it off as another failed internet idea that only the nerds will use. Hopefully VoIP will become popular enough before this type of thing is implimented that people will expect good service, but it seems like people are much more willing to accept shoddy service and bad reliability with technology than with just about anything else that is so pervasive in daily life.
It seems to me that all one would have to do to get around this is to use SSL. ISPs wouldn't be able to lower the priority of such communications without affecting many other applications, such as VPNs. They could still do it based on IP, but not if the providers of a service used some large provider like Akamai.
Anyway, regardless of whether it could be circumvented, and at what cost, the implication is still a further push away from the original spirit of the internet towards a network that is solely a means of extracting as much revenue from consumers as possible. I just wish it were more realisitc to create an ad-hoc network with all my friends...and their friends, etc. I think some day that is what the tech community will be forced to turn to someday, in order to retain the usability we have come to cherish.
Of couse keeping this theoretical peer network free and uncommercial would be very tough, if it got popular. Call me paranoid, but I'm looking into affordable methods of connecting my friends directly together, using wireless technology and encryption.
Last December alone, the town of Honeydew received over 100 inches IN ONE MONTH
The year of La Nina my house (in the Santa Cruiz Mtn. Redwoods) got 87in. of rain in two weeks. But that was unusual, I think we usually don't get more than 90 a year.
Despite the natural reaction to such a thread (I mean who doesn't want to bash the recording industry?) the fact of the matter is that studios are still very expensive. Add to Protools (which, in the configurations I've worked with, could easily cost over $30,000) all the other gear, and a studio can easily cost in the 100s of thousands to build. A good recording engineer isn't cheap either, nor is a good mixdown engineer. The best mixdown engineers cost several hundred an hour. All the design for the cover, etc. isn't free either, nor is mastering, nor are musicicans, for that matter. That, and as the parent post stated, there are many costs that aren't related to the production.
All but the most popular albums don't even make much money (for the artests at least), where they make their money is off radio-play, which goes to the artists, not the label. But even this isn't free - you need a publicist to get your work out.
All in all, the buisness isn't as easy as sitting down in front of a computer with some software. There is a complex set of variables, and making the statement that with the advent of ProTools, albums should cost less is a gross oversimplification.
As for the scamming, it's done to everyone who doesn't project an air of hollier than thou condescension that will burn the face off of the trangressor with a single glance...
I wish you luck in developing said aura, I certainly haven't had any luck getting it going on demand 8(
The ominous black trench-coat look usually works for me. In fact, customers tend to ask me questions, rather than asking the sales people.
Bah. If your post were anything other than mindless trash, it would have some points that could be backed up. But since all you seem to be interested in is flaming a perfectly good OS, I guess that's too much to hope for.
I used BSD back in the days of 4.0, and it was solid then - I'm sure it's even better now.
Slashdot Mirror
My major concern with such a system (besides the obvious privacy ones touched on in the article) is what happens when some other user sits at my comptuter uses it for a while. Would the "adaptive engine" or whatever be smart enough to figure out that there was someone else there or would I have to reset my settings and have it relearn everything?
Another interesting aspect would be as a constant check to make sure the allowed user is the one at tthe keyboard. Different enough input stats and the password box pops up.
Some usefull information (although not as clearly laid out as I would like) can be found at on x.org's freedesktop page.
Basically, they say that it started out as XFree86 4.4 RC2, and was started because the new XFree86 license may possibly be incompatible with the GPL. Since then, they have continued to improve the code, so it should be better than the version it split from. Of course, I can only imagine that xfree has been developed to about the same amount, but I don't know the exact differences. There is a changelog at the link I gave.
I don't think there are drastic performance differences between the two versions yet, although aparently work is underway to improve performance in some things that were badly implimented in xf86-4.3.
At this point, I would say that unless you are obsessed about having the latest version of everything, want to try out the new, or have run into one of the specific bugs that is fixed, I wouldn't recommend updating. But the next time you would otherwise update to a new version of XF86, I would go ahead and switch to x.org. It's definately not worse, and it seems to be the future of X on linux for time being. For all new installs I would install x.org.
That said, I just ran "emerge -C xfree" "emerge xorg-x11" so I guess I'll find out if it's worth it (in about a day when it finally finishes compiling).
Um...Can I mod myself down -1 Idiot?
The article clearly states that you have to have the same version of GCC. For some reason I read it as distCC, hence the comment about different versions of GCC causing problems.
I stand by my other points
While distCC is a great tool, there are a couple things to mention. First, the article blurb states that distCC is "a distributed compiler based on GCC." It is actually a method of passing files to GCC on a remote computer in such a way that the build scripts think it was done locally.
The article also says that other than distCC, the computers need not have anything in common; this is not strictly true. Different major versions of GCC can cause problems if you are trying to compile with optimization flags that are only on the newer version. I have run into this on my gentoo box, trying to use an outdated version of GCC on a redhat box.
Another thing is that some very large packages have trouble with distributed building of any sort (either multiple threads on the same machine, or over a network like with distCC). As far as I know, at least parts of xfree86, KDE and the kernel turn off distributed compiling during the build. Some of this might just be in the gentoo ebuilds, but I tink some of it is in the actual Makefiles. If a program has trouble compiling, it's always worth a shot to turn off distCC.
A good resource for setting up distCC on a gentoo system (since compiling is so large of gentoo, this is particularly important) is gentoo.org's own distCC guide
When I was at college you could fire up iTunes and easily discover 50 other people with it running at any time. The network wasn't negatively affected.
In a network of that size (2000+ computers), the traffic generated by both zeroconf and UPnP and was neglegible, much more was generated by the popular DirectConnect hub (although admittadly, most of that was unicast, and thus switched) or regular web traffic.
I would regularly watch incoming packets with ethereal, and since the network was fully switched, the only packets that came through were either for me or were multicast. There was always a fair amount of traffic, however, the only time there was a very large amount of packets (and also the only time the network slowed down noticably) was when the latest virus hit all the windows boxes that people hadn't updated.
I should have specified that I raise POP, because we have very limited bandwidth, and when it gets maxed out, the users get much more angry about having their email say it cannot find the server than anything else being a bit slower. Mail coming and going to/from the mail server has lowish priority, but extenal POP and SMTP have higher because dropped email connections was the bigest complaint by far.
While MAC addresses would provide a way for ISPs to uniquely ID servers, it wouldn't prove was using the service. All the manufacturer ID would tell them is for example, that the server was using an Intel network card. Certain MAC addresses could be given lower priority, but if a large infrastructure company were providing the connectivity on a round-robin system, there is no gaurentee that such action wouldn't also downgrade a bunch of unrelated sites/services. Also, the overhead required to do this could quite quickly become cost prohibitive. Think how many more resources it would take to inspect each packet for several different criteria and prioritize it differently based on the results than just letting most things through unchecked, and perhaps lowering the priority of things that are easily flagged.
Some priority checking is already in wide use; I use it on the LAN I run to raise the priority of email and DNS queries over web traffic/FTP-data, and SSH/Telnet/FTP-control over both. This type of prioritizing is actually a Good Thing, because it makes letency-sensitive services run better without noticably hurting other traffic. But that's a far cry from deliberately making your competitors's services run badly.
Of course, the best way to keep companies from doing this is to speak with our money. But the truth of the matter is that the average user won't know enough to realize why their fancy new VoIP isn't working well. They'll just write it off as another failed internet idea that only the nerds will use. Hopefully VoIP will become popular enough before this type of thing is implimented that people will expect good service, but it seems like people are much more willing to accept shoddy service and bad reliability with technology than with just about anything else that is so pervasive in daily life.
It seems to me that all one would have to do to get around this is to use SSL. ISPs wouldn't be able to lower the priority of such communications without affecting many other applications, such as VPNs. They could still do it based on IP, but not if the providers of a service used some large provider like Akamai.
Anyway, regardless of whether it could be circumvented, and at what cost, the implication is still a further push away from the original spirit of the internet towards a network that is solely a means of extracting as much revenue from consumers as possible. I just wish it were more realisitc to create an ad-hoc network with all my friends...and their friends, etc. I think some day that is what the tech community will be forced to turn to someday, in order to retain the usability we have come to cherish.
Of couse keeping this theoretical peer network free and uncommercial would be very tough, if it got popular. Call me paranoid, but I'm looking into affordable methods of connecting my friends directly together, using wireless technology and encryption.
Of course if all of /. pounds that mirror we'll all get about 2k/s...if it doesn't get totally /.ed.
So fix it. Or can you do less than that 14 year-old?
Last December alone, the town of Honeydew received over 100 inches IN ONE MONTH
The year of La Nina my house (in the Santa Cruiz Mtn. Redwoods) got 87in. of rain in two weeks. But that was unusual, I think we usually don't get more than 90 a year.
Despite the natural reaction to such a thread (I mean who doesn't want to bash the recording industry?) the fact of the matter is that studios are still very expensive. Add to Protools (which, in the configurations I've worked with, could easily cost over $30,000) all the other gear, and a studio can easily cost in the 100s of thousands to build. A good recording engineer isn't cheap either, nor is a good mixdown engineer. The best mixdown engineers cost several hundred an hour. All the design for the cover, etc. isn't free either, nor is mastering, nor are musicicans, for that matter. That, and as the parent post stated, there are many costs that aren't related to the production.
All but the most popular albums don't even make much money (for the artests at least), where they make their money is off radio-play, which goes to the artists, not the label. But even this isn't free - you need a publicist to get your work out.
All in all, the buisness isn't as easy as sitting down in front of a computer with some software. There is a complex set of variables, and making the statement that with the advent of ProTools, albums should cost less is a gross oversimplification.
The boys have started a petition stating that the signers will boycott American Greetings until the comic is allowed to be shown.
Let's show 'em what happens when slashdot readers get wind of something like this.
As for the scamming, it's done to everyone who doesn't project an air of hollier than thou condescension that will burn the face off of the trangressor with a single glance... I wish you luck in developing said aura, I certainly haven't had any luck getting it going on demand 8( The ominous black trench-coat look usually works for me. In fact, customers tend to ask me questions, rather than asking the sales people.
Bah. If your post were anything other than mindless trash, it would have some points that could be backed up. But since all you seem to be interested in is flaming a perfectly good OS, I guess that's too much to hope for.
I used BSD back in the days of 4.0, and it was solid then - I'm sure it's even better now.