I suppose the sweet spot is somewhere between just under 1500 bytes, which always fits in a single packet in practice, and 64K, which gives you less overhead but more chance that a single packet will be lost somewhere and your chunk will be incomplete. It depends on the expected packet loss rate and the per-packet overhead. Or use big chunks by default, but if packet loss occurs step down to half the size adaptively. I guess the original poster was right: you do end up reinventing at least some higher-level protocol features on top of UDP.
Yeah, having to run as root is the biggest flaw in the way RPM and other package managers are typically set up. There needs to be some way for ordinary users to install software in their home directory - without having to drop down to 'make install' or ad hoc binary tarballs. That's kind of an independent issue to the choice between yum repository and single rpm though.
Do remember, though, that on any desktop system today having root permissions is not much more dangerous than running in the user's account. All the valuable data is in the user's home directory! So perhaps avoiding the root account is more of a nicety. I would like to see better locked down permissions for applications so they don't automatically run with the user's full permissions, but I'm not optimistic.
You are right. Adding third-party repositories that provide lots of packages and want to overwrite packages already on the system causes trouble. That's why I would like to see some concept of 'primary' and 'secondary' repositories, where the primary one is the normal package collection from your vendor, and secondary repositories are used only when you explicitly pick a package contained in one, in which case that package (and any dependencies it has outside the primary package collection) are pulled down from the secondary repository, but nothing else. Further, a secondary repository is not allowed to replace packages belonging to another repository, unless the user explicitly requests so.
Then you'd have some protection against repositories that try to borg your machine with all sorts of package updates. But anyway, that's not really the situation with third party applications, where there is one big binary package and then a small number of supporting libraries which are probably free software.
I think autopackage is good work, but creating another packaging format is misguided. I appreciate the reasons they have for reinventing something new rather than sticking with RPM, and I agree that the current RPM situation is not ideal, but in my opinion that doesn't outweigh the massive advantage of having _one_ package manager to deal with instead of N where N > 1. The same applies to ROX application directories and Zero Install, which are a lovely idea (app dirs, of course, have been around since the late 1980s) but again, doomed by trying to bypass the native package manager instead of integrating with it. I would greatly prefer to fix the real and perceived problems with RPM than to go off making another system which 10% of the free world adopts and the rest ignores.
If you think of things that add cost and hurt performance from an ISP perspective, total number of sessions is one of them. It increases the load on routers
Why is that? Surely the router doesn't care what is inside the IP datagrams it is sending from one place to another. Whether they are made of one TCP session between two hosts, or a hundred separate TCP sessions between those same two hosts, or they aren't TCP at all, should make no difference. Communicating with a large number of different hosts would need more space in the routing table, but it's unlikely to be a significant effect.
OK, fair enough. It would only be simple if a block were small enough to fit in a single UDP datagram. Still, perhaps this is what the uTorrent developers are doing?
Except that one of the cool things about UDP is that it doesn't have to get through, so your router can drop all it needs to if it starts saturating your bandwidth. UDP has no guarantee of reliability at all.
You could make the opposite argument: the cool thing about TCP is it automatically retries and resends any dropped packets, so your router can drop all TCP traffic if it needs to.
If you're going to transfer files over UDP then you need to build some TCP-like protocol on top of it.
Not really. You would need that if you were transferring a file from one computer to another. But Bittorrent scrapes together little bits of file from lots of other computers. If a packet is lost here and there, that bit of file is naturally requested again, probably from a different machine. That's just a consequence of the way Bittorrent works.
However, one thing to realize about P2P is that because there are often dozens of active TCP connections transmitting from one machine, fairness goes pretty much out the window anyway.
There's no reason in principle for this to be the case; obviously, metering of bandwidth should be by subscriber according to money paid, not by some arbitrary and easily manipulated value like number of open TCP connections.
I'll leave others to comment on the rest of the article but I liked this one nugget:
One thing that might help is a kind of meta-package format: a file which, when downloaded, is run by a client native to the given distribution. The client then goes to the software repositories for the program maker and obtains all the right packages to make that program run on that particular machine.
We have the LSB, and distributions which make some effort to ship binary 'compat' packages, so that third parties can distribute their software in RPMv3 format (n.b. not the same format as currently used by RPM-based distros, which are on RPMv4) and it will just install and work on any i386 or x86_64 Linux system. But I wonder if that is slightly the wrong model. At the moment if you want some particular library you have the choice of statically linking it into your executable, or just relying on it being there in the target system; neither is very appealing.
For example, suppose you want GTK version 2.16 or later but LSB specifies an older GTK (actually, it specifies a set of interfaces, but that corresponds to a particular GTK version). You could statically link your app with gtk-2.16, or you could include your own private copy of the library to be stuck in/opt/myapp/libs, but then what about Fedora 10 which does include a new enough GTK?
Instead of providing a single RPM (or worse, lots of different binary RPMs for different distros), we should encourage vendors to set up a yum repository. Then to install their software you could add the third-party's repository to your software sources list and use the normal GUI tools to update and install packages. If they want to use some newer library which is not included in Ye Olde Enterprise Linux 1.1, then they can just add a package for that library to the repository, and it will be installed only on systems that need it. This also takes care of automatic updates, which are not provided if you just give people an RPM file to install manually.
Of course, we don't live in a world where you can just 'encourage' third-party software vendors to do things and they'll jump to it; otherwise Nvidia would long ago have released free drivers. So you need to make it as easy as possible to set up a repository for yum or apt-get or smart or whatever packaging tool distros are using. It needs to be trivially easy. So I would suggest enhancing yum and the other tools to work from a plain directory of rpm files served over http. Just dump the files on a webserver, let Apache serve the directory listing and let yum point to that and Just Work. Or, if that's too dirty for you, use a directory on an ftp site (which at least has a defined protocol for listing the files available).
I think a repository for package management programs like yum satisfies what the author is talking about when he asks for a 'meta-package'.
The news here is not the existence of a software renderer, but one with good performance (such that a high-end CPU is competitive with a low-end GPU for some tasks). I wonder how the trusty Mesa GL renderer compares to Microsoft's latest offering? (They implement different APIs, but Wine provides DirectX 10 on top of OpenGL, so you can get an apples to apples comparison.)
Just because you've never used it, it doesn't mean that it was a waste of time. Most children who play association football at school never go on to become professional footballers (and most not even amateur ones). Does that mean that football and other school sports are a waste of time?
Cystic fibrosis only affects people who have cystic fibrosis, which is a tiny minority of the population (a much smaller minority than white men). So if they must choose a charity that represents the entire student body, it's clearly not suitable, since most of the students do not have CF and never will.
If that is their criterion, the only choice open to them is just to give the money back to the students. Any other use would be favouring one minority or another.
The synthetic benchmark running slowly is not the problem. What is worrying is that you can run the benchmark once and it somehow crufts up the drive so that all future operations run much more slowly. The only way to get back the original performance is a low-level reformat. That is the bug that Intel needs to fix.
The earlier model of Intel SSD had some serious performance degradation after a few hours of heavy use. (Article in French, but it says that after a ten minute torture with IOmeter writing small blocks to the drive, and even after waiting an hour for the drive to 'recover', performance drops by about 70%.) I wonder if they have fixed this bug with the new model?
Is there some reporting and analysis of this matter from a more impartial source than Groklaw? I'd love to believe what PJ writes, but the history of software patents is one of cleverly worded applications exploiting and widening every possible loophole to expand the scope of patentability. I think Groklaw is putting a very optimistic spin on this.
More importantly, part of the value of a game is its resale value. When people buy a car they take into account how much it's likely to be worth in three, five, ten years' time when they want to sell it. You'd be much more likely to stump up $50 for a game if you were pretty sure you could sell it for $30 on Ebay or Amazon a few months later. The game publishers should be encouraging this secondary market.
I suppose one difference is that there is no piracy of cars; you can sell it to another person and they now own it. You can do that with a video game too, but it's sooo tempting just to leave a backup copy on your own computer. If you accept the principle of copyright, which is that making a copy requires special permission and this is how the authors and publishers make money, then a market in 'secondhand' games which are really just pirate copies doesn't help the industry or, in the long run, encourage development of new games.
No, actually, line-based diff is almost entirely useless with written documents. You either have "soft" or "dynamic" word wrap (one line per paragraph), or "static" word wrap (newline on the end of each line). In the first case, a single change in a paragraph marks the *whole* paragraph as changed, and in the second case, a single change causes the paragraph to need to be re-wrapped and again the whole thing is marked as a change.
This is a good point. Strangely, in practice I have never found this to be a problem, but then, most version controlled documents have either been computer code which doesn't have reflowable paragraphs, or have been edited by few people at once. I wonder if Subversion (or Mercurial, or Git or Bazaar, etc) lets you plug in a different merging engine that would be more appropriate for prose?
Pardon me if I'm wrong but isn't subversion entirely line based?
Yes, it works with text files. (You can store binary files but they can't be merged automatically.) So that does make it unsuitable for documents saved from a word processor, unless you save in text format and add the formatting as the last step.
And you can't actually see the changes in place and highlighted.
Well, you can use all sorts of tools to show you the diffs. On Windows I use TortoiseSVN, which shows the two versions of a file with differences highlighted.
Have you tried using a version control system such as Subversion or Mercurial? You don't all see the same screen in real time, but it automatically coordinates changes that need to be merged in.
I don't know a single Windows user of Firefox who uses it because it's free, and IE is proprietary.
I can't be the only one, surely. But the very fact of being free is some advantage. For example, a free program can support options like 'save stream to disk' or 'block this advertisement' that proprietary software is unlikely to support for fear of upsetting vested interests. If you don't think there is any inherent advantage to free software, and the only criterion should be how well the program works when downloaded as an unchangeable binary blob, then as I said you might as well forget Silverlight and Moonlight, and just use Flash. Its market share is far higher. The biggest reason to be interested in Moonlight is as an open source alternative.
Moonlight is great but it's for Linux only. (Mono itself runs on Linux, Windows and Mac OS X.) That reduces its suitability for making dynamic websites, because Mac and Windows users don't have a free browser plugin to run them with. They only have Microsoft's proprietary Silverlight plugin, and if you're going to require a binary-only plugin then you might as well just use Flash. So I think a Windows version of Moonlight would be cool; just as many people prefer to run the free Firefox browser even though Windows includes the proprietary Internet Explorer, so Moonlight could provide a free alternative for dynamic content.
One commercial OS having patent deals with another commercial OS is fine with me. It is when they start infecting otherwise free software when I have a problem.
Surely Solaris (being free software otherwise) is tainted just as much as SuSE Linux by this? If you want to boycott companies that have a patent non-agression pact with Microsoft that's fine, but make sure you are not applying double standards.
Slashdot Mirror
I suppose the sweet spot is somewhere between just under 1500 bytes, which always fits in a single packet in practice, and 64K, which gives you less overhead but more chance that a single packet will be lost somewhere and your chunk will be incomplete. It depends on the expected packet loss rate and the per-packet overhead. Or use big chunks by default, but if packet loss occurs step down to half the size adaptively. I guess the original poster was right: you do end up reinventing at least some higher-level protocol features on top of UDP.
Yeah, having to run as root is the biggest flaw in the way RPM and other package managers are typically set up. There needs to be some way for ordinary users to install software in their home directory - without having to drop down to 'make install' or ad hoc binary tarballs. That's kind of an independent issue to the choice between yum repository and single rpm though.
Do remember, though, that on any desktop system today having root permissions is not much more dangerous than running in the user's account. All the valuable data is in the user's home directory! So perhaps avoiding the root account is more of a nicety. I would like to see better locked down permissions for applications so they don't automatically run with the user's full permissions, but I'm not optimistic.
You are right. Adding third-party repositories that provide lots of packages and want to overwrite packages already on the system causes trouble. That's why I would like to see some concept of 'primary' and 'secondary' repositories, where the primary one is the normal package collection from your vendor, and secondary repositories are used only when you explicitly pick a package contained in one, in which case that package (and any dependencies it has outside the primary package collection) are pulled down from the secondary repository, but nothing else. Further, a secondary repository is not allowed to replace packages belonging to another repository, unless the user explicitly requests so.
Then you'd have some protection against repositories that try to borg your machine with all sorts of package updates. But anyway, that's not really the situation with third party applications, where there is one big binary package and then a small number of supporting libraries which are probably free software.
I think autopackage is good work, but creating another packaging format is misguided. I appreciate the reasons they have for reinventing something new rather than sticking with RPM, and I agree that the current RPM situation is not ideal, but in my opinion that doesn't outweigh the massive advantage of having _one_ package manager to deal with instead of N where N > 1. The same applies to ROX application directories and Zero Install, which are a lovely idea (app dirs, of course, have been around since the late 1980s) but again, doomed by trying to bypass the native package manager instead of integrating with it. I would greatly prefer to fix the real and perceived problems with RPM than to go off making another system which 10% of the free world adopts and the rest ignores.
Why is that? Surely the router doesn't care what is inside the IP datagrams it is sending from one place to another. Whether they are made of one TCP session between two hosts, or a hundred separate TCP sessions between those same two hosts, or they aren't TCP at all, should make no difference. Communicating with a large number of different hosts would need more space in the routing table, but it's unlikely to be a significant effect.
OK, fair enough. It would only be simple if a block were small enough to fit in a single UDP datagram. Still, perhaps this is what the uTorrent developers are doing?
You could make the opposite argument: the cool thing about TCP is it automatically retries and resends any dropped packets, so your router can drop all TCP traffic if it needs to.
Not really. You would need that if you were transferring a file from one computer to another. But Bittorrent scrapes together little bits of file from lots of other computers. If a packet is lost here and there, that bit of file is naturally requested again, probably from a different machine. That's just a consequence of the way Bittorrent works.
There's no reason in principle for this to be the case; obviously, metering of bandwidth should be by subscriber according to money paid, not by some arbitrary and easily manipulated value like number of open TCP connections.
We have the LSB, and distributions which make some effort to ship binary 'compat' packages, so that third parties can distribute their software in RPMv3 format (n.b. not the same format as currently used by RPM-based distros, which are on RPMv4) and it will just install and work on any i386 or x86_64 Linux system. But I wonder if that is slightly the wrong model. At the moment if you want some particular library you have the choice of statically linking it into your executable, or just relying on it being there in the target system; neither is very appealing.
For example, suppose you want GTK version 2.16 or later but LSB specifies an older GTK (actually, it specifies a set of interfaces, but that corresponds to a particular GTK version). You could statically link your app with gtk-2.16, or you could include your own private copy of the library to be stuck in /opt/myapp/libs, but then what about Fedora 10 which does include a new enough GTK?
Instead of providing a single RPM (or worse, lots of different binary RPMs for different distros), we should encourage vendors to set up a yum repository. Then to install their software you could add the third-party's repository to your software sources list and use the normal GUI tools to update and install packages. If they want to use some newer library which is not included in Ye Olde Enterprise Linux 1.1, then they can just add a package for that library to the repository, and it will be installed only on systems that need it. This also takes care of automatic updates, which are not provided if you just give people an RPM file to install manually.
Of course, we don't live in a world where you can just 'encourage' third-party software vendors to do things and they'll jump to it; otherwise Nvidia would long ago have released free drivers. So you need to make it as easy as possible to set up a repository for yum or apt-get or smart or whatever packaging tool distros are using. It needs to be trivially easy. So I would suggest enhancing yum and the other tools to work from a plain directory of rpm files served over http. Just dump the files on a webserver, let Apache serve the directory listing and let yum point to that and Just Work. Or, if that's too dirty for you, use a directory on an ftp site (which at least has a defined protocol for listing the files available).
I think a repository for package management programs like yum satisfies what the author is talking about when he asks for a 'meta-package'.
The news here is not the existence of a software renderer, but one with good performance (such that a high-end CPU is competitive with a low-end GPU for some tasks). I wonder how the trusty Mesa GL renderer compares to Microsoft's latest offering? (They implement different APIs, but Wine provides DirectX 10 on top of OpenGL, so you can get an apples to apples comparison.)
Just because you've never used it, it doesn't mean that it was a waste of time. Most children who play association football at school never go on to become professional footballers (and most not even amateur ones). Does that mean that football and other school sports are a waste of time?
Cystic fibrosis only affects people who have cystic fibrosis, which is a tiny minority of the population (a much smaller minority than white men). So if they must choose a charity that represents the entire student body, it's clearly not suitable, since most of the students do not have CF and never will.
If that is their criterion, the only choice open to them is just to give the money back to the students. Any other use would be favouring one minority or another.
LOL.
Care to back that up with some facts?
The synthetic benchmark running slowly is not the problem. What is worrying is that you can run the benchmark once and it somehow crufts up the drive so that all future operations run much more slowly. The only way to get back the original performance is a low-level reformat. That is the bug that Intel needs to fix.
The earlier model of Intel SSD had some serious performance degradation after a few hours of heavy use. (Article in French, but it says that after a ten minute torture with IOmeter writing small blocks to the drive, and even after waiting an hour for the drive to 'recover', performance drops by about 70%.) I wonder if they have fixed this bug with the new model?
Is there some reporting and analysis of this matter from a more impartial source than Groklaw? I'd love to believe what PJ writes, but the history of software patents is one of cleverly worded applications exploiting and widening every possible loophole to expand the scope of patentability. I think Groklaw is putting a very optimistic spin on this.
More importantly, part of the value of a game is its resale value. When people buy a car they take into account how much it's likely to be worth in three, five, ten years' time when they want to sell it. You'd be much more likely to stump up $50 for a game if you were pretty sure you could sell it for $30 on Ebay or Amazon a few months later. The game publishers should be encouraging this secondary market.
I suppose one difference is that there is no piracy of cars; you can sell it to another person and they now own it. You can do that with a video game too, but it's sooo tempting just to leave a backup copy on your own computer. If you accept the principle of copyright, which is that making a copy requires special permission and this is how the authors and publishers make money, then a market in 'secondhand' games which are really just pirate copies doesn't help the industry or, in the long run, encourage development of new games.
Is it possible for third party apps such as Firefox to use this service?
This is a good point. Strangely, in practice I have never found this to be a problem, but then, most version controlled documents have either been computer code which doesn't have reflowable paragraphs, or have been edited by few people at once. I wonder if Subversion (or Mercurial, or Git or Bazaar, etc) lets you plug in a different merging engine that would be more appropriate for prose?
Yes, it works with text files. (You can store binary files but they can't be merged automatically.) So that does make it unsuitable for documents saved from a word processor, unless you save in text format and add the formatting as the last step.
Well, you can use all sorts of tools to show you the diffs. On Windows I use TortoiseSVN, which shows the two versions of a file with differences highlighted.
Have you tried using a version control system such as Subversion or Mercurial? You don't all see the same screen in real time, but it automatically coordinates changes that need to be merged in.
I can't be the only one, surely. But the very fact of being free is some advantage. For example, a free program can support options like 'save stream to disk' or 'block this advertisement' that proprietary software is unlikely to support for fear of upsetting vested interests. If you don't think there is any inherent advantage to free software, and the only criterion should be how well the program works when downloaded as an unchangeable binary blob, then as I said you might as well forget Silverlight and Moonlight, and just use Flash. Its market share is far higher. The biggest reason to be interested in Moonlight is as an open source alternative.
Moonlight is great but it's for Linux only. (Mono itself runs on Linux, Windows and Mac OS X.) That reduces its suitability for making dynamic websites, because Mac and Windows users don't have a free browser plugin to run them with. They only have Microsoft's proprietary Silverlight plugin, and if you're going to require a binary-only plugin then you might as well just use Flash. So I think a Windows version of Moonlight would be cool; just as many people prefer to run the free Firefox browser even though Windows includes the proprietary Internet Explorer, so Moonlight could provide a free alternative for dynamic content.
Surely Solaris (being free software otherwise) is tainted just as much as SuSE Linux by this? If you want to boycott companies that have a patent non-agression pact with Microsoft that's fine, but make sure you are not applying double standards.