No, we don't (typically) mess with the treading model/scheduling etc. It was just to point out that we do know how the Linux kernel works. Erlang wasn't made/used due to ignorance of the options.
Not in the last 7-8 years no. But last time I did Erlang was a couple of magnitudes of order (say two) better. Which is no surprise since Erlang processes were made to be very light weight.
But sure, if you wait long enough, the hardware will eventually catch up...:-)
In which case it'll still be relying on the linux threading subsystem to do all the thread CPU assignment and other thread management tasks. It won't have any choice in the matter.
Sure. But that's a no brainer, when the runtime don't run (substantially) more threads than there are cores. The runtime doesn't use the scheduling of the OS much (if at all).
I'm not sure if you believe that all base station code is written in erlang but I can assure you it isn't.
No, like I said there's also lots of e.g. C. And that's specifically used for e.g. "base stations". (Which do mostly signal processing, so they're written in e.g. VHDL, truth be told. That part of the equation is much more about building hardware. Forwarding code is also typically C, however "management", i.e. making decisions etc. is Erlang. This has all been published, so it's no great secret.
I only know what I've read about it , however I do know about unix operating system kernels.
As do I. We used to write our own. Then used a mix of realtime and Unix e.g. wxWorks (no it doesn't) and Solaris, and then finally Linux. On hardware we built... It's not a "stock" kernel.
Anyway , your homepage states you work with Ericsson so you're hardly unbiased in this discussion.
Not any longer. I used to work *at* Ericsson, but that was quite a few years ago. But of course I'm biased. I haven't seen anything else that worked as well in the kind of large "firm" (somewhere between soft and hard) real time systems. By the sound of you it's as if we (users/developers of Erlang) didn't know about the possible alternatives. We do. But more importantly Erlang embodies the accumulated knowledge of how to build systems like these. Just like 'C' is the embodiement of the knowledge of what it took to write UNIX (and OSes in general) by the guys at AT&T.
I see you 100k and raise you an order of magnitude (at least). From Wikipedia
They are neither operating system processes nor operating system threads, but lightweight processes[citation needed] somewhat similar to Java's original âoegreen threadsâ.[clarification needed] Like operating system processes (and unlike green threads and operating system threads) they have no shared state between them. The estimated minimal overhead for each is 300 words;[8] thus many of them can be created without degrading performance: a benchmark with 20 million processes has been successfully performed.[9]
But numbers aside, the threading/process model of Erlang really *is* orders of magnitude less taxing on resources than almost anything else out there. You can always use a thread in Erlang without thinking about "cost". No thread pools or other tricks like you have to resort to with e.g. Posix threads etc.
This is not surprising. It was made for this. I stems from the observation that telecoms software typically runs tons of little state machines, and the most straight forward way of programming a state machine is by doing it in message passing (i.e. CSP) straight line code, one process per state machine. (Though Ericsson tried other solutions before Erlang, e.g. Plex, that didn't work out so well in practice.)
Apples and oranges. A telecom router will be running a specialised OS which is probably tightly intergrated with erlang. You won't be getting that sort of threading out of erlang on an x86 running windows or linux. If you put C on that router you'd probably get the same performance.
Nope, it's Linux. The mapping/slicing of Erlang thread to OS thread is indeed done by the Erlang runtime. And you most definately will get that amount of threading. Otherwise you wouldn't be using your cell phone.
Plenty of intelligent systems are written C/C++ - eg high speed trading. Sounds to me like you've spent too long in an ivory tower.
Didn't say they hadn't. Said that they weren't the best tool for the task. (Given a certain set of requirement of course.) I am saying that using a tool (Erlang) that was developed to build these kinds of large scale multiply redundant systems given the very considerable experience of how to build such systems is most probably the right tool.
And I don't get the "Ivory tower". That's usually reserved for academia. Erlang is industry, through and through. Started there and stayed there. And I have experience of all the tools you mention. I've worked as both a C/C++ programmer and an Erlang one. You obviously don't know much about Erlang.
Again. You need to read; e.g. Joe Armstrong's thesis , or his blog or something. (Don't worry, he's not an "academic" he got his thesis years *after* having developed Erlang.
What on earth are you on about? The language has nothing to do with threading, thats down to the OS. The pthreads API on unix scales to any number of threads and if the threads arn't being spread evenly among cores than thats down to a problem in the OS kernel , not the C library.
Not even close. Erlang even uses it's own threading model since Posix threads are much too heavy weight. You can have (perhaps) a thousand threads, but hundreds of thousands; forget it. And a typical "telecom router" (like the AXD 301) Erlang implementation typically has a million or more running.
Also I suspect Erlang is a managed language and would therefor probably be pretty hopeless when used for multi process as opposed to multi threaded.
I don't know what you mean exactly by "managed" here, but no. Erlang was built for dependability, i.e. situations where you need more than one computer. It's built on message passing, and hence works just as well (or badly) all the way to the receiving thread being on another computer across the internet. The difference being that since it's functional and message passing is part of the language, it actually works and gets used. That's why we've seen some pretty amazing scaling at i.e. Ericsson, just by adding more computers/cores.
You'd do well to actually surf over to www.erlang.org and read some of the papers/reports on performance etc. I.e. while it's typically (much) slower than e.g. C on micro benchmarks, it's much faster on real application size projects. (The same as assembly was faster in micro benchmarks in the eighties and C was faster when it came to whole programmes.)
That said. These projects *also* contain a lot of C, it's just used where it's good, i.e. for device drivers and stuff like that. Not code with any "intelligence" in it.
First of all, freedom of speech only means that the government cannot impede your right to express constitutionally protected speech.
In the context of the US first amendment "yes." In the more general context of freedom of speech. "No."
And I would say that I'm not alone in this interpretation, given the existence of specific anti slapp laws. What purpose could these laws have except to protect freedom of speech. In fact, from this case, it seems we/you need specific anti-SLAPP laws that include scientific journals.
Many Europeans fail to grasp that items on a national policy level in the US are akin to a EU-wide mandate. Should Estonia and France have an identical transit policy? The state gasoline tax is nearly 50-cents per gallon in New York and California, as compared to 14-cents in Wyoming. The federal tax is (an additional) 18 cents. Europeans like to ignore the state-by-state issues entirely and paint the US with a broad brush.
No, living in Sweden I understand. Our population density is even lower than the US and we're even slightly more urbanised. The top two thirds of the Swedish nation has a population density close to that of Wyoming. (Spent a forthnight in Lander, pop 7000 in the late nineties, so I'm not a complete newbie when it comes to that particular state).
And we don't special case within the nation, and we still manage to have good public transport (trains, busses) and road infrastructure and mobile coverage, and fiber connections. And it's pretty much the same all over the rest of western europe. Not by mandate but by necessity and policy.
But yes, I do propose that you treat them as outliers, and that especially you stop blaming the lack of fuel efficient cars, lack of cell phone coverate, or fiber to the curb or what have you for the rest of the population, you know the EIGHTY percent. It's the outliers that should be treated as such. Not the vast majority.
Oh, and BTW Cheyenne is more than 60k in the city proper according to Wikipedia. I grew up in a Swedish city of less than that (50k) with considerably more than six buss lines. And better trains. And now better fiber connections also.
That you're in the situation you are is due to policy, NOT due to some geographical or other necessity. The sooner you USians acknowledget that, the sooner you can start having a rational discussion about these issues.
Well, I don't know. I've been using a similar technique when charing i.e. a rump session at a conference.
These sessions typically have lots of speakers that only get 5-10 minutes each. If they don't strictly stick to the time limit, the schedule will fall to pieced in no time flat.
So instead of being an asshole and shutting people up in a negative manner, I picked up a trick from (Mike Reiter I think). I start the session by asking the audience to please chime in when I stand up and whistle/applaud when the presentation should end. The idea being to make so much positive encouraging noise that it becomes impossible for the speaker to continue. Works great.
So in that setting I'd be willing to give the silencer gun a try. It sounds as it could be worth a laugh or two.
Is is true of the entire US? No. It isn't true for the majority of the population (since the majority live in the dense areas- that's why they are densely populated).
Exactly. From the same map, 80% of all Americans live in a "metropolitan area". Which means that while the average population density might be lower than the EU (about half if memory serves) the density where people actually live is pretty damn high. Higher than the EU (again if memory serves). That is to say, you are more urbanized than us in the EU.
So we need to get away from talking about the average population density as if it matters. Of course people living in rural Wyoming are going to still use/need individual cars. But that's not the point, since no-one (relatively speaking) lives there to begin with. You need to start thinking about the 80%, not the 20%, whether you're talking gas prices, public transport, mobile phone coverage or something else that depends on population density.
I'm not surprised Europe has a lot of trains that are 'subsidized' by socialist. Take a look at your crumbling, overtaxed, low-growth economies - they are created by that same socialist mentality.
Yes, and of course us Swedes are among the worst of the lot when it comes to "Socialism". And even so, our economy grows faster than yours and our GDP per capita is higher than yours. (And no, we don't have any oil to sell, that's the Norwegians).
That may be so. But it's still largely true. The European countries are not nearly as isolated as the US. As a European politician (for example) you couldn't get away with half of what you could in the US, simply because there are plenty of neighboring countries with which to compare. And I don't mean "compare" in the abstract sense, but rather in the "I've been there, I've worked there, I have friends there, I see news about them on the TV, hell, I even see their news on the TV" kind of way.
Whenever I hear an american exclaim that you're the greatest country on earth I hear two things. First, that the best any of the rest of us could ever hope for would of course be a distant second. And second that even though you might have in the past been a bit full of yourselves, now you're perfect...
If you said the same thing in Europe there would always be a "foreigner" within earshot that would either laugh at you or call you on your bull.
Don't know why this is modded Troll - shooting across a public highway is a crime (the incident report states "once shot, the helicopter lost lift and crash landed on the roadway of U.S. 601.") Responsible gun owners should be against people carrying out criminal acts with their guns.
That's interesting. In my country, which have strict, nay severe gun laws and penalties, it's not a crime per see so shoot across a road. If you hit something you weren't supposed to then that's a problem of course. Furthermore, there are general rules about the safe discharge of a firearm, but there's nothing specific about the path of a bullet/shot crossing a road (public or otherwise). It could certainly be ill advised, but not illegal.
So is there a federal statute that regulates this? Is it up to the state, and what states etc. etc.?
There's video linked from the fine article. It looks a lot less dramatic than what the summary makes it sound to be.
The road is not exactly a four lane interstate. It's single/double track and there's no traffic. The only vehicle you see is the animal rights group's parked van. Go see for yourselves.
What of the some 200,000 Kurds that were killed? I guess they weren't a good enough reason to get rid of Saddam? If you could put a good number on exactly when enough is enough that would be wonderful. How many of the police were involved in those killing and how would you sort out the innocent from the guilty? Does it not seem better to remove all those from power and start from scratch?
Yes, the command structure should of course be put to the boot asap, BUT, that doesn't mean that it's a smart move to disband the police and army. After all the allies kept several German Army units under allied command active as police for several months after Germany surrendered after WWII to ensure an orderly change over. (And it's not as anybody thought they were angels in any way shape or form.)
The same should of course obviously have happened in Iraq as well. It's occupation 101. But the US "leadership" (and I use the term loosely) managed to forget what they knew back in 1945.
Of course, the Kurds in particular do not really enter into the equation, that situation was by no means an emergency. And of course, it was the invaders who had supported Sadam when he committed the worst atrocities in the eighties. In fact, Dick Chaney was the then envoy to Sadam and told him after the gassings of the Kurds to stop doing that because it made it more difficult to support him in the US. Indeed the senate on the news were so appalled that they passed legislation to ban any further support to Sadam. Legislation that Reagan promptly vetoed... So not keeping control of the armed forces both to use them to keep the order and to control their future behaviour and whereabouts because of some sudden concern for past crimes against the Kurdish people would make no sense what so ever given the previous policy. In fact quite the opposite. If you want to be able to properly deal with army and police you keep them in their barracks until you can get around to dealing with them. You don't just cut them lose
I don't disagree, mostly. However, they had better check with the people who were paid to think before they go ahead and do something contrary to what they were instructed to do, just because they thought the instructions weren't right.
But they did do what they were instructed to do, that is to say put bolts in head up. So now they were in a situation with conflicting instructions, and they followed the "superseding one". In hindsight they shouldn't have, but that's in hindsight.
I get the feeling from your post that you assume that engineering/management can walk on water, and let me tell you that most of the time we're only slightly less full of it than the people on the shop floor. If at all. (I don't like the "not paid to think" sentiment one bit.) So blindly following orders wouldn't have worked one bit better overall. As an engineer I place the blame for this almost solely at the feet of engineering.
Your point about the accolades is flawed as well. The Corps goes to great lengths to train and encourage heroic acts, so when one of them receives accolades for it, the Corps deserves some of the credit. The Corps does NOT train and encourage Marines to piss on corpses.
begin with the thoughts and ideas of middle eastern peoples, and imagine the usa is a mild pesky mosquito, and then you can begin to have a better starting point for saying valid things about the motivations al qaeda, or where middle eastern societies go from here (after the arab spring)
That analogy would surely work if you were talking about e.g. Denmark. That would be a gnat. But it's the US we're talking here, and it's more akin to an 800 lbs gorilla...
Sure, if all you're saying is that the forest is full of animals and we would better be looking at all of them, there's no arguing that. But the gorilla is still the gorilla. It ain't no gnat.;-)
You can't take the worst individuals of a fine organization and claim they represent everyone in that organization.
And conversely, thinking that their actions don't reflect on the corps, US military and the US as a whole is equally misguided. You have to find some middle ground. All the while realising that those that are already against you, will already be predisposed to not give you the benefit of the doubt.
The US armed forces thinks so itself; witness the medal of honor citations that invariably say something along the lines of the soldier/marine/airman reflecting great credit on himself, his branch of service and the USA. By your token the accolades could only go to the person, with none being "reflected" on anybody or anything else. It works both ways, you can't both disavow the rotten apples and take credit for the heroes.
Language bloat isn't a problem in itself. You are free not to use the features you consider bloat, at no cost.
Spoken like someone that has never needed to maintain other people's code. You might not write code using these features, but if they're there, you must be able to read and understand them because someone else will use them.
And team/employer coding standards won't work, because they a) have to be followed to the letter, and b) other teams/employers don't use the same standards.
We learnt this already with PL/1 (granted they made the mother of all such mistakes). It's a mistake that we shouldn't have to make over and over again. Language bloat is a problem because people (i.e. programmers) aren't suited to using overly large and complex languages.
Um. If the original TCP/IP stack was GPLed (rather than a reference implementation being available under a BSD license), TCP/IP would not have taken off and we would not have the internet we have today. BECAUSE people could take the BSD tcp/ip stack and port it quite simply to their OS, it became a standard.
Well, be that as it may, the FSF recognizes this situation, that's why the wrote the LGPL (lesser/library GPL).
And the GPL doesn't seem to have hurt, e.g. the GCC, GDB, Linux, or a host of other projects uptake.
And even that wasn't the low end. In the "beginning" we used X comfortably on 8MB Sun3s. A 4MB Sun3 was a bit cramped, with the OS (SunOS) and a few applications it would start swapping (i.e. drive whole programs to disk) to the point that you felt the pain. With 8MB it was quite usable however. The CPUs where what, 15-16 MHz?
Yes, I'm not saying the earth is flat. If you want to explain time zones then a spherical earth comes in handy, but if you just want to live with them a ribbon or better yet route memorisation does just as well (as they don't follow geometry anyway, too much politics involved). China even does without, and they still start school at 8.00 whether that's in the middle of the night or close to lunch. So you don't strictly need them.:-)
So, I'm not sure about "easy to notice" or "run into". As Asimov said, even "flat earth" is a model itself. If you look at the earth, it's patently not flat in most places (barring Bonneville salt flats and places like that). The ancients looked at the undulating land and said, "I wonder if on average it doesn't flatten out."
We could live for a good many thousand years and develop some pretty sophisticated technology without having to question that assumption (hell, even when we got around to thinking round instead of flat, we could then convince ourselves that the rest of the solar system revolved around us instead of a more useful model.
Slashdot Mirror
No, we don't (typically) mess with the treading model/scheduling etc. It was just to point out that we do know how the Linux kernel works. Erlang wasn't made/used due to ignorance of the options.
Have you tried?
Not in the last 7-8 years no. But last time I did Erlang was a couple of magnitudes of order (say two) better. Which is no surprise since Erlang processes were made to be very light weight.
But sure, if you wait long enough, the hardware will eventually catch up... :-)
In which case it'll still be relying on the linux threading subsystem to do all the thread CPU assignment and other thread management tasks. It won't have any choice in the matter.
Sure. But that's a no brainer, when the runtime don't run (substantially) more threads than there are cores. The runtime doesn't use the scheduling of the OS much (if at all).
I'm not sure if you believe that all base station code is written in erlang but I can assure you it isn't.
No, like I said there's also lots of e.g. C. And that's specifically used for e.g. "base stations". (Which do mostly signal processing, so they're written in e.g. VHDL, truth be told. That part of the equation is much more about building hardware. Forwarding code is also typically C, however "management", i.e. making decisions etc. is Erlang. This has all been published, so it's no great secret.
I only know what I've read about it , however I do know about unix operating system kernels.
As do I. We used to write our own. Then used a mix of realtime and Unix e.g. wxWorks (no it doesn't) and Solaris, and then finally Linux. On hardware we built... It's not a "stock" kernel.
Anyway , your homepage states you work with Ericsson so you're hardly unbiased in this discussion.
Not any longer. I used to work *at* Ericsson, but that was quite a few years ago. But of course I'm biased. I haven't seen anything else that worked as well in the kind of large "firm" (somewhere between soft and hard) real time systems. By the sound of you it's as if we (users/developers of Erlang) didn't know about the possible alternatives. We do. But more importantly Erlang embodies the accumulated knowledge of how to build systems like these. Just like 'C' is the embodiement of the knowledge of what it took to write UNIX (and OSes in general) by the guys at AT&T.
I see you 100k and raise you an order of magnitude (at least). From Wikipedia
They are neither operating system processes nor operating system threads, but lightweight processes[citation needed] somewhat similar to Java's original âoegreen threadsâ.[clarification needed] Like operating system processes (and unlike green threads and operating system threads) they have no shared state between them. The estimated minimal overhead for each is 300 words;[8] thus many of them can be created without degrading performance: a benchmark with 20 million processes has been successfully performed.[9]
But numbers aside, the threading/process model of Erlang really *is* orders of magnitude less taxing on resources than almost anything else out there. You can always use a thread in Erlang without thinking about "cost". No thread pools or other tricks like you have to resort to with e.g. Posix threads etc.
This is not surprising. It was made for this. I stems from the observation that telecoms software typically runs tons of little state machines, and the most straight forward way of programming a state machine is by doing it in message passing (i.e. CSP) straight line code, one process per state machine. (Though Ericsson tried other solutions before Erlang, e.g. Plex, that didn't work out so well in practice.)
Apples and oranges. A telecom router will be running a specialised OS which is probably tightly intergrated with erlang. You won't be getting that sort of threading out of erlang on an x86 running windows or linux. If you put C on that router you'd probably get the same performance.
Nope, it's Linux. The mapping/slicing of Erlang thread to OS thread is indeed done by the Erlang runtime. And you most definately will get that amount of threading. Otherwise you wouldn't be using your cell phone.
Plenty of intelligent systems are written C/C++ - eg high speed trading. Sounds to me like you've spent too long in an ivory tower.
Didn't say they hadn't. Said that they weren't the best tool for the task. (Given a certain set of requirement of course.) I am saying that using a tool (Erlang) that was developed to build these kinds of large scale multiply redundant systems given the very considerable experience of how to build such systems is most probably the right tool.
And I don't get the "Ivory tower". That's usually reserved for academia. Erlang is industry, through and through. Started there and stayed there. And I have experience of all the tools you mention. I've worked as both a C/C++ programmer and an Erlang one. You obviously don't know much about Erlang.
Again. You need to read; e.g. Joe Armstrong's thesis , or his blog or something. (Don't worry, he's not an "academic" he got his thesis years *after* having developed Erlang.
What on earth are you on about? The language has nothing to do with threading, thats down to the OS. The pthreads API on unix scales to any number of threads and if the threads arn't being spread evenly among cores than thats down to a problem in the OS kernel , not the C library.
Not even close. Erlang even uses it's own threading model since Posix threads are much too heavy weight. You can have (perhaps) a thousand threads, but hundreds of thousands; forget it. And a typical "telecom router" (like the AXD 301) Erlang implementation typically has a million or more running.
Also I suspect Erlang is a managed language and would therefor probably be pretty hopeless when used for multi process as opposed to multi threaded.
I don't know what you mean exactly by "managed" here, but no. Erlang was built for dependability, i.e. situations where you need more than one computer. It's built on message passing, and hence works just as well (or badly) all the way to the receiving thread being on another computer across the internet. The difference being that since it's functional and message passing is part of the language, it actually works and gets used. That's why we've seen some pretty amazing scaling at i.e. Ericsson, just by adding more computers/cores.
You'd do well to actually surf over to www.erlang.org and read some of the papers/reports on performance etc. I.e. while it's typically (much) slower than e.g. C on micro benchmarks, it's much faster on real application size projects. (The same as assembly was faster in micro benchmarks in the eighties and C was faster when it came to whole programmes.)
That said. These projects *also* contain a lot of C, it's just used where it's good, i.e. for device drivers and stuff like that. Not code with any "intelligence" in it.
First of all, freedom of speech only means that the government cannot impede your right to express constitutionally protected speech.
In the context of the US first amendment "yes." In the more general context of freedom of speech. "No."
And I would say that I'm not alone in this interpretation, given the existence of specific anti slapp laws. What purpose could these laws have except to protect freedom of speech. In fact, from this case, it seems we/you need specific anti-SLAPP laws that include scientific journals.
I'd like to, but the DEA would probably come and smash down my door and shoot my family.
Yeah, Sweden is no model country in that respect either I'm afraid. In fact you could argue we're worse. Much worse.
Many Europeans fail to grasp that items on a national policy level in the US are akin to a EU-wide mandate. Should Estonia and France have an identical transit policy? The state gasoline tax is nearly 50-cents per gallon in New York and California, as compared to 14-cents in Wyoming. The federal tax is (an additional) 18 cents. Europeans like to ignore the state-by-state issues entirely and paint the US with a broad brush.
No, living in Sweden I understand. Our population density is even lower than the US and we're even slightly more urbanised. The top two thirds of the Swedish nation has a population density close to that of Wyoming. (Spent a forthnight in Lander, pop 7000 in the late nineties, so I'm not a complete newbie when it comes to that particular state).
And we don't special case within the nation, and we still manage to have good public transport (trains, busses) and road infrastructure and mobile coverage, and fiber connections. And it's pretty much the same all over the rest of western europe. Not by mandate but by necessity and policy.
But yes, I do propose that you treat them as outliers, and that especially you stop blaming the lack of fuel efficient cars, lack of cell phone coverate, or fiber to the curb or what have you for the rest of the population, you know the EIGHTY percent. It's the outliers that should be treated as such. Not the vast majority.
Oh, and BTW Cheyenne is more than 60k in the city proper according to Wikipedia. I grew up in a Swedish city of less than that (50k) with considerably more than six buss lines. And better trains. And now better fiber connections also.
That you're in the situation you are is due to policy, NOT due to some geographical or other necessity. The sooner you USians acknowledget that, the sooner you can start having a rational discussion about these issues.
Well, I don't know. I've been using a similar technique when charing i.e. a rump session at a conference.
These sessions typically have lots of speakers that only get 5-10 minutes each. If they don't strictly stick to the time limit, the schedule will fall to pieced in no time flat.
So instead of being an asshole and shutting people up in a negative manner, I picked up a trick from (Mike Reiter I think). I start the session by asking the audience to please chime in when I stand up and whistle/applaud when the presentation should end. The idea being to make so much positive encouraging noise that it becomes impossible for the speaker to continue. Works great.
So in that setting I'd be willing to give the silencer gun a try. It sounds as it could be worth a laugh or two.
Is is true of the entire US? No. It isn't true for the majority of the population (since the majority live in the dense areas- that's why they are densely populated).
Exactly. From the same map, 80% of all Americans live in a "metropolitan area". Which means that while the average population density might be lower than the EU (about half if memory serves) the density where people actually live is pretty damn high. Higher than the EU (again if memory serves). That is to say, you are more urbanized than us in the EU.
So we need to get away from talking about the average population density as if it matters. Of course people living in rural Wyoming are going to still use/need individual cars. But that's not the point, since no-one (relatively speaking) lives there to begin with. You need to start thinking about the 80%, not the 20%, whether you're talking gas prices, public transport, mobile phone coverage or something else that depends on population density.
I'm not surprised Europe has a lot of trains that are 'subsidized' by socialist. Take a look at your crumbling, overtaxed, low-growth economies - they are created by that same socialist mentality.
Yes, and of course us Swedes are among the worst of the lot when it comes to "Socialism". And even so, our economy grows faster than yours and our GDP per capita is higher than yours. (And no, we don't have any oil to sell, that's the Norwegians).
Put that in your pipe and smoke it.
That may be so. But it's still largely true. The European countries are not nearly as isolated as the US. As a European politician (for example) you couldn't get away with half of what you could in the US, simply because there are plenty of neighboring countries with which to compare. And I don't mean "compare" in the abstract sense, but rather in the "I've been there, I've worked there, I have friends there, I see news about them on the TV, hell, I even see their news on the TV" kind of way.
Whenever I hear an american exclaim that you're the greatest country on earth I hear two things. First, that the best any of the rest of us could ever hope for would of course be a distant second. And second that even though you might have in the past been a bit full of yourselves, now you're perfect...
If you said the same thing in Europe there would always be a "foreigner" within earshot that would either laugh at you or call you on your bull.
Don't know why this is modded Troll - shooting across a public highway is a crime (the incident report states "once shot, the helicopter lost lift and crash landed on the roadway of U.S. 601.") Responsible gun owners should be against people carrying out criminal acts with their guns.
That's interesting. In my country, which have strict, nay severe gun laws and penalties, it's not a crime per see so shoot across a road. If you hit something you weren't supposed to then that's a problem of course. Furthermore, there are general rules about the safe discharge of a firearm, but there's nothing specific about the path of a bullet/shot crossing a road (public or otherwise). It could certainly be ill advised, but not illegal.
So is there a federal statute that regulates this? Is it up to the state, and what states etc. etc.?
There's video linked from the fine article. It looks a lot less dramatic than what the summary makes it sound to be. The road is not exactly a four lane interstate. It's single/double track and there's no traffic. The only vehicle you see is the animal rights group's parked van. Go see for yourselves.
What of the some 200,000 Kurds that were killed? I guess they weren't a good enough reason to get rid of Saddam? If you could put a good number on exactly when enough is enough that would be wonderful. How many of the police were involved in those killing and how would you sort out the innocent from the guilty? Does it not seem better to remove all those from power and start from scratch?
Yes, the command structure should of course be put to the boot asap, BUT, that doesn't mean that it's a smart move to disband the police and army. After all the allies kept several German Army units under allied command active as police for several months after Germany surrendered after WWII to ensure an orderly change over. (And it's not as anybody thought they were angels in any way shape or form.)
The same should of course obviously have happened in Iraq as well. It's occupation 101. But the US "leadership" (and I use the term loosely) managed to forget what they knew back in 1945.
Of course, the Kurds in particular do not really enter into the equation, that situation was by no means an emergency. And of course, it was the invaders who had supported Sadam when he committed the worst atrocities in the eighties. In fact, Dick Chaney was the then envoy to Sadam and told him after the gassings of the Kurds to stop doing that because it made it more difficult to support him in the US. Indeed the senate on the news were so appalled that they passed legislation to ban any further support to Sadam. Legislation that Reagan promptly vetoed... So not keeping control of the armed forces both to use them to keep the order and to control their future behaviour and whereabouts because of some sudden concern for past crimes against the Kurdish people would make no sense what so ever given the previous policy. In fact quite the opposite. If you want to be able to properly deal with army and police you keep them in their barracks until you can get around to dealing with them. You don't just cut them lose
I don't disagree, mostly. However, they had better check with the people who were paid to think before they go ahead and do something contrary to what they were instructed to do, just because they thought the instructions weren't right.
But they did do what they were instructed to do, that is to say put bolts in head up. So now they were in a situation with conflicting instructions, and they followed the "superseding one". In hindsight they shouldn't have, but that's in hindsight.
I get the feeling from your post that you assume that engineering/management can walk on water, and let me tell you that most of the time we're only slightly less full of it than the people on the shop floor. If at all. (I don't like the "not paid to think" sentiment one bit.) So blindly following orders wouldn't have worked one bit better overall. As an engineer I place the blame for this almost solely at the feet of engineering.
In fact, in the wider sense, this is an almost perfect example of an interface that kills. This design was a disaster waiting to happen. And it did.
My point was more than a language shouldn't be discounted because it's perceived to have "too many" features.
That I agree with. I'm not a minimalist. As long as we're in agreement that even the features you don't use do have a cost. Even to you.
Your point about the accolades is flawed as well. The Corps goes to great lengths to train and encourage heroic acts, so when one of them receives accolades for it, the Corps deserves some of the credit. The Corps does NOT train and encourage Marines to piss on corpses.
Good point.
begin with the thoughts and ideas of middle eastern peoples, and imagine the usa is a mild pesky mosquito, and then you can begin to have a better starting point for saying valid things about the motivations al qaeda, or where middle eastern societies go from here (after the arab spring)
That analogy would surely work if you were talking about e.g. Denmark. That would be a gnat. But it's the US we're talking here, and it's more akin to an 800 lbs gorilla...
Sure, if all you're saying is that the forest is full of animals and we would better be looking at all of them, there's no arguing that. But the gorilla is still the gorilla. It ain't no gnat. ;-)
You can't take the worst individuals of a fine organization and claim they represent everyone in that organization.
And conversely, thinking that their actions don't reflect on the corps, US military and the US as a whole is equally misguided. You have to find some middle ground. All the while realising that those that are already against you, will already be predisposed to not give you the benefit of the doubt.
The US armed forces thinks so itself; witness the medal of honor citations that invariably say something along the lines of the soldier/marine/airman reflecting great credit on himself, his branch of service and the USA. By your token the accolades could only go to the person, with none being "reflected" on anybody or anything else. It works both ways, you can't both disavow the rotten apples and take credit for the heroes.
Language bloat isn't a problem in itself. You are free not to use the features you consider bloat, at no cost.
Spoken like someone that has never needed to maintain other people's code. You might not write code using these features, but if they're there, you must be able to read and understand them because someone else will use them.
And team/employer coding standards won't work, because they a) have to be followed to the letter, and b) other teams/employers don't use the same standards.
We learnt this already with PL/1 (granted they made the mother of all such mistakes). It's a mistake that we shouldn't have to make over and over again. Language bloat is a problem because people (i.e. programmers) aren't suited to using overly large and complex languages.
Um. If the original TCP/IP stack was GPLed (rather than a reference implementation being available under a BSD license), TCP/IP would not have taken off and we would not have the internet we have today. BECAUSE people could take the BSD tcp/ip stack and port it quite simply to their OS, it became a standard.
Well, be that as it may, the FSF recognizes this situation, that's why the wrote the LGPL (lesser/library GPL).
And the GPL doesn't seem to have hurt, e.g. the GCC, GDB, Linux, or a host of other projects uptake.
And even that wasn't the low end. In the "beginning" we used X comfortably on 8MB Sun3s. A 4MB Sun3 was a bit cramped, with the OS (SunOS) and a few applications it would start swapping (i.e. drive whole programs to disk) to the point that you felt the pain. With 8MB it was quite usable however. The CPUs where what, 15-16 MHz?
Yes, I'm not saying the earth is flat. If you want to explain time zones then a spherical earth comes in handy, but if you just want to live with them a ribbon or better yet route memorisation does just as well (as they don't follow geometry anyway, too much politics involved). China even does without, and they still start school at 8.00 whether that's in the middle of the night or close to lunch. So you don't strictly need them. :-)
So, I'm not sure about "easy to notice" or "run into". As Asimov said, even "flat earth" is a model itself. If you look at the earth, it's patently not flat in most places (barring Bonneville salt flats and places like that). The ancients looked at the undulating land and said, "I wonder if on average it doesn't flatten out."
We could live for a good many thousand years and develop some pretty sophisticated technology without having to question that assumption (hell, even when we got around to thinking round instead of flat, we could then convince ourselves that the rest of the solar system revolved around us instead of a more useful model.