Not everyone runs workloads that are poorly vectorized and parallelized, you insensitive clod.
Very few consumers actually run workloads that are properly vectorized and parallelized. Explicit vectorization requires manual creation of multiple codepaths based on the level of vector support in the hardware. Autovectorization is substantially more flexible but requires a decent compiler to pick it up; ICC is by far the best for this, and GCC still struggles after many years of development. Furthermore, the proliferation of virtual-machine based languages means that consumer application developers have largely absolved themselves responsibility for writing code that is vectorized much less suitable for auto vectorization by a JIT that actually does so. Heck, SIMD support in Javascript is just beginning to materialize.
Hyperthreading (Intel's implementation of SMT) is what gives Intel's i7 series microprocessors a huge advantage
The P4 had hyperthreading too. If that really would be such a huge advantage, one would think it would have been a bit more competitive than it was...
Netburst had a ton of issues with it that crippled performance across the board. The HT design was also rather immature. The implementation of HT in later releases of the Itanium series and Nehalem were vastly improved.
Disabling one of the CMT frontends...
...assuming the workload is not keeping all the frontends busy most of the time.
There are only a handful of common consumer applications that keep 6 or even 8 frontends busy at all times. AMD's FX series microarchitectures tends to keep up with Intel Core microarchitectures in such applications, yet fall behind in the ones that consumers spend most of their time running. Javascript, the language that powers the web for some strange reason, is inherently single-threaded.
...only reduces competition for resources that are shared, which on AMD FX series microprocessors includes some of the cache and floating point hardware.
Not with AVX-intensive workloads; there, a single thread can keep the whole shared FPU busy with AVX instructions.
That's correct. The vector unit in both AMD's FX series and Intel's Core series microprocessors are shared between two front ends. although on Intel's architecture the add and multiply vector EUs are on separate ports and can accept issues from separate threads in the same cycle (albeit in lieu of two scalar arithmetic instructions), I'm not sure if AMD's architecture works the same way (although I think that the instruction latency is longer). What I was discussing is that under AMD's CMT design the architecture is unable issue instructions to ALUs on the module's paired core, whereas SMT allows this by virtue of having a completely common backend with a unified reservation station. If one of the frontends on an AMD FX series microprocessor is disabled, the two ALUs are disabled along with it and the result is a typical 4-way SMP with 2 ALUs per logical processor. If Hyperthreading is disabled, the result is a 4-way SMP with 4 ALUs per logical processor as ALUs can still be issued instructions from the unified reservation station. SMT allows for flexibility that simply doesn't exist under CMT.
CMT is inherently less efficient than SMT. It's also a simpler design that's easier for a smaller company to implement.
{citation needed} on both accounts.
There are piles upon piles of benchmarks out there demonstrating this. Intel's architecture excels in instruction throughput, transistor budget, and power efficiency.
Look at the price of AMD's microprocessors on any online retailer's website. Intel's i7-3930k still sells for around $600 and its successor is around $630. AMD's flagship FX-9590 fell from $1000... to $600... to $300 in a matter of weeks as it just can't keep up where it counts.
Hyperthreading (Intel's implementation of SMT) is what gives Intel's i7 series microprocessors a huge advantage over AMD's FX series equivalents.
In terms of pure scalar arithmetic an i7-4700 series microprocessor Haswell and FX-8300 series Piledriver microprocessor have nearly identical clock-for-clock capabilities. Haswell has 4 scalar ALUs per core, whereas Piledriver has 2. SMT allows for the backend execution resources (which includes the scalar ALUs) to be balanced between the two SMT frontends, whereas CMT does not. Disabling or idling one of the SMT frontends improves the instruction throughput of the complementary frontends as they will have greater access to the shared resources due to reduced fighting. Disabling one of the CMT frontends only reduces competition for resources that are shared, which on AMD FX series microprocessors includes some of the cache and floating point hardware. The unshared arithmetic hardware, which is responsible for the bulk of the instructions in most programs, is idled along with the frontend that it belongs to.
CMT is inherently less efficient than SMT. It's also a simpler design that's easier for a smaller company to implement.
No one is going to be manufacturing a traditional implosion style nuclear weapon out of Uranium-233 any time soon. However, a dirty bomb would contaminate a very large area with gamma emitting Uranium-232, causing quite a headache.
Thorium-232 is not fissile, it cannot be used to drive a nuclear fuel cycle. However, Thorium-232 is fertile, it can be bred into an isotope that can drive a nuclear fuel cycle, which in this case is Uranium-233
A contiguous multi-dimensional array in C/C++ is just a block of data with unit stride along the columns and n times unit stride along the rows.
Calculating offsets to do matrix multiplication is incredibly easy as long as the base, dimensions, and stride of each input matrix are known. Now, for particularly large matricies the memory access pattern may be optimized through some clever transposing but that's a different matter.
No language has real multidimensional arrays because most computer address spaces are linear by design. Multidimensional arrays are arrays of arrays, either by index or by reference. There is no other way to do it. Mimicking multi-dimensional arrays in C/C++ is trivial if the style, dimensions, and stride are known. Just allocate an appropriately sized block of data and dereference it with appropriate offsets (or twice if it's jagged). The code generator converts [x][y] notation into this format anyway and most autovectorizers should pick it up.
My understanding is that crash dumps are written to the swap file and the crash dumps are extracted during the next boot when the kernel is once again in a consistent state
Kernel crashes occur when the kernel enters an inconsistent or invalid state from which it cannot recover.
When a user program fails, the kernel maintains consistency, can cleanly terminate the process, and can accurately report the cause of the failure if need be (illegal instruction, deadlock, access violation, etc...).
When a kernel fails the very systems that it relies on to report failures may very well be compromised by whatever caused the kernel to fail in the first place. As such, any kernel fault reporting needs to be incredibly robust and as independent of other kernel mechanisms as possible. Dumping text to a serial terminal is the preferred method because it's incredibly simple and relies on nothing else, meaning that barring a failure of the system memory it should always act as a reliable fallback.
Dumping kernel memory to a disk might fail if the state of the file system is compromised, if the storage controller is compromised, or if any number of intermediary systems are compromised by the inconsistent state of the kernel. Many operating systems do attempt to dump crash memory to the swap file / swap partition as this is less likely to cause data corruption than writing to a particular file in the file system.
It "can" be done, but that does not necessarily make it a good idea.
You can't pay $1 / movie to stream any movie whenever you want because that's not a sustainable revenue model.
Financially successful movies typically demand big budgets, and these same financially successful movies typically make the bulk of their return during the initial cinema run. This is followed by the home-theatre / pay-per-view release which aims to reach both diehard fans and untapped markets that value it enough to actually pay for it. Once that's been worn out it'll head for a second theatre release if there's demand for it, and finally head to broadcast syndication and public availability like Netflix. High budget programs that reach Netflix have already made over 95% of the revenue that they will make from program viewership; further revenue comes from milking bargain bin sales, re-releases, and branded merchandise.
Were media to go straight from cinema to general availability many titles would miss out entirely on very important sources of revenue, and this would render many niche and cult-classic films entirely unprofitable. Many high-budget films would survive (albeit at a much reduced profit) provided that they have a long and successful cinema run, but quality titles that don't generate significant consumer awareness due to smaller initial market demand will simply fail miserably.
>AT&T, and other providers, should have no right to put up walls. If there are issues of peering, those should be working out at the peering level, and not at the application/service or individual business level.
It is strictly a peering issue and it is being worked out at the peering level.
In order to keep their operating costs low, Netflix decided to go with the lowest cost bandwidth around, Cogent. Cogent is great for getting data between datacenters on the cheap, but not-so-great for getting huge volumes of data to end consumers. As a result of Netflix growth and the rollout of higher bandwidth video streams, Cogent began dumping tons of traffic onto other ISPs with which they have peering agreements. Peering agreements are mostly informal and involve exchanging X quantity of traffic for Y quantity of traffic where X and Y are reasonably close to each other. As long as the peering agreement is fair, there's typically no money involved, so the sender of the traffic keeps all the revenue. The amount of traffic originating from Cogent has smashed into the limit of the peering agreements that Cogent has with various consumer ISPs. The bulk of this traffic just happens to originate from Netflix.
The cost of expanding the interconnects to handle all the added cogent traffic would fall entirely on the consumer ISPs, but the revenue for doing so would end up entirely in Cogent's hands. The consumer ISPs perceive this as being rather one sided and unfair (a matter of debate and opinion), so they're dragging their feet and refusing to bolster the exchanges or expand the peering agreements with Cogent unless Cogent foots some of the bill.
This is not a net neutrality issue at all. Netflix is not being treated any differently than any other traffic source. The dispute is between Netflix's upstream ISP and consumer ISPs. Netflix only got involved directly because Netflix is Cogent's biggest consumer, and is indeed the largest source of internet traffic by volume in the world right now.
I'm certain that many consumer ISPs would love to create "Internet + Netflix" packages, but doing so would be a flagrant violation of network neutrality. Instead, they have to bite the bullet and treat it the same as all other traffic which means downloading all of the costs of delivering it onto all of their customers equally regardless of whether or not they actually use it. The workaround is to shift some of those costs onto the source of the traffic (Cogent) who in turn would shift those costs onto the source (Netflix).
The root zone is one of the few things related to DNS administration that ICANN doesn't control. Root zone authority still sits with the US department of commerce
Don't be facetious. Echoing the traffic would make neither Verizon nor Cogent, nor Netflix's customers happy. Verizon is under no obligation to receive every byte that a paying customer has solicited at the customer's marketed rate unless that paying customer is a business customer that has a service level agreement. The peering agreement between Verizon and Cogent is purely voluntary and Netflix is free to contract with another ISP that has better interconnects to Verizon. The requests coming from Verizon's network are part of the traffic that Verizon sends to Cogent.
Selling internet access with a particular level of general service, and selling access to a particular destination with a guaranteed or dedicated level of service are two different things. Consumers deal with the former, and get aggregate access with little to no guaranteed quality of service to any particular endpoint. Business consumers deal with the latter and pay tremendous amounts of money to get the level of service that they need.
The Internet is not just some big magic box in which traffic goes into and comes out of. Ted Steven's "series of tubes" comparison was heavily mocked by detractors, but it is a shockingly accurate comparison. ISPs provide access to the internet through a large number of backbone networks. Routing traffic from A to B and from B back to A may traverse several different networks with traffic changing hands at various exchange locations, typically located in big cities. Disconnect one particular peering arrangement and data that normally traverses that edge will simply find its way to its destination through another route, but this route will usually be less efficient to most consumers.
Right now Verizon peers directly with Cogent all across the country and that's how Netflix traffic is delivered to Verizon customers. Peering agreements are usually constructed to be fair to both parties and rarely involve actual cash payments and that is indeed the case between Verizon and Cogent. It's rare for a peering agreement to be perfectly balanced, but the growth of Netflix means that Verizon is taking far more traffic from Cogent than they are sending back to Cogent and as such are incurring the cost of accepting that uneven amount of bandwidth (which is a huge amount) while as the sender Cogent is keeping the revenue that it gets from Netflix.
Right now, Netflix accounts for almost a third of all downstream Internet traffic, but less than 5% of all upstream traffic. This is a pretty big discrepancy, wider than the usual uses which, even when they do place a large load on the network, tend to be less time sensitive and burstier.
No they are not. They are promising a certain link speed between the customer and the point where the customer's traffic leaves the ISPs network; if they don't deliver on that, that's a different matter entirely. They are not promising a certain level of access to services outside of the ISPs network. When external services are aggregated the marketed rate should be attainable, but aggregation involves making certain assumptions about traffic, one of which is that traffic is more or less evenly distributed across the interconnects. If thousands of customers all try to draw traffic across the same interconnect, that interconnect gets bogged down. The rest of the network is fine, and the customer should still be able to obtain whatever their normal data rate is, but only by aggregating traffic appropriately.
The congestion isn't on the customer-facing side of the ISP's network, it's at the peering exchange with Netflix's carriers. They make no promise about that.
I made no comment about the varying architectures, I made a comment about the build servers themselves.
2.5 racks of ancient equipment is too much equipment. Modernizing those servers would cut the physical and electrical load down by at least 80%. Moving it to a more effective location would go even further. There are some places in the states that rent out a full 42u rack with a 20 amp supply and an unmetered gigabit link for around $700 a month. Colocation in Canada is more expensive across the board but there are comparable services in the GTA.
It's purely poor management. From what I understand, the build servers are absolutely archaic beasts that had they been replaced long ago would not have led to such astronomically high bills. It also doesn't help that they seem to be located in Theo de Raadt's basement.
Copyright protects software as a particular implementation whereas patents protect software as an innovative or inventive approach (that's the idea anyway). Anyone who copies a piece of software verbatim without authorization is going to fall afoul of copyright law. However, anyone who performs clean-room reverse engineering on that piece of software and reimplements it from an abstract level will not. In the latter case, the party performing the reverse engineering may still infringe on one or more patents in the process even if they successfully avoid any breach of copyright.
I'm of the opinion that this is "too bad so sad" for Google, they had their opportunity to bid for the patents but didn't want to shell out for them. The billions of dollars in proceeds generated from that bid allowed my father to recoup some of his pension that he lost when Nortel collapsed. They didn't buy Nortel as a whole, they just purchased some of the IP that was auctioned off.
Slashdot Mirror
Not everyone runs workloads that are poorly vectorized and parallelized, you insensitive clod.
Very few consumers actually run workloads that are properly vectorized and parallelized. Explicit vectorization requires manual creation of multiple codepaths based on the level of vector support in the hardware. Autovectorization is substantially more flexible but requires a decent compiler to pick it up; ICC is by far the best for this, and GCC still struggles after many years of development. Furthermore, the proliferation of virtual-machine based languages means that consumer application developers have largely absolved themselves responsibility for writing code that is vectorized much less suitable for auto vectorization by a JIT that actually does so. Heck, SIMD support in Javascript is just beginning to materialize.
Hyperthreading (Intel's implementation of SMT) is what gives Intel's i7 series microprocessors a huge advantage
The P4 had hyperthreading too. If that really would be such a huge advantage, one would think it would have been a bit more competitive than it was...
Netburst had a ton of issues with it that crippled performance across the board. The HT design was also rather immature. The implementation of HT in later releases of the Itanium series and Nehalem were vastly improved.
Disabling one of the CMT frontends...
...assuming the workload is not keeping all the frontends busy most of the time.
There are only a handful of common consumer applications that keep 6 or even 8 frontends busy at all times. AMD's FX series microarchitectures tends to keep up with Intel Core microarchitectures in such applications, yet fall behind in the ones that consumers spend most of their time running. Javascript, the language that powers the web for some strange reason, is inherently single-threaded.
...only reduces competition for resources that are shared, which on AMD FX series microprocessors includes some of the cache and floating point hardware.
Not with AVX-intensive workloads; there, a single thread can keep the whole shared FPU busy with AVX instructions.
That's correct. The vector unit in both AMD's FX series and Intel's Core series microprocessors are shared between two front ends. although on Intel's architecture the add and multiply vector EUs are on separate ports and can accept issues from separate threads in the same cycle (albeit in lieu of two scalar arithmetic instructions), I'm not sure if AMD's architecture works the same way (although I think that the instruction latency is longer). What I was discussing is that under AMD's CMT design the architecture is unable issue instructions to ALUs on the module's paired core, whereas SMT allows this by virtue of having a completely common backend with a unified reservation station. If one of the frontends on an AMD FX series microprocessor is disabled, the two ALUs are disabled along with it and the result is a typical 4-way SMP with 2 ALUs per logical processor. If Hyperthreading is disabled, the result is a 4-way SMP with 4 ALUs per logical processor as ALUs can still be issued instructions from the unified reservation station. SMT allows for flexibility that simply doesn't exist under CMT.
CMT is inherently less efficient than SMT. It's also a simpler design that's easier for a smaller company to implement.
{citation needed} on both accounts.
There are piles upon piles of benchmarks out there demonstrating this. Intel's architecture excels in instruction throughput, transistor budget, and power efficiency.
Look at the price of AMD's microprocessors on any online retailer's website. Intel's i7-3930k still sells for around $600 and its successor is around $630. AMD's flagship FX-9590 fell from $1000... to $600... to $300 in a matter of weeks as it just can't keep up where it counts.
Hyperthreading (Intel's implementation of SMT) is what gives Intel's i7 series microprocessors a huge advantage over AMD's FX series equivalents.
In terms of pure scalar arithmetic an i7-4700 series microprocessor Haswell and FX-8300 series Piledriver microprocessor have nearly identical clock-for-clock capabilities. Haswell has 4 scalar ALUs per core, whereas Piledriver has 2. SMT allows for the backend execution resources (which includes the scalar ALUs) to be balanced between the two SMT frontends, whereas CMT does not. Disabling or idling one of the SMT frontends improves the instruction throughput of the complementary frontends as they will have greater access to the shared resources due to reduced fighting. Disabling one of the CMT frontends only reduces competition for resources that are shared, which on AMD FX series microprocessors includes some of the cache and floating point hardware. The unshared arithmetic hardware, which is responsible for the bulk of the instructions in most programs, is idled along with the frontend that it belongs to.
CMT is inherently less efficient than SMT. It's also a simpler design that's easier for a smaller company to implement.
No one is going to be manufacturing a traditional implosion style nuclear weapon out of Uranium-233 any time soon. However, a dirty bomb would contaminate a very large area with gamma emitting Uranium-232, causing quite a headache.
Both.
Thorium-232 is not fissile, it cannot be used to drive a nuclear fuel cycle. However, Thorium-232 is fertile, it can be bred into an isotope that can drive a nuclear fuel cycle, which in this case is Uranium-233
A contiguous multi-dimensional array in C/C++ is just a block of data with unit stride along the columns and n times unit stride along the rows.
Calculating offsets to do matrix multiplication is incredibly easy as long as the base, dimensions, and stride of each input matrix are known. Now, for particularly large matricies the memory access pattern may be optimized through some clever transposing but that's a different matter.
No language has real multidimensional arrays because most computer address spaces are linear by design. Multidimensional arrays are arrays of arrays, either by index or by reference. There is no other way to do it. Mimicking multi-dimensional arrays in C/C++ is trivial if the style, dimensions, and stride are known. Just allocate an appropriately sized block of data and dereference it with appropriate offsets (or twice if it's jagged). The code generator converts [x][y] notation into this format anyway and most autovectorizers should pick it up.
Says the AC.
My understanding is that crash dumps are written to the swap file and the crash dumps are extracted during the next boot when the kernel is once again in a consistent state
I never claimed that it was hard. I claimed that it's not bulletproof and it requires substantially more forethought than at first seems
Windows writes crash data to the swap file and even then it fails from time to time.
Kernel crashes occur when the kernel enters an inconsistent or invalid state from which it cannot recover.
When a user program fails, the kernel maintains consistency, can cleanly terminate the process, and can accurately report the cause of the failure if need be (illegal instruction, deadlock, access violation, etc...).
When a kernel fails the very systems that it relies on to report failures may very well be compromised by whatever caused the kernel to fail in the first place. As such, any kernel fault reporting needs to be incredibly robust and as independent of other kernel mechanisms as possible. Dumping text to a serial terminal is the preferred method because it's incredibly simple and relies on nothing else, meaning that barring a failure of the system memory it should always act as a reliable fallback.
Dumping kernel memory to a disk might fail if the state of the file system is compromised, if the storage controller is compromised, or if any number of intermediary systems are compromised by the inconsistent state of the kernel. Many operating systems do attempt to dump crash memory to the swap file / swap partition as this is less likely to cause data corruption than writing to a particular file in the file system.
It "can" be done, but that does not necessarily make it a good idea.
You can't pay $1 / movie to stream any movie whenever you want because that's not a sustainable revenue model.
Financially successful movies typically demand big budgets, and these same financially successful movies typically make the bulk of their return during the initial cinema run. This is followed by the home-theatre / pay-per-view release which aims to reach both diehard fans and untapped markets that value it enough to actually pay for it. Once that's been worn out it'll head for a second theatre release if there's demand for it, and finally head to broadcast syndication and public availability like Netflix. High budget programs that reach Netflix have already made over 95% of the revenue that they will make from program viewership; further revenue comes from milking bargain bin sales, re-releases, and branded merchandise.
Were media to go straight from cinema to general availability many titles would miss out entirely on very important sources of revenue, and this would render many niche and cult-classic films entirely unprofitable. Many high-budget films would survive (albeit at a much reduced profit) provided that they have a long and successful cinema run, but quality titles that don't generate significant consumer awareness due to smaller initial market demand will simply fail miserably.
The definition of "industry expert" has been diluted to mean "anyone who has blogged about a topic more than once". It's entirely meaningless
>AT&T, and other providers, should have no right to put up walls. If there are issues of peering, those should be working out at the peering level, and not at the application/service or individual business level.
It is strictly a peering issue and it is being worked out at the peering level.
In order to keep their operating costs low, Netflix decided to go with the lowest cost bandwidth around, Cogent. Cogent is great for getting data between datacenters on the cheap, but not-so-great for getting huge volumes of data to end consumers. As a result of Netflix growth and the rollout of higher bandwidth video streams, Cogent began dumping tons of traffic onto other ISPs with which they have peering agreements. Peering agreements are mostly informal and involve exchanging X quantity of traffic for Y quantity of traffic where X and Y are reasonably close to each other. As long as the peering agreement is fair, there's typically no money involved, so the sender of the traffic keeps all the revenue. The amount of traffic originating from Cogent has smashed into the limit of the peering agreements that Cogent has with various consumer ISPs. The bulk of this traffic just happens to originate from Netflix.
The cost of expanding the interconnects to handle all the added cogent traffic would fall entirely on the consumer ISPs, but the revenue for doing so would end up entirely in Cogent's hands. The consumer ISPs perceive this as being rather one sided and unfair (a matter of debate and opinion), so they're dragging their feet and refusing to bolster the exchanges or expand the peering agreements with Cogent unless Cogent foots some of the bill.
This is not a net neutrality issue at all. Netflix is not being treated any differently than any other traffic source. The dispute is between Netflix's upstream ISP and consumer ISPs. Netflix only got involved directly because Netflix is Cogent's biggest consumer, and is indeed the largest source of internet traffic by volume in the world right now.
I'm certain that many consumer ISPs would love to create "Internet + Netflix" packages, but doing so would be a flagrant violation of network neutrality. Instead, they have to bite the bullet and treat it the same as all other traffic which means downloading all of the costs of delivering it onto all of their customers equally regardless of whether or not they actually use it. The workaround is to shift some of those costs onto the source of the traffic (Cogent) who in turn would shift those costs onto the source (Netflix).
The root zone is one of the few things related to DNS administration that ICANN doesn't control. Root zone authority still sits with the US department of commerce
Don't be facetious. Echoing the traffic would make neither Verizon nor Cogent, nor Netflix's customers happy. Verizon is under no obligation to receive every byte that a paying customer has solicited at the customer's marketed rate unless that paying customer is a business customer that has a service level agreement. The peering agreement between Verizon and Cogent is purely voluntary and Netflix is free to contract with another ISP that has better interconnects to Verizon. The requests coming from Verizon's network are part of the traffic that Verizon sends to Cogent.
Selling internet access with a particular level of general service, and selling access to a particular destination with a guaranteed or dedicated level of service are two different things. Consumers deal with the former, and get aggregate access with little to no guaranteed quality of service to any particular endpoint. Business consumers deal with the latter and pay tremendous amounts of money to get the level of service that they need.
The Internet is not just some big magic box in which traffic goes into and comes out of. Ted Steven's "series of tubes" comparison was heavily mocked by detractors, but it is a shockingly accurate comparison. ISPs provide access to the internet through a large number of backbone networks. Routing traffic from A to B and from B back to A may traverse several different networks with traffic changing hands at various exchange locations, typically located in big cities. Disconnect one particular peering arrangement and data that normally traverses that edge will simply find its way to its destination through another route, but this route will usually be less efficient to most consumers.
Right now Verizon peers directly with Cogent all across the country and that's how Netflix traffic is delivered to Verizon customers. Peering agreements are usually constructed to be fair to both parties and rarely involve actual cash payments and that is indeed the case between Verizon and Cogent. It's rare for a peering agreement to be perfectly balanced, but the growth of Netflix means that Verizon is taking far more traffic from Cogent than they are sending back to Cogent and as such are incurring the cost of accepting that uneven amount of bandwidth (which is a huge amount) while as the sender Cogent is keeping the revenue that it gets from Netflix.
Right now, Netflix accounts for almost a third of all downstream Internet traffic, but less than 5% of all upstream traffic. This is a pretty big discrepancy, wider than the usual uses which, even when they do place a large load on the network, tend to be less time sensitive and burstier.
No they are not. They are promising a certain link speed between the customer and the point where the customer's traffic leaves the ISPs network; if they don't deliver on that, that's a different matter entirely. They are not promising a certain level of access to services outside of the ISPs network. When external services are aggregated the marketed rate should be attainable, but aggregation involves making certain assumptions about traffic, one of which is that traffic is more or less evenly distributed across the interconnects. If thousands of customers all try to draw traffic across the same interconnect, that interconnect gets bogged down. The rest of the network is fine, and the customer should still be able to obtain whatever their normal data rate is, but only by aggregating traffic appropriately.
The congestion isn't on the customer-facing side of the ISP's network, it's at the peering exchange with Netflix's carriers. They make no promise about that.
Nothing at all. I quite liked Doom 3.
I made no comment about the varying architectures, I made a comment about the build servers themselves.
2.5 racks of ancient equipment is too much equipment. Modernizing those servers would cut the physical and electrical load down by at least 80%. Moving it to a more effective location would go even further. There are some places in the states that rent out a full 42u rack with a 20 amp supply and an unmetered gigabit link for around $700 a month. Colocation in Canada is more expensive across the board but there are comparable services in the GTA.
It's purely poor management. From what I understand, the build servers are absolutely archaic beasts that had they been replaced long ago would not have led to such astronomically high bills. It also doesn't help that they seem to be located in Theo de Raadt's basement.
fuck that, bring back crucifixions!
Not entirely.
Copyright protects software as a particular implementation whereas patents protect software as an innovative or inventive approach (that's the idea anyway). Anyone who copies a piece of software verbatim without authorization is going to fall afoul of copyright law. However, anyone who performs clean-room reverse engineering on that piece of software and reimplements it from an abstract level will not. In the latter case, the party performing the reverse engineering may still infringe on one or more patents in the process even if they successfully avoid any breach of copyright.
It's most likely heat related
I'm of the opinion that this is "too bad so sad" for Google, they had their opportunity to bid for the patents but didn't want to shell out for them. The billions of dollars in proceeds generated from that bid allowed my father to recoup some of his pension that he lost when Nortel collapsed. They didn't buy Nortel as a whole, they just purchased some of the IP that was auctioned off.