I have always lived in countries where civilian use of guns is tightly restricted, and my instinct is to sympathise with the ban, but I think the "guns don't kill people. people kill people" lot have the facts on their side.
Ah, but that's clearly not reading the statistics right. The correct formulation would be, "Guns don't kill people. Americans kill people." If you contrast the prevalence of guns in e.g. Norway (tons of guns, more than the US) the adage becomes "Americans with handguns kill people."
It largely worked - They have one of the happiest, healthiest, most attractive nations on the frickin' planet (the present fallout of US bullying notwithstanding).
When trying to make eugenics look like a monstrosity, you'd do better not to point out its successes.
Thank's for the kind words, but noting that correlation is not causation is very apt here. There are many reasons why Sweden has done well, when it comes to the overall health of the population we would sooner point to our high quality generally available health and dental care (both proactive and reactive including pre-natal etc.), relatively good schools, relatively low income gap (difference between poor and wealthy), even income distribution etc. rather than a failed eugenics programme. (That wasn't nearly widespread enough to have any real impact on the population as a whole.)
We're emphatically not proud of that part of your history; you won't find anyone defending those practices these days, and we have apologized and tried to compensate the victims. (Small comfort, I know, but at least we're not still trying to deny and defend). In our defence, ideas such as these were very much the Zeitgeist, we were just better at it than some (and worse than others).
Well, it's been my experience that functional programmers are often so happy to be able to ply their trade for money that they're not more expensive. In fact they're often cheaper.
And I'll take 10x over "competent" any day. For whatever job.:-)
Its not harder than a OO lang. However finding good help *is* harder. One reason i had to pick java over the many languages I have used was its reasonably easy to find people who know it. Not so much for Scheme or Haskell.
Then again, having worked for Ericsson (Erlang), the quality of the applicants when you look for a Haskell (etc.) programmer will often blow you away. And since good programmers out perform bad ones by at least 10 to 1, the choice may not be as obivous as you'd think at first. Obl. Paul Graham reference.
And the van issue, with kids? Right, so the US just had a firefight with some insurgents armed with AK-47's and RPGs...so what do you do? Gee, drive an unmarked van, with kids *inside* the van, to go take a closer look? *sigh*. Even if you were allegedly picking up wounded insurgents (gosh, I wonder what side that makes me look at), has anybody considered that it's frigging retarded, if not bad parenting, to drive a van with your kids into the aftermath of a US versus insurgents aftermath?
The driver in all probability didn't know any of that. The helicopter was at least a kilometre away and the wounded man he stopped by was unarmed. (Had he been armed the helicopter would have fired, as is demonstrated by the comments by the crew; they goad the wounded man crawling along the street to pick up a weapon so they can open fire).
Also, you are conducting a war in someone's neighbourhood. (Compare the British squaddie joke of renaming FIUBA, "FISH" - "Fighting in somebody else's house.") Of course there are going to be civilians with children around. Civilians that might want to aid what they perceive as their countrymen laying wounded in the street. Civilians who weren't there when the fight actually happened, and may not even be aware of one taking place (esp. with the prevalence of IEDs targeting the civilian population). Don't you think people came running/driving/ when the Oklahoma city bomb went off? It wasn't as if a Bradley was parked in the middle of the street just as he came around the corner.
A helicopter crew should and did knew all of this. As is witnessed by their lying to their chain of command in describing the situation, one can only assume to knowingly and illegally secure permission to fire.
The most tragic part of it was the van but even that was not strictly speaking a violation of the rules of war. Anybody helping the enemy (while not clearly marked as a medic) is a fair target.
No, not true. Not even close. Article 18 of the very first Geneva convention states: "The military authorities shall permit the inhabitants (my emphasis) and relief societies, even in invaded or occupied areas, spontaneously (my emphasis) to collect and care for wounded or sick of whatever nationality. The protection offered by the flag consisting of the reversal of the colours of the federal flag of Switzerland is for the protection of the Medical Service of armed forces. That you're not allowed to harass or attack them of course doesn't mean that you're allowed to attack any and everything else. For example wounded combatants are also of limits. Something the helicopter crew demonstrably knew as they refrained from doing so. (Their comments notwithstanding).
I was actually given rudimentary training in the laws of war when I did my service, if you did and this is the sum total of your knowledge then that of course speaks volumes about the general state of training in the US armed forces. BUT, I don't believe it. The crew of the helicopter clearly had been trained in the US rules of engagement and knew them, as they blatantly lied to his chain of command (one can only assume to illegally secure permission to fire).
Now, I'm not starry eyed enough to believe that the laws of war are actually followed to the letter, or even in spirit, or that they ever were. But to argue that such a clear violation is in fact "A OK", that's taking the cake. The action was illegal and dishonourable, and it should be condemned as such.
That's not how I took the parent. Rather that local predictions in the same time frame as now could be made better. I.e. I'll know if it will rain on *me* or not, given that there is a front moving into the area.
Actually, it's not required by Swedish law. There would be many free speech issues with such regulation.
You may well be right there, I'm working from dim memory, I remember it as technically a form of trespassing (aka, "I've told you to sod off, so sod off!").
I can't see where the free speech issues would come in though. You only have the right to free speech, not to force others to listen to you. If people got the idea to stand on my lawn and shout political slogans, they'd be out of there in no time flat. Lawfully, without freedom of expression being in jeopardy. I'm not in general required to be inconvenienced by someone else's performance of their right to freedom of expression.
I never thought I'd see the day where they would encourage junk mail. As a Swede; my "Please no advertisements" sticker on the mailbox is generally respected (it has to be, by law). But the stuff that's directly addressed to me, i.e. that which is handed out by the Postal Service, is more difficult to get rid of.
"Hooray no spam here!" indeed...
I live in Israel, while staying at the university dorms in Jerusalem some of the local kids were playing on the lawn, this is word for word how they introduced themselves: "This is Muhammad, Muhammad, Muhammad, Muhammad, Hamza, Muhammad".
Oh the cruelty some parents show when naming their children. Is that Hamza kid going to get bullied for his funny name or what...
This, of course, this ignores the long term deaths and illness caused by radiation exposure.
Yes, and that's the killer. If you take "long term" to mean from a couple of days to a month or so. For a ground burst this is easily many times the number of casualties compared to the initial blast. (Higher risk the smaller the blast.)
That's the funny (as in peculiar, not "ha ha") thing about nuclear weapons. Our expectations are often counter intuitive. For example, a counter force strike will lead to many more civilian deaths than a strike against population centres. A counter force strike contains a large number of ground burst (to be effective against hardened structures) and will lead to massive amounts of fall out, that subsequently kills civilians. A strike against population centres OTOH will utilise air burst (even high) air bursts to maximise the effectiveness of the blast against non hard structures (to wit, the strikes against Hiroshima and Nagasaki). This leads to highly reduced amounts of fall out, almost all fatalities and casualties will be the results of blast, thermal and prompt radiation effects, and these are limited in scope and time.
I especially love it when people cite bad code as proof of poor language design. It is like saying you can prove that English is a horrible language by referencing a Rap song. Any good language can be misused, misunderstood, and abused and said abuse is not proof that the language itself is inferior or flawed.
It's not about whether you can do something, it's about whether there is an impedance miss-match between the technology and the operator. It's about how easy it is to shoot yourself in the foot, not whether it is possible. To wit; if there are tons and tons of bad code in a certain language, that tells you something about that language. (Not all, there could for example be bias in the type of programmers that are active/attracted to it). Over the years, it turns out that some elements of language design are in general a bad idea, e.g. humans just aren't good at always getting tedious details right. Take for example, manual memory management. Humans will tend to forget to free memory in all cases (even the corner cases). That's not to say that e.g. free/malloc should be forbidden, there are clearly uses for it, but it's a poor default.
This is especially true as we haven't even begun to really study these aspects yet. There are still orders of magnitude to reap by choosing the right tools.
Well, as you saw from my result the test server was actually in another country, Denmark to be exact, and quite a few hops away from me (20ms ping time).
But, there's something to be said for your question, certainly. There are two parts to it IMHO, the first is as you say, getting to/from your ISP at all. And the second is getting to/from the US (where many of the interesting endpoints are). In the first case, when it comes to cheap broadband, there is certainly caveat emptor. I could get bandwidth cheaper, but with worse peering, and that's why I chose Bahnhof (Sweden's first ISP, with a heavy dose of anonymity etc. thrown in. They get IP in a way that e.g. Telia-Sonera doesn't; and they're not that bad). Of course, it doesn't hurt that TPB is Swedish and that many Swedes have a nice uplink as well as a nice downlink...:-) (As a matter of fact the strong asymmetry in the US hurts Bittorrent more in my experience than does the overall bandwidth. I upload significantly more to the US than I can get back typically.
When it comes to getting across the pond, we are mostly all in the same boat. There is very little you can do if you're not on a special network (such as the Swedish University Network; SUNET). That's to say, there's less you can do, but not all ISPs are exactly equal. As a small aside, somewhat amusingly, peering/network structure to/from the US (esp. in Scandinavia/Holland etc.) is typically better than to the rest of Europe at large. Getting to a server in Austria can bring tears to your eyes. This has mostly to do with the crap state of network infrastructure in continental Europe in general.
Of course ISPs don't advertise peering agreements/status, so one has to go to e.g. netnod to check that for oneself.
As it happens I'm both on fibre at home and on SUNET at "work", so if you want to arrange a test, I'm game. Just tell me what to up/download to/from where and how, and I'll post (or email) the results. (You can reach me at "middlename" (really my first name) at lastname dot cx if you want to go offline).
Fiber to the home (free standing house/single family home, don't know the proper US real estate terminology), at approx $35 per month; that includes IP-telephony monthly charges, calls are extra but cheaper than ordinary land line. Even though I'm paying for 50/50 symmetric, speedtest didn't quite reach that in uplink, I usually see better speeds to a more reasonably located Swedish ISP.
I don't think it's ever gone in Sweden. We don't have that stupid "oh so they didn't got you and now they never will!" AFAIK.
We used to have a maximum time for how long you could be prosecuted/sentenced but I wonder if we didn't dropped that very recently.
Yes we do have statutes of limitation in Sweden. We even used to have a statute of limitation on murder, but that was removed on July 1 this year. So now murder (in the first and second degrees, in US parlance) do not fall under the statute of limitation here.
Also, while being acquitted by a lower court doesn't mean you're off the hook (it typically takes a jury to set a precedent and we don't have juries) that's not to say that you can keep prosecuting someone that was found not guilty on the same evidence over and over again. Something materially new will have had to come to light. If it doesn't there is a maximum of three levels of courts (all of which can say "no", or "yeah that was wrong, do it again") and then it's over. Only the highest court sets a precedent.
Could you elaborate on the difference between swapping and paging? I have always thought of it (adopting the term "paging") as an effort to disconnect modern Virtual Memory implementations from the awful VM performance of Windows 3.1/9x. Wikipedia mentions them as interchangeable terms and other sources on the web seem to agree.
It's actually (buried) in the wikipedia article you link, but only a sentence or so. In the old days, before paging, a Unix system would swap an entire running program onto disk/drum. (That's where the sticky bit comes from, as swap space was typically much faster than other secondary storage, if nothing else the lack of a file system helps, the sticky bit on an executable file meant, "keep text of program on swap even when it's stopped executing". This meant that executing the program again would go much faster). Then came paging, where only certain pages of a running program would get ejected to swap space.
Unix systems would then both swap and page. Roughly, when memory pressure was low (but still high enough to demand swap space), the system would page. As memory pressure rose, the OS would decide the situation to be untenable and select entire processes to be evicted to swap for a long time (several seconds to tens of seconds) and then check periodically to see if they could/should be brought back (evicting someone else in the process). The BSDs even divided the task struct into two parts, the swappable and the unswappable part. Where the swappable part would record things like page tables etc. that is superfluous information when all the pages of a process have been ejected. The unswappable part contained only the bare minimum needed to remember there was a process on swap, and to make scheduling decisions regarding it. This made sense when main memory was measured in single digit megabytes, I don't think that Linux bothered with this (or even swapping as a concept, implementing just paging, but don't quote me on that, as memories were becoming bigger fast).
Of course, swapping meant that those of us that ran X on a 4MB Sun system in the eighties would find that our X-term processes had been swapped out (the OS had decided that since they hadn't been used in a while, and where waiting for I/O, they were probably batch oriented in nature and could be swapped out wholesale) and it would take several seconds for the cursor to become responsive when you changed windows...:-) The scheduling decisions hadn't kept up. The solution though was the same as today, buy more memory...:-)
Any good *old* book on OS internals, esp. the earlier incantations of "The Design and Implementation of the FreeBSD Operating System" by McCusick et.al. would have the gory details. (But the FreeBSD version of that book might have done away with that. It was still in the 4.2 version though.):-)
Anyone who's played Asteroids on the original coin-op hardware (or even just played around with a CRT-based oscilloscope!) knows that if you dump a CRT's electron beam onto a single point, you get a spot of brightness that's radically brighter than a single white pixel on either a CRT or an LCD monitor.
I've done both, i.e. played the original coin-op Asteroids on an oscilloscope when the screen broke.:-) Rather, we used an oscilloscope in X-Y mode to confirm that it was indeed the high voltage driver to the screen that had burned out, (someone much more skilled in electronics than me) fixed it, and were back in action. It was a bit different playing Asteroids green on a 4-inch screen with green traces though.
There's not many dumb terminals around any more for sure unless you're using an IBM Mainframe I guess. I suspect they still use 3270's.
I guess I'm going to show my age here, but to me a VT320 is very far from a dumb terminal, having used a real glass tty (i.e. terminal that couldn't do e.g. cursor addressing, or even backspace).
And the 3270 in particular is about as smart as a terminal ever got. The terminal itself did the input field text editing before shipping the whole screen input back to the mainframe. Even though there aren't many actual terminals around you'll still see them emulated on PCs in quite a number of applications.
Thinking about your post makes me feel even older. When I was in college the "new" terminals were VT-100. The lab was open 24 hours a day because there weren't enough terminals to go around. For those who knew where to look, there were a few VT-52s hiding in relative obscurity.
When I was in college the terminals hiding in relative obscurity were the decwriter hardcopy terminals. That is, they were ignored in a corner until someone started to use them. The noise turned out to be a good way of chasing at least one or two people from their VT-102s. (Also taught you 'ed', no fancy "visual" editing on a hardcopy terminal).
Without mining minerals from the earth, we'd be stuck in the Stone Age.
What! Where do you think stone comes from, and what do you think it's made of? Without mining minerals we'd be stuck in the Wood age!
After-the-fact law enforcement is NOT a deterrent to a suicide bomber.
Yes it is. If the suicide bomber is a terrorist as opposed to just a suicidal individual deciding to take a lot of other people with him, something you are already the experts on. If so the bomber is part of a system that wishes to inflict terror. That system wishes to continue to inflict terror (or rather, to achieve its goals). If it is in prison it cannot, and so will try its best to stay out of it.
If all of Al Queda decided to blow themselves up tomorrow, that might lead to regrettable consequences tomorrow, but would mean there would be no problem the day after that, and for many days to come, so that would trivially not be in their best interest.
1: quotes, to get decent looking quotes in latex you have to use a pair of backticks for opening quotes and a pair of single quotes for closing quotes. I understand the history behind this but it's annoying not to be able to enter text in the normal way and have it dealt with decently.
The LaTeX-mode in emacs has handled this for you since (wait for it) 1985...:-) So, it's been taken care of.
P.S. Yes, tweaking can be painful. That's a feature, not a bug. It helps you putting it off until you're really done. No, I mean, *really done* with the content. It's like optimization; "Don't do it. At least don't do it yet."
Also, for theses, the integration with BiBTeX makes LaTeX a godsend. I know of no citation management system that is as comprehensive (and works as well) as BiBTeX. I couldn't live without it (coupled with reftex-mode for emacs).
I like the Swedish rule for this situation, where the fire hydrant is actually in the street, below a man hole cover. The only thing at the side of the road is a sign pointing to it (so that I can be found under e.g. snow). If you were to block one by parking over it, then the fire department would be the least of your worries.
Slashdot Mirror
I have always lived in countries where civilian use of guns is tightly restricted, and my instinct is to sympathise with the ban, but I think the "guns don't kill people. people kill people" lot have the facts on their side.
Ah, but that's clearly not reading the statistics right. The correct formulation would be, "Guns don't kill people. Americans kill people." If you contrast the prevalence of guns in e.g. Norway (tons of guns, more than the US) the adage becomes "Americans with handguns kill people."
It largely worked - They have one of the happiest, healthiest, most attractive nations on the frickin' planet (the present fallout of US bullying notwithstanding). When trying to make eugenics look like a monstrosity, you'd do better not to point out its successes.
Thank's for the kind words, but noting that correlation is not causation is very apt here. There are many reasons why Sweden has done well, when it comes to the overall health of the population we would sooner point to our high quality generally available health and dental care (both proactive and reactive including pre-natal etc.), relatively good schools, relatively low income gap (difference between poor and wealthy), even income distribution etc. rather than a failed eugenics programme. (That wasn't nearly widespread enough to have any real impact on the population as a whole.)
We're emphatically not proud of that part of your history; you won't find anyone defending those practices these days, and we have apologized and tried to compensate the victims. (Small comfort, I know, but at least we're not still trying to deny and defend). In our defence, ideas such as these were very much the Zeitgeist, we were just better at it than some (and worse than others).
Well, it's been my experience that functional programmers are often so happy to be able to ply their trade for money that they're not more expensive. In fact they're often cheaper. And I'll take 10x over "competent" any day. For whatever job. :-)
Its not harder than a OO lang. However finding good help *is* harder. One reason i had to pick java over the many languages I have used was its reasonably easy to find people who know it. Not so much for Scheme or Haskell.
Then again, having worked for Ericsson (Erlang), the quality of the applicants when you look for a Haskell (etc.) programmer will often blow you away. And since good programmers out perform bad ones by at least 10 to 1, the choice may not be as obivous as you'd think at first. Obl. Paul Graham reference.
And the van issue, with kids? Right, so the US just had a firefight with some insurgents armed with AK-47's and RPGs...so what do you do? Gee, drive an unmarked van, with kids *inside* the van, to go take a closer look? *sigh*. Even if you were allegedly picking up wounded insurgents (gosh, I wonder what side that makes me look at), has anybody considered that it's frigging retarded, if not bad parenting, to drive a van with your kids into the aftermath of a US versus insurgents aftermath?
The driver in all probability didn't know any of that. The helicopter was at least a kilometre away and the wounded man he stopped by was unarmed. (Had he been armed the helicopter would have fired, as is demonstrated by the comments by the crew; they goad the wounded man crawling along the street to pick up a weapon so they can open fire).
Also, you are conducting a war in someone's neighbourhood. (Compare the British squaddie joke of renaming FIUBA, "FISH" - "Fighting in somebody else's house.") Of course there are going to be civilians with children around. Civilians that might want to aid what they perceive as their countrymen laying wounded in the street. Civilians who weren't there when the fight actually happened, and may not even be aware of one taking place (esp. with the prevalence of IEDs targeting the civilian population). Don't you think people came running/driving/ when the Oklahoma city bomb went off? It wasn't as if a Bradley was parked in the middle of the street just as he came around the corner.
A helicopter crew should and did knew all of this. As is witnessed by their lying to their chain of command in describing the situation, one can only assume to knowingly and illegally secure permission to fire.
The most tragic part of it was the van but even that was not strictly speaking a violation of the rules of war. Anybody helping the enemy (while not clearly marked as a medic) is a fair target.
No, not true. Not even close. Article 18 of the very first Geneva convention states: "The military authorities shall permit the inhabitants (my emphasis) and relief societies, even in invaded or occupied areas, spontaneously (my emphasis) to collect and care for wounded or sick of whatever nationality. The protection offered by the flag consisting of the reversal of the colours of the federal flag of Switzerland is for the protection of the Medical Service of armed forces. That you're not allowed to harass or attack them of course doesn't mean that you're allowed to attack any and everything else. For example wounded combatants are also of limits. Something the helicopter crew demonstrably knew as they refrained from doing so. (Their comments notwithstanding).
I was actually given rudimentary training in the laws of war when I did my service, if you did and this is the sum total of your knowledge then that of course speaks volumes about the general state of training in the US armed forces. BUT, I don't believe it. The crew of the helicopter clearly had been trained in the US rules of engagement and knew them, as they blatantly lied to his chain of command (one can only assume to illegally secure permission to fire).
Now, I'm not starry eyed enough to believe that the laws of war are actually followed to the letter, or even in spirit, or that they ever were. But to argue that such a clear violation is in fact "A OK", that's taking the cake. The action was illegal and dishonourable, and it should be condemned as such.
That's not how I took the parent. Rather that local predictions in the same time frame as now could be made better. I.e. I'll know if it will rain on *me* or not, given that there is a front moving into the area.
You may well be right there, I'm working from dim memory, I remember it as technically a form of trespassing (aka, "I've told you to sod off, so sod off!").
I can't see where the free speech issues would come in though. You only have the right to free speech, not to force others to listen to you. If people got the idea to stand on my lawn and shout political slogans, they'd be out of there in no time flat. Lawfully, without freedom of expression being in jeopardy. I'm not in general required to be inconvenienced by someone else's performance of their right to freedom of expression.
I never thought I'd see the day where they would encourage junk mail. As a Swede; my "Please no advertisements" sticker on the mailbox is generally respected (it has to be, by law). But the stuff that's directly addressed to me, i.e. that which is handed out by the Postal Service, is more difficult to get rid of. "Hooray no spam here!" indeed...
I live in Israel, while staying at the university dorms in Jerusalem some of the local kids were playing on the lawn, this is word for word how they introduced themselves: "This is Muhammad, Muhammad, Muhammad, Muhammad, Hamza, Muhammad".
Oh the cruelty some parents show when naming their children. Is that Hamza kid going to get bullied for his funny name or what...
This, of course, this ignores the long term deaths and illness caused by radiation exposure.
Yes, and that's the killer. If you take "long term" to mean from a couple of days to a month or so. For a ground burst this is easily many times the number of casualties compared to the initial blast. (Higher risk the smaller the blast.)
That's the funny (as in peculiar, not "ha ha") thing about nuclear weapons. Our expectations are often counter intuitive. For example, a counter force strike will lead to many more civilian deaths than a strike against population centres. A counter force strike contains a large number of ground burst (to be effective against hardened structures) and will lead to massive amounts of fall out, that subsequently kills civilians. A strike against population centres OTOH will utilise air burst (even high) air bursts to maximise the effectiveness of the blast against non hard structures (to wit, the strikes against Hiroshima and Nagasaki). This leads to highly reduced amounts of fall out, almost all fatalities and casualties will be the results of blast, thermal and prompt radiation effects, and these are limited in scope and time.
These articles are a good introduction to the area.
Read the cite re Erlang vs. C++ and then come back to me on the question of "handing over tedious details to the compiler". :-)
I especially love it when people cite bad code as proof of poor language design. It is like saying you can prove that English is a horrible language by referencing a Rap song. Any good language can be misused, misunderstood, and abused and said abuse is not proof that the language itself is inferior or flawed.
You need to read: When Interfaces Kill: What Really Happened to John Denver
It's not about whether you can do something, it's about whether there is an impedance miss-match between the technology and the operator. It's about how easy it is to shoot yourself in the foot, not whether it is possible. To wit; if there are tons and tons of bad code in a certain language, that tells you something about that language. (Not all, there could for example be bias in the type of programmers that are active/attracted to it). Over the years, it turns out that some elements of language design are in general a bad idea, e.g. humans just aren't good at always getting tedious details right. Take for example, manual memory management. Humans will tend to forget to free memory in all cases (even the corner cases). That's not to say that e.g. free/malloc should be forbidden, there are clearly uses for it, but it's a poor default.
This is especially true as we haven't even begun to really study these aspects yet. There are still orders of magnitude to reap by choosing the right tools.
Well, as you saw from my result the test server was actually in another country, Denmark to be exact, and quite a few hops away from me (20ms ping time).
But, there's something to be said for your question, certainly. There are two parts to it IMHO, the first is as you say, getting to/from your ISP at all. And the second is getting to/from the US (where many of the interesting endpoints are). In the first case, when it comes to cheap broadband, there is certainly caveat emptor. I could get bandwidth cheaper, but with worse peering, and that's why I chose Bahnhof (Sweden's first ISP, with a heavy dose of anonymity etc. thrown in. They get IP in a way that e.g. Telia-Sonera doesn't; and they're not that bad). Of course, it doesn't hurt that TPB is Swedish and that many Swedes have a nice uplink as well as a nice downlink... :-) (As a matter of fact the strong asymmetry in the US hurts Bittorrent more in my experience than does the overall bandwidth. I upload significantly more to the US than I can get back typically.
When it comes to getting across the pond, we are mostly all in the same boat. There is very little you can do if you're not on a special network (such as the Swedish University Network; SUNET). That's to say, there's less you can do, but not all ISPs are exactly equal. As a small aside, somewhat amusingly, peering/network structure to/from the US (esp. in Scandinavia/Holland etc.) is typically better than to the rest of Europe at large. Getting to a server in Austria can bring tears to your eyes. This has mostly to do with the crap state of network infrastructure in continental Europe in general.
Of course ISPs don't advertise peering agreements/status, so one has to go to e.g. netnod to check that for oneself.
As it happens I'm both on fibre at home and on SUNET at "work", so if you want to arrange a test, I'm game. Just tell me what to up/download to/from where and how, and I'll post (or email) the results. (You can reach me at "middlename" (really my first name) at lastname dot cx if you want to go offline).
As long as we're bragging... :-)
Here are my results from a few minutes ago: http://www.speedtest.net/result/985839676.png
Fiber to the home (free standing house/single family home, don't know the proper US real estate terminology), at approx $35 per month; that includes IP-telephony monthly charges, calls are extra but cheaper than ordinary land line. Even though I'm paying for 50/50 symmetric, speedtest didn't quite reach that in uplink, I usually see better speeds to a more reasonably located Swedish ISP.
Yes we do have statutes of limitation in Sweden. We even used to have a statute of limitation on murder, but that was removed on July 1 this year. So now murder (in the first and second degrees, in US parlance) do not fall under the statute of limitation here.
Also, while being acquitted by a lower court doesn't mean you're off the hook (it typically takes a jury to set a precedent and we don't have juries) that's not to say that you can keep prosecuting someone that was found not guilty on the same evidence over and over again. Something materially new will have had to come to light. If it doesn't there is a maximum of three levels of courts (all of which can say "no", or "yeah that was wrong, do it again") and then it's over. Only the highest court sets a precedent.
Could you elaborate on the difference between swapping and paging? I have always thought of it (adopting the term "paging") as an effort to disconnect modern Virtual Memory implementations from the awful VM performance of Windows 3.1/9x. Wikipedia mentions them as interchangeable terms and other sources on the web seem to agree.
It's actually (buried) in the wikipedia article you link, but only a sentence or so. In the old days, before paging, a Unix system would swap an entire running program onto disk/drum. (That's where the sticky bit comes from, as swap space was typically much faster than other secondary storage, if nothing else the lack of a file system helps, the sticky bit on an executable file meant, "keep text of program on swap even when it's stopped executing". This meant that executing the program again would go much faster). Then came paging, where only certain pages of a running program would get ejected to swap space.
Unix systems would then both swap and page. Roughly, when memory pressure was low (but still high enough to demand swap space), the system would page. As memory pressure rose, the OS would decide the situation to be untenable and select entire processes to be evicted to swap for a long time (several seconds to tens of seconds) and then check periodically to see if they could/should be brought back (evicting someone else in the process). The BSDs even divided the task struct into two parts, the swappable and the unswappable part. Where the swappable part would record things like page tables etc. that is superfluous information when all the pages of a process have been ejected. The unswappable part contained only the bare minimum needed to remember there was a process on swap, and to make scheduling decisions regarding it. This made sense when main memory was measured in single digit megabytes, I don't think that Linux bothered with this (or even swapping as a concept, implementing just paging, but don't quote me on that, as memories were becoming bigger fast).
Of course, swapping meant that those of us that ran X on a 4MB Sun system in the eighties would find that our X-term processes had been swapped out (the OS had decided that since they hadn't been used in a while, and where waiting for I/O, they were probably batch oriented in nature and could be swapped out wholesale) and it would take several seconds for the cursor to become responsive when you changed windows... :-) The scheduling decisions hadn't kept up. The solution though was the same as today, buy more memory... :-)
Any good *old* book on OS internals, esp. the earlier incantations of "The Design and Implementation of the FreeBSD Operating System" by McCusick et.al. would have the gory details. (But the FreeBSD version of that book might have done away with that. It was still in the 4.2 version though.) :-)
Anyone who's played Asteroids on the original coin-op hardware (or even just played around with a CRT-based oscilloscope!) knows that if you dump a CRT's electron beam onto a single point, you get a spot of brightness that's radically brighter than a single white pixel on either a CRT or an LCD monitor.
I've done both, i.e. played the original coin-op Asteroids on an oscilloscope when the screen broke. :-) Rather, we used an oscilloscope in X-Y mode to confirm that it was indeed the high voltage driver to the screen that had burned out, (someone much more skilled in electronics than me) fixed it, and were back in action. It was a bit different playing Asteroids green on a 4-inch screen with green traces though.
There's not many dumb terminals around any more for sure unless you're using an IBM Mainframe I guess. I suspect they still use 3270's.
I guess I'm going to show my age here, but to me a VT320 is very far from a dumb terminal, having used a real glass tty (i.e. terminal that couldn't do e.g. cursor addressing, or even backspace).
And the 3270 in particular is about as smart as a terminal ever got. The terminal itself did the input field text editing before shipping the whole screen input back to the mainframe. Even though there aren't many actual terminals around you'll still see them emulated on PCs in quite a number of applications.
Thinking about your post makes me feel even older. When I was in college the "new" terminals were VT-100. The lab was open 24 hours a day because there weren't enough terminals to go around. For those who knew where to look, there were a few VT-52s hiding in relative obscurity.
When I was in college the terminals hiding in relative obscurity were the decwriter hardcopy terminals. That is, they were ignored in a corner until someone started to use them. The noise turned out to be a good way of chasing at least one or two people from their VT-102s. (Also taught you 'ed', no fancy "visual" editing on a hardcopy terminal).
Without mining minerals from the earth, we'd be stuck in the Stone Age. What! Where do you think stone comes from, and what do you think it's made of? Without mining minerals we'd be stuck in the Wood age!
After-the-fact law enforcement is NOT a deterrent to a suicide bomber.
Yes it is. If the suicide bomber is a terrorist as opposed to just a suicidal individual deciding to take a lot of other people with him, something you are already the experts on. If so the bomber is part of a system that wishes to inflict terror. That system wishes to continue to inflict terror (or rather, to achieve its goals). If it is in prison it cannot, and so will try its best to stay out of it. If all of Al Queda decided to blow themselves up tomorrow, that might lead to regrettable consequences tomorrow, but would mean there would be no problem the day after that, and for many days to come, so that would trivially not be in their best interest.
1: quotes, to get decent looking quotes in latex you have to use a pair of backticks for opening quotes and a pair of single quotes for closing quotes. I understand the history behind this but it's annoying not to be able to enter text in the normal way and have it dealt with decently.
The LaTeX-mode in emacs has handled this for you since (wait for it) 1985... :-) So, it's been taken care of.
P.S. Yes, tweaking can be painful. That's a feature, not a bug. It helps you putting it off until you're really done. No, I mean, *really done* with the content. It's like optimization; "Don't do it. At least don't do it yet."
Also, for theses, the integration with BiBTeX makes LaTeX a godsend. I know of no citation management system that is as comprehensive (and works as well) as BiBTeX. I couldn't live without it (coupled with reftex-mode for emacs).
I like the German rules for this situation.
I like the Swedish rule for this situation, where the fire hydrant is actually in the street, below a man hole cover. The only thing at the side of the road is a sign pointing to it (so that I can be found under e.g. snow). If you were to block one by parking over it, then the fire department would be the least of your worries.