I think this is perfect example again that we put too much trust on Google.
Google isn't the problem. The American government is. Which means if you want to be safe, stay away from USA and don't trust any companies based there.
If you happen to live there already, maybe it is about time you let the government know, you are not satisfied with their work.
The point here probably being, that if your route to sydney is misbehaving, losing packets, being otherwise slow etc. you break it even more from the point where it's misbehaving and the system should reroute it around that point.
Exactly right. And this should come as no surprise to anybody with experience in distributed systems. Often a partially functional component cause more damage to the system than a completely broken component. This is because it is much easier to design a system to deal with failures if you know when something has failed.
The best way to avoid this sort of problems is by designing the system to handle Byzantine failures. Many people see the Byzantine failure model as overkill and opt for a less strict failure model. But in doing so they are making assumptions on how failures behave, any failure that violates the assumption about the behaviour of failing components can then bring down the system.
Since any reasonable set of assumptions consider the possibility that a component simply stop responding, you can often bring a failure that violated your initial assumptions in compliance with your assumptions by breaking it more. That is why breaking it more will fix the problem, unless the invalid assumption already caused bad state to spread through the system.
There is a lot of misunderstanding and ignorance about windows -- yours is a prime example.
I think most of those misunderstandings are caused by two factors. Backward compatibility has lead to a fairly convoluted system, which is hard to understand. Microsoft's desire to hide the technical details and the remnants of earlier systems has lead to users having an incorrect impression of what is really going on behind the scenes. At some point Microsoft promised to deliver a Windows version, which was not built on top of DOS. When they couldn't truly live up to that promise, they instead tried to hide the existence of DOS underneath, they also crippled that DOS version by removing lots of the tools. If they hadn't done that, it could not only have been the best DOS version yet, but also the best of those Windows versions running on top of DOS.
I don't claim to know a lot about how Windows works. The last time I looked at any technical details around Windows was when it was called version 3.11. And the last time I touched Windows professionally, Windows XP was state of the art among Windows systems.
What I can tell is that people who use Windows daily have trouble with even such simple tasks as maximizing a window. They can't tell why the maximize button sometimes maximizes in one direction and other times in both directions. And nobody seem to know how to get complete control over it to the point where they can maximize in exactly the direction(s) they want.
I know enough about the history of Windows to realize that the different behaviour of terminal windows compared to other windows is due to its DOS legacy. Most Windows users don't even realize that and are just confused when the maximize button doesn't work as expected.
Much like Windows 3.11 the GUI in GUN/Linux isn't a core part of the OS - but a graphics server with window managers on top and all the real work being done by the OS under the manager.
That is true, but the similarity doesn't go much further than that. If you look at the capabilities of the OS underneath, there is a major difference between Linux and DOS. (Even to this day some of the limitations inherited from DOS are still found in modern Windows versions. The last Windows user I came across wasn't able to open a command line window more than 80 characters wide.)
Monkeys and humans evolved from a common haplorhini ancestor which was neither monkey nor human
If you could reconstruct pictures of what they looked like, I bet the majority of people would classify it as a monkey if you showed them the picture. And chances are nobody would classify it as a fish.
Journeys to other solar system would take an enormous amount of years. So much so that it probably won't happen with live crews.
If you could build propulsion capable of delivering 1G of acceleration continuously for the entire duration of the flight, then I think you could do it in a lifetime. As a nice side effect that would provide artificial gravity during the flight. Achieving that would require a much higher specific impulse than any current propulsion technology could deliver. You'd actually need a powerful particle accelerator onboard the craft.
I haven't done all of the math, but it would be interesting to see a comparison of the specific impulse needed with the speeds delivered by current accelerator rings.
Even if you couldn't do the trip in a lifetime, that just means you need sustainable recycling on board capable of supporting life for enough generations to make the trip there. Which is probably easier than growing and raising a child without any humans around.
One thing is certain - by that time, it would not be mankind, any more than what we are today can be called fishkind.
In terms of time passed it could be a shorter period than the time it took to evolve from monkeys into todays humans. Whether we will use the term human about all descendants of humans is a matter of definition. The changes in culture and technology are likely to be greater than the changes in genome. But all of the changes would be subject to evolutionary selection.
But I highly doubt that we'll get there. Evolution does not favour long term strategies unless those picking short term strategies die off.
The two are not mutually exclusive. Earth would still be populated by humans favouring strategies suitable for life on Earth. Compared to the total size of the human population it only takes a small number of individuals to seed colonization across the galaxy. And other star systems would be dominated by those who are ready to take the risks involved in interstellar travel.
The fastest spacecraft we've ever launched won't reach Alpha Centauri for 40000 years, and that's only because it's not stopping.
Leaving now isn't the fastest way to get there. You'd get there faster by waiting back on Earth for more efficient propulsion technology to be developed. So when is the right time to leave in order to get there as soon as possible? That is a question which can only be answered in retrospect. One day people can look and say, hey we could have been there already if only we had left in the year x.
In reality there are other goals as well, so getting humans there as soon as possible isn't desirable as that would fail at some other goals of such a mission. The first mission to reach another star is going to be an unmanned probe. Serious research into such a possibility is actually already happening. The distance unmanned probes have travelled from the Earth is several orders of magnitudes beyond the furthest any living being has ever travelled from the Earth. I don't imagine manned missions will catch up with that in a thousand years.
But on a longer time scale I actually do imagine manned missions will travel beyond autonomous probes. That of course depends on which happens first, mankind successfully colonizing another star system or mankind extinguishing itself. If the successful colonization happens first, I don't see what would be stopping this from continuing throughout the galaxy. Reaching the other side of the galaxy take such a long time that evolution will be at play, and whoever reach the other side first will have evolved into a mindset where it seems entirely natural that once you have colonized a planet you breed for long enough to produce enough humans for the mission to the next star system. At that time the fatality rate of such missions would be high, but evolution would reward sending out a thousand missions even if only two survives rather than safely staying put until the first mission can be done safely.
If we do reach the other side of the galaxy, it will be with a manned mission intending to colonize yet another star system. Antonymous probes from the Earth will never get that far. What will mankind do, once there are no more habitable star systems left in this galaxy? I guess some crazy attempts at reaching other galaxies. But none of this will happen in my lifetime anyway, so we'll never know if my guesses are even remotely correct.
If I click a grid [on a website] and it offers me the options to add a row, delete a row, and I dontknowwhat than I like that a lot better than having the default popup-menu of the browser.
A user friendly browser would give you a menu with all the options available, which of course must be rendered in a way that it is clearly visible, which are from the browser and which are from the script.
I can think of four different ways to render it. I am not sure which of those four is most user friendly, any of them would work.
You could have the browser's own items show up first on the menu. Then there would be a separator line before the items from the script. Alternatively the order could be swapped. It would also be possible to have a menu on which the first item is a submenu and right after that submenu follows the items from the script. The submenu would then contain the browser's own items. Alternatively the two could be swapped such that the script's items are in the submenu and the browser's own items are in the main menu after the submenu. Since the browser decides the name of that first submenu, it can use that to make it clear to the user, which items are which.
Some sites have java script that disables context menus (right mouse button) and other things that I don't want.
If javascript can break functionality of the browser UI, then that is a browser bug. What you mention is one of many bugs present across a wide range of browsers. So far I haven't had much luck reporting such bugs. I do recall being told to just disable javascript in order to avoid such a bug. At least if they remove the ability to disable javascript, then they can no longer use that lame excuse. That is really the only good thing I can say about having javscript forced on.
There are sites that do something good with javascript. But given the amount of damage you can do with javascript, it should still have been disabled by default, with the possibility of enabling it on a per site basis.
Having javascript turned on permanently is a good goal to aim for. But they forgot the step on the way there, which was to fix all the issues, which makes it better for users to keep it turned off.
Funny you should mention that; apparently someone has gone and invented a book that, get this, you can use to look up the definitions of a word!
Name one spoken language, where there is an authoritative source of definitions of words. Anybody can go write such a book, and none of them will actually be authoritative.
without government regulation or fear of monopolies.
How would you avoid monopolies without government regulation?
it should be abundantly clear at this point, there is not and never has been such a thing as a free market
Before you even try to answer if there is a free market or not, you need to figure out what the words free market actually means. Do you have a free market if a single established player in the market or a small group of players can force newcomers off the market? I'd say no. But then you need regulations to protect the free market. There are people who say it is not a free market if there is any sort of regulations. And by their definition a market controlled by a monopoly is more free than a market with multiple competing players subject to government regulations protecting consumers from the most immoral business practices.
If your definition of a free market is one where there are no regulations and a newcomer can take a part of the market by producing a better product than the established players, then such a market cannot exist. Because without regulations established players can and will squash newcomers.
I don't really care much how people define the words free market. I care more about how the market actually works. And I consider some amount of regulations to be a good thing. At the very least consumers should be able to know what the products on the market are, such that they can make informed decisions on which products they want. Misleading information about products undermines fair competition, so regulations to prevent such misleading information is a good thing.
Police are legally allowed to possess contraband in the course of an investigation; private-sector entities aren't
I consider that to be a real problem with the current laws. There are some data, which can be used for good or for bad purposes. Google has lots of data, they also have the computing architecture to store and process all of this data, and they have the expertise. I firmly believe Google is in a better position to do this sort of data mining than authorities. It is not just about images of child abuse, but also about correlating that with other data, which would not be illegal on its own.
If Google by performing mining across a little bit of child pornography along with lots of legal data is able to produce an output, which can track down the people who were abusing the child in the first place, then I consider that to be a good use of the data, regardless of what the law says about that practice.
The potential for Google to help track down some of these kids and get them out of the abuse is so important, that it is unfortunate that such efforts are jeapordized by the current laws. That makes it only so much nicer to hear that Google is doing an effort in this area. Whether Google is breaking the law or not in the current effort is not important to me, as the goal of the effort is to go after much worse crimes.
I consider abuse of children to be a much worse crime than possession of child pornography. Most people agree that it is worse, but some people seem to think it is not that much worse. Would the average person think it was ok to let 100 people guilty of possession of child pornography go without punishment, if it meant one more person guilty of child abuse could get caught?
It's not the authors of the 20-40 year old works that benefit from keeping it from the public domain, it's the publishers and authors of new works that benefit by not having to compete against:
1) Old works in the public domain
2) New works based on public domain works
If that sort of reasoning was considered valid, we should also outlaw all new inventions, that could make any other profession unnecessary. We need to accept, that nobody has a right to make a living within a profession, that nobody need anymore.
But I don't think we are close to that point yet. Even if we had free access to all culture older than 20 years, there would still be people willing to pay for something new.
So if I paint ONE painting and sell it, ANYONE can then copy it (since it isn't available for purchase?)
Sounds fair to me. There is a market for copies, if the copyright holder has no intention of supplying that market, then that opportunity should be open for others. Regardless of who is selling the copies, the price of the original will still be much higher than that of the copies.
What if I want to make a limited edition book?
Why would you? If all the ones you printed are sold, you can surely make money from another print. If you don't do another print, you are not losing any money from somebody else doing so.
The binary packages (*.deb files) are not signed. It's the "Release" file that is signed. It contains checksums of the "Package" files that contain checksums of the "*.deb" files.
Those are probably not checksums, but actually cryptographic hashes. And assuming they are actually cryptographic hashes, then signing the hash or signing the input is pretty much the same thing. You never sign the actual files in the first place (since they are too large to be input into the signing algorithm), you always hash the data to be signed and then sign the hash. Adding more layers of hashing before you sign is really just constructing a hash tree, which is just another way of hashing data before you sign it.
The main difference between a sequential hashing algorithm and a hash tree is that the tree structure allows for parallel computations of the hash, as well as allows for checking just those parts of the data which you are interested in rather than having to work through the entire computation.
What these money-hungry Hollywood and publishing executives don't seem to realize is that everything DRM'ed will be lost in time, like tears in the rain.
Publishers should be forced to choose whether they want protection from DRM or from copyright. They should not be allowed to have protection from both. So if they choose to release it with DRM, the copyright will immediately expire.
Except that copyright is already tied to the life of the author. It's just the life of the author plus a really stupidly long time...
That additional time is so long, that it removes all incentive to attempt influencing the expiry time. Either the author is already dead, in which case the expiry time can only be changed by changing the law. Or the author is still alive, in which case the copyright of the work will last for so many years into the future, that no living person will care about the exact date. It is easier to influence the expiry time by having the laws changed, which is happening faster than copyrights are expiring.
I personally, in this current system, would limit copyright for all works to a mere five years. With a requirement to retain attribution for maybe another five or ten years after that. But, ten to fifteen years after a work is first published, or say twenty after it is first recorded (if not published), make it fall into true public domain, without even the requirement for attribution.
I agree it should be tied to the publication date. But I think five years is too short. I consider 20 years from the first publication (with author's permission) to be more appropriate. It should come with certain requirements, such as the work remaining available for purchase. Attribution requirements should last longer, but derivative works should be possible. If a product is leaked without author's permission, then the time shouldn't start ticking yet. But there need to be a limit on how many years can pass between such a leak and the actual publication, if full term copyright is to be retained. There also need to be rules preventing any loopholes from making money off a staged "leak" and then retaining copyright after a later "publication" date.
The solution is obviously things like mulitpath-TCP.
That didn't exist at the time. But on a longer term I definitely think multipath TCP looks promising. If multipath TCP gets widely deployed, then we may be able to reach a point where a bundle of network links for all practical purposes work at least as good as a single link at twice the speed.
It does make me a bit sad to see how much the multipath TCP design was restricted by the need to work through NAT devices. But the designers do deserver kudos for the effort in producing a design, which can work with subchannels going through different NAT devices. Multipath could have been even better, if NAT hadn't been part of the equation.
It is actually pretty simple and straightforward to get a second interface to share the work load.
It depends on the workload. Each TCP connection stays on one interface. The fewer TCP connections you have, the harder it is to spread load evenly. In the most extreme real world scenario I have experienced, there was a need to push 1.3Gbit/s over a single TCP connection, and the machine had a bundle of two 1Gbit/s interfaces. Needless to say, the throughput did not reach the 1.3Gbit/s, which was needed.
Pity lunix doesn't have a feature like FreeBSD's securelevel.
You can't expect to have that sort of features on a 16 bit architecture. Managing to produce a unix system with just the basic features and capable of running on only 64KB of RAM is quite a feat.
Have you not noticed all the places in this thread, where that suggestion was made already? A bundle of two interfaces does not behave the same way as a single interface at twice the speed. If don't want to deal with the additional complexity from bundling and all the performance tweaking needed to get traffic evenly distributed on the interfaces, then a 10Gbit/s interface is the only option that I know of.
Then you should have bought some 10 gig interfaces
Unfortunately in order to make room for a 10 Gbit/s interface, we would have needed to remove another card, which was even more important to those servers operation.
or dropped in more 1gigs and bonded them.
We had multiple 1Gbit/s interfaces on board, and we were bundling them. But a bundle of two 1Gbit/s interfaces doesn't give you twice the performance of a 1Gbit/s interface. In some usage patterns the bundle does not give you any additional throughput. We had situations where we needed more than 1Gbit/s on a single TCP connection. You don't get that with bundling of 1Gbit/s interfaces, regardless of how many you use.
Your LACP bond still limits a single stream to a single link.
That is very true indeed. And I have experienced a real world use case, where that was a severe limitation. Since then TCP has been extended to take advantage of multiple links, but that feature is not yet widely supported. In performance tests, it has been shown possible to push 50Gbit/s over a single TCP connection run across a bundle of 6x10Gbit/s.
Even with multiple streams, you would have to have a lot in order of them to hash out to all the links.
One stream per link should be sufficient to utilize all links, assuming an adaptive hashing algorithm is used. It is ok to move a stream from one link to another mid stream. The brief performance drop as the stream is moved to another link is acceptable, if it means the stream gets moved to a less congested link and gets more throughput for the rest of its lifetime.
Slashdot Mirror
Google isn't the problem. The American government is. Which means if you want to be safe, stay away from USA and don't trust any companies based there.
If you happen to live there already, maybe it is about time you let the government know, you are not satisfied with their work.
Exactly right. And this should come as no surprise to anybody with experience in distributed systems. Often a partially functional component cause more damage to the system than a completely broken component. This is because it is much easier to design a system to deal with failures if you know when something has failed.
The best way to avoid this sort of problems is by designing the system to handle Byzantine failures. Many people see the Byzantine failure model as overkill and opt for a less strict failure model. But in doing so they are making assumptions on how failures behave, any failure that violates the assumption about the behaviour of failing components can then bring down the system.
Since any reasonable set of assumptions consider the possibility that a component simply stop responding, you can often bring a failure that violated your initial assumptions in compliance with your assumptions by breaking it more. That is why breaking it more will fix the problem, unless the invalid assumption already caused bad state to spread through the system.
I think most of those misunderstandings are caused by two factors. Backward compatibility has lead to a fairly convoluted system, which is hard to understand. Microsoft's desire to hide the technical details and the remnants of earlier systems has lead to users having an incorrect impression of what is really going on behind the scenes. At some point Microsoft promised to deliver a Windows version, which was not built on top of DOS. When they couldn't truly live up to that promise, they instead tried to hide the existence of DOS underneath, they also crippled that DOS version by removing lots of the tools. If they hadn't done that, it could not only have been the best DOS version yet, but also the best of those Windows versions running on top of DOS.
I don't claim to know a lot about how Windows works. The last time I looked at any technical details around Windows was when it was called version 3.11. And the last time I touched Windows professionally, Windows XP was state of the art among Windows systems.
What I can tell is that people who use Windows daily have trouble with even such simple tasks as maximizing a window. They can't tell why the maximize button sometimes maximizes in one direction and other times in both directions. And nobody seem to know how to get complete control over it to the point where they can maximize in exactly the direction(s) they want.
I know enough about the history of Windows to realize that the different behaviour of terminal windows compared to other windows is due to its DOS legacy. Most Windows users don't even realize that and are just confused when the maximize button doesn't work as expected.
That is true, but the similarity doesn't go much further than that. If you look at the capabilities of the OS underneath, there is a major difference between Linux and DOS. (Even to this day some of the limitations inherited from DOS are still found in modern Windows versions. The last Windows user I came across wasn't able to open a command line window more than 80 characters wide.)
If you could reconstruct pictures of what they looked like, I bet the majority of people would classify it as a monkey if you showed them the picture. And chances are nobody would classify it as a fish.
If you could build propulsion capable of delivering 1G of acceleration continuously for the entire duration of the flight, then I think you could do it in a lifetime. As a nice side effect that would provide artificial gravity during the flight. Achieving that would require a much higher specific impulse than any current propulsion technology could deliver. You'd actually need a powerful particle accelerator onboard the craft.
I haven't done all of the math, but it would be interesting to see a comparison of the specific impulse needed with the speeds delivered by current accelerator rings.
Even if you couldn't do the trip in a lifetime, that just means you need sustainable recycling on board capable of supporting life for enough generations to make the trip there. Which is probably easier than growing and raising a child without any humans around.
In terms of time passed it could be a shorter period than the time it took to evolve from monkeys into todays humans. Whether we will use the term human about all descendants of humans is a matter of definition. The changes in culture and technology are likely to be greater than the changes in genome. But all of the changes would be subject to evolutionary selection.
The two are not mutually exclusive. Earth would still be populated by humans favouring strategies suitable for life on Earth. Compared to the total size of the human population it only takes a small number of individuals to seed colonization across the galaxy. And other star systems would be dominated by those who are ready to take the risks involved in interstellar travel.
Leaving now isn't the fastest way to get there. You'd get there faster by waiting back on Earth for more efficient propulsion technology to be developed. So when is the right time to leave in order to get there as soon as possible? That is a question which can only be answered in retrospect. One day people can look and say, hey we could have been there already if only we had left in the year x.
In reality there are other goals as well, so getting humans there as soon as possible isn't desirable as that would fail at some other goals of such a mission. The first mission to reach another star is going to be an unmanned probe. Serious research into such a possibility is actually already happening. The distance unmanned probes have travelled from the Earth is several orders of magnitudes beyond the furthest any living being has ever travelled from the Earth. I don't imagine manned missions will catch up with that in a thousand years.
But on a longer time scale I actually do imagine manned missions will travel beyond autonomous probes. That of course depends on which happens first, mankind successfully colonizing another star system or mankind extinguishing itself. If the successful colonization happens first, I don't see what would be stopping this from continuing throughout the galaxy. Reaching the other side of the galaxy take such a long time that evolution will be at play, and whoever reach the other side first will have evolved into a mindset where it seems entirely natural that once you have colonized a planet you breed for long enough to produce enough humans for the mission to the next star system. At that time the fatality rate of such missions would be high, but evolution would reward sending out a thousand missions even if only two survives rather than safely staying put until the first mission can be done safely.
If we do reach the other side of the galaxy, it will be with a manned mission intending to colonize yet another star system. Antonymous probes from the Earth will never get that far. What will mankind do, once there are no more habitable star systems left in this galaxy? I guess some crazy attempts at reaching other galaxies. But none of this will happen in my lifetime anyway, so we'll never know if my guesses are even remotely correct.
A user friendly browser would give you a menu with all the options available, which of course must be rendered in a way that it is clearly visible, which are from the browser and which are from the script.
I can think of four different ways to render it. I am not sure which of those four is most user friendly, any of them would work.
You could have the browser's own items show up first on the menu. Then there would be a separator line before the items from the script. Alternatively the order could be swapped. It would also be possible to have a menu on which the first item is a submenu and right after that submenu follows the items from the script. The submenu would then contain the browser's own items. Alternatively the two could be swapped such that the script's items are in the submenu and the browser's own items are in the main menu after the submenu. Since the browser decides the name of that first submenu, it can use that to make it clear to the user, which items are which.
If javascript can break functionality of the browser UI, then that is a browser bug. What you mention is one of many bugs present across a wide range of browsers. So far I haven't had much luck reporting such bugs. I do recall being told to just disable javascript in order to avoid such a bug. At least if they remove the ability to disable javascript, then they can no longer use that lame excuse. That is really the only good thing I can say about having javscript forced on.
There are sites that do something good with javascript. But given the amount of damage you can do with javascript, it should still have been disabled by default, with the possibility of enabling it on a per site basis.
Having javascript turned on permanently is a good goal to aim for. But they forgot the step on the way there, which was to fix all the issues, which makes it better for users to keep it turned off.
Name one spoken language, where there is an authoritative source of definitions of words. Anybody can go write such a book, and none of them will actually be authoritative.
How would you avoid monopolies without government regulation?
Before you even try to answer if there is a free market or not, you need to figure out what the words free market actually means. Do you have a free market if a single established player in the market or a small group of players can force newcomers off the market? I'd say no. But then you need regulations to protect the free market. There are people who say it is not a free market if there is any sort of regulations. And by their definition a market controlled by a monopoly is more free than a market with multiple competing players subject to government regulations protecting consumers from the most immoral business practices.
If your definition of a free market is one where there are no regulations and a newcomer can take a part of the market by producing a better product than the established players, then such a market cannot exist. Because without regulations established players can and will squash newcomers.
I don't really care much how people define the words free market. I care more about how the market actually works. And I consider some amount of regulations to be a good thing. At the very least consumers should be able to know what the products on the market are, such that they can make informed decisions on which products they want. Misleading information about products undermines fair competition, so regulations to prevent such misleading information is a good thing.
I consider that to be a real problem with the current laws. There are some data, which can be used for good or for bad purposes. Google has lots of data, they also have the computing architecture to store and process all of this data, and they have the expertise. I firmly believe Google is in a better position to do this sort of data mining than authorities. It is not just about images of child abuse, but also about correlating that with other data, which would not be illegal on its own.
If Google by performing mining across a little bit of child pornography along with lots of legal data is able to produce an output, which can track down the people who were abusing the child in the first place, then I consider that to be a good use of the data, regardless of what the law says about that practice.
The potential for Google to help track down some of these kids and get them out of the abuse is so important, that it is unfortunate that such efforts are jeapordized by the current laws. That makes it only so much nicer to hear that Google is doing an effort in this area. Whether Google is breaking the law or not in the current effort is not important to me, as the goal of the effort is to go after much worse crimes.
I consider abuse of children to be a much worse crime than possession of child pornography. Most people agree that it is worse, but some people seem to think it is not that much worse. Would the average person think it was ok to let 100 people guilty of possession of child pornography go without punishment, if it meant one more person guilty of child abuse could get caught?
It's not the authors of the 20-40 year old works that benefit from keeping it from the public domain, it's the publishers and authors of new works that benefit by not having to compete against: 1) Old works in the public domain 2) New works based on public domain works
If that sort of reasoning was considered valid, we should also outlaw all new inventions, that could make any other profession unnecessary. We need to accept, that nobody has a right to make a living within a profession, that nobody need anymore.
But I don't think we are close to that point yet. Even if we had free access to all culture older than 20 years, there would still be people willing to pay for something new.
Sounds fair to me. There is a market for copies, if the copyright holder has no intention of supplying that market, then that opportunity should be open for others. Regardless of who is selling the copies, the price of the original will still be much higher than that of the copies.
Why would you? If all the ones you printed are sold, you can surely make money from another print. If you don't do another print, you are not losing any money from somebody else doing so.
Those are probably not checksums, but actually cryptographic hashes. And assuming they are actually cryptographic hashes, then signing the hash or signing the input is pretty much the same thing. You never sign the actual files in the first place (since they are too large to be input into the signing algorithm), you always hash the data to be signed and then sign the hash. Adding more layers of hashing before you sign is really just constructing a hash tree, which is just another way of hashing data before you sign it.
The main difference between a sequential hashing algorithm and a hash tree is that the tree structure allows for parallel computations of the hash, as well as allows for checking just those parts of the data which you are interested in rather than having to work through the entire computation.
Publishers should be forced to choose whether they want protection from DRM or from copyright. They should not be allowed to have protection from both. So if they choose to release it with DRM, the copyright will immediately expire.
That additional time is so long, that it removes all incentive to attempt influencing the expiry time. Either the author is already dead, in which case the expiry time can only be changed by changing the law. Or the author is still alive, in which case the copyright of the work will last for so many years into the future, that no living person will care about the exact date. It is easier to influence the expiry time by having the laws changed, which is happening faster than copyrights are expiring.
I agree it should be tied to the publication date. But I think five years is too short. I consider 20 years from the first publication (with author's permission) to be more appropriate. It should come with certain requirements, such as the work remaining available for purchase. Attribution requirements should last longer, but derivative works should be possible. If a product is leaked without author's permission, then the time shouldn't start ticking yet. But there need to be a limit on how many years can pass between such a leak and the actual publication, if full term copyright is to be retained. There also need to be rules preventing any loopholes from making money off a staged "leak" and then retaining copyright after a later "publication" date.
That didn't exist at the time. But on a longer term I definitely think multipath TCP looks promising. If multipath TCP gets widely deployed, then we may be able to reach a point where a bundle of network links for all practical purposes work at least as good as a single link at twice the speed.
It does make me a bit sad to see how much the multipath TCP design was restricted by the need to work through NAT devices. But the designers do deserver kudos for the effort in producing a design, which can work with subchannels going through different NAT devices. Multipath could have been even better, if NAT hadn't been part of the equation.
My bad. I just checked what Wikipedia had to say. And it turns out the 6502 is actually an 8 bit CPU (even though it has 16 bit addresses).
It depends on the workload. Each TCP connection stays on one interface. The fewer TCP connections you have, the harder it is to spread load evenly. In the most extreme real world scenario I have experienced, there was a need to push 1.3Gbit/s over a single TCP connection, and the machine had a bundle of two 1Gbit/s interfaces. Needless to say, the throughput did not reach the 1.3Gbit/s, which was needed.
You can't expect to have that sort of features on a 16 bit architecture. Managing to produce a unix system with just the basic features and capable of running on only 64KB of RAM is quite a feat.
There was not a single word about video streaming in the posting you replied to.
Have you not noticed all the places in this thread, where that suggestion was made already? A bundle of two interfaces does not behave the same way as a single interface at twice the speed. If don't want to deal with the additional complexity from bundling and all the performance tweaking needed to get traffic evenly distributed on the interfaces, then a 10Gbit/s interface is the only option that I know of.
Unfortunately in order to make room for a 10 Gbit/s interface, we would have needed to remove another card, which was even more important to those servers operation.
We had multiple 1Gbit/s interfaces on board, and we were bundling them. But a bundle of two 1Gbit/s interfaces doesn't give you twice the performance of a 1Gbit/s interface. In some usage patterns the bundle does not give you any additional throughput. We had situations where we needed more than 1Gbit/s on a single TCP connection. You don't get that with bundling of 1Gbit/s interfaces, regardless of how many you use.
That is very true indeed. And I have experienced a real world use case, where that was a severe limitation. Since then TCP has been extended to take advantage of multiple links, but that feature is not yet widely supported. In performance tests, it has been shown possible to push 50Gbit/s over a single TCP connection run across a bundle of 6x10Gbit/s.
One stream per link should be sufficient to utilize all links, assuming an adaptive hashing algorithm is used. It is ok to move a stream from one link to another mid stream. The brief performance drop as the stream is moved to another link is acceptable, if it means the stream gets moved to a less congested link and gets more throughput for the rest of its lifetime.