Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Comment Mmm, XML parsing with regexps (Score 1) 73

Apparently we need a nice high level 3D presentation library but we don't want to work out how to use libxml2. I shall leave here and leave you to consider the error of your ways.

(Also, what language did you base that on? It's surprisingly hard to read.)

Comment Re:Joke? (Score 1) 128

FTTC would be a damn sight better than what we have. If we actually *mean* cabinet, then most people are a few hundred metres away from their nearest cabinet. However, rural users are typically several km from their local exchange. The wiring is set up for 1960s phone systems, with long runs of many many pairs from the exchange out to neighbouring villages - runs that could be replaced with something as lowly as a single gigabit link for drastically improved connections over an all-IP network.

Comment Re:wireless (Score 1) 128

My family lives in a small village.

BT had an advertising campaign a couple of years back saying that anyone on BT could vote to get their exchange upgraded to BT Infinity. And yet, because their exchange was so small, it was impossible to reach the necessary 1000 person threshold to be counted.

They're 25 miles away from two large cities, and yet their broadband runs at somewhere between 500 and 1000kbps, despite being well within the 14km ADSL line length limit - and that's when the wind isn't blowing, because it's apparent that the overhead lines are no longer intact.

Their provider is charging them more than you'd pay in a city - not only for a 20Mbps connection, but also extra because they're outside the areas where the provider has (cheaper) local coverage.

BT won't fix the problem. The providers in the area all use BT cables to give broadband, so there's no competition.

And here's no service guarantee - if you complain, nothing happens, and if you complain more, you get told that you have the choice between shitty broadband or no broadband at all.

Until the government appreciates that the network have-nots in the UK are so, so far removed from the other 90% of the population, it's hard to see how anything will happen, or how anyone will actually able to calculate how much it will cost to fix.

Comment A *secret* ballot (Score 2) 218

No-one mentions this, and it always annoys me. Aside from the software failings, there's an obvious systematic one caused by internet voting at home.

Elections should be secret to avoid the sale or compulsion of votes. So you go to a secured place and vote in a booth so that no-one can tell how you voted (and try not to think too hard about those tracking numbers on your slips, but hey). You cannot leave an identifying mark on your ballot - sign a ballot, for instance, and it is invalid and not counted.

Vote at home, or postally, or by proxy, and secrecy is lost. You can sell your proxy to someone. You can have someone watch you while you vote. This may not matter to you, but hypothetically (and there have been cases of this) if you live in a less-than-free country your employer or your commanding officer might check your ballot to ensure you voted patriotically.

*This* should be sufficient reason to insist on voting at a controlled location. If you worry about people being simply too idle to vote - or prevented from attending - then you should go the way of Belgium or Australia, where you must turn out and vote on pain of being fined, even if you then choose to spoil your ballot. But you should never neglect the principle of secrecy in the name of expediency.

Comment Re:What about pipelining and keep-alive? (Score 1) 275

It all depends on the nature of the loss on the path the packets traverse.
Correlated (i.e. simultaneous) loss will be *worse* to the many-connection case.

I think you'd need to test that to prove it. In my head your simultaneous loss would cause some (but perhaps not all) of many connections would stall for retransmit and they would concurrently wait for the missed packets (1RTT on some percentage of the data), whereas one connection would stall for retransmit (1RTT on 100% of the data).

You deny yourself possibilities for optimisation by putting data with a low ordering requirement through a channel with a high ordering guarantee. You can't pause only one stream for a lost packet when it's within a TCP multiplex; data is being buffered up in the kernel where you can't access it while it waits for a packet that may represent a chunk of a stream you could live without for the moment. (This is not to say that multiple-stream TCP is a better answer, mind you; in truth, there are disadvantages to using either method and some third method might be more appropriate, for instance some protocol that was reliable but did not attempt to preserve ordering).

Comment Re:What about pipelining and keep-alive? (Score 1) 275

Ideally, fewer TCP connections should result in fewer dropped packets.

It's not obvious that there's a huge difference there. There will be more packets for more TCP connections and therefore potentially more drops, but perhaps only a tiny percentage more.

Also, with (say) 10 connections, each drop only stalls one of them while the other 9 continue. With one, 100% of the data stalls. So the number of drops may increase but the increase would have to be drastic to have the same magnitude of effect.

Comment Re:What about pipelining and keep-alive? (Score 1) 275

But lost packets is not the sort of problem SPDY is trying to solve.

Indeed, it makes things worse.

If you miss a packet in HTTP you stall one connection. Other data is still being received on other TCP connections.

If you miss a packet in SPDY you stall all the multiplexed downloads running over that connection until the retransmit.

This may not affect bandwidth, because modern TCP is quite good at recovering from a packet loss without stalling the transmission of packets, but it will stall the browser's receive thread because it can't be given any incoming data until the missing packet turns up, which is at least one round trip.

Comment Re:What about pipelining and keep-alive? (Score 1) 275

This would be true if one page used a single keepalive connection to its server. But typically it uses several and achieves multiplexing by having several TCP connections open. You'd make a request for the image on the first available idle connection - if the JS is still being served there may be another idle connection available nevertheless.

Comment If you need an argument... (Score 4, Insightful) 169

... consider this one, which is purely economic:

If copyrights are extended by 20 years, the entire Canadian public is deprived of value, which is handed mostly to holders of existing copyrights. What are you getting in return?

If the answer is 'nothing', then why would your MP, whose sole job is to represent the Canadian public, vote for this?

If the answer is 'more creativity', then that statement would need considerable backup before it's worthwhile changing the status quo, considering the loss involved. Last I checked there was no shortage of new novels, films and so on, and no indication that more money for the creators in the long distant future would change that.

And if the answer is 'appeasing other countries', then someone needs to justify the value of such appeasement.

Anything else would seem to be a dereliction of the MP's duty.

Comment Re:But copyright IS working (Score 5, Interesting) 314

I think the 'supporting the established players' argument has merits.

As a young country, the US was notorious for ignoring copyrights and patents held in older, countries during its early development. Japan had the same reputation; China is arguably just leaving this phase itself, as they've tightened their IP rules for WIPO purposes in order to more easily access other markets with their products.

It would seem that, for countries and businesses both, there's a threshold they cross where they realise the value of their ideas, if copyrighted, is worth more to them than the cost of paying for the ideas of others.

Slashdot Top Deals

Those who can't write, write manuals.