It would distribute the concentration of computational power and increase the security of bitcoin transactions. The security of the protocol is dependent upon individuals not being able to outcompute the rest of the network. A widespread distribution of computational power reduces the opportunity of individuals and bolsters the protocol security.
I was a Libertarian long before I read Atlas Shrugged. I read it this year and I was very disappointed actually. I found the book to have a very shallow plot and was very long winded and preachy. It should have been a short story. Marketing that book as the Libertarian Opus makes me realize why people think Libertarians are pseudo intellectual idiots.
> and the courts have ruled that you can't copyright an API.
Not to my knowledge. In the Oracle v. Google case the judge specifically avoided ruling on this. Non-expressive API's should be okay for some vague notion of non-expression.
It is kind of grey. The GPL says you cannot link, but in doing so it is governing usage, not copying, which could be considered outside of the copyright holder's jurisdiction. They are defining what it is to be a derivative work, which isn't something a copyright holder can necessarily do. They can have an *opinion* as to what defines a derivative work, and the FSF certainly does have a strong opinion on that. Someone can of course disagree with that opinion and link anyway. Personally, I sure as hell don't want to be the one defending the opposing opinion against the FSF in a court of law, so your interpretation is by far the safer one.
Linux is the primary component of android that cares about what chip is running. Most everything else in android just uses whatever linux gives it and couldn't care less what chip it's running on. If Android is not supported on a CPU, you can pretty much bet they mean the Linux part of Android.
Firefox alpha-6 segfaulted 6 minutes after it was installed here. Breakpad never bothered to report our progress. It was only through the power of my superior intellect that I was able to install a previous build.
Yes. Because policing or banning distributed file sharing is commonly what the **AA is asking for. This effects me greatly, and I don't even buy OR download their crap.
Re:Distributed version control gaining ground in F
on
Linus on GIT and SCM
·
· Score: 2, Informative
So, how do you take that diff, revert half of it back to server's version, begin coding a completely new direction, realize you were right the first time, go back to the original dif you took, then pull in half the stuff you did while doing the wrong thing, finish coding and push the commit back to the server?
You can't because subversion has no client side version control.
For fairness, lets compare Haskell's version, with this (fictional) Java-like syntax. Being as the Java version has additional OO features (requiring the public and static keywords) and 2 of the 7 lines are brackets, because it doesn't use layout, which is purely stylistic, and it needs to use an accumulator, since it's strict and needs tail recursion, I still say it's not so bad. Any tail recursive fold is going to require the extra overhead of the accumulator, which is the bloat you see over Haskell's 3 line version (4 if we add type signature) since Haskell's laziness removes the need for the tail recursive version.
Java's horribly bloated (my original point), but this fictional language based on Java syntax is not a good example of it IMO.
// Idealized-Java TCO public static fold(k, z, xs) {
acc = z;
for (x : xs) {
result = k.apply(acc, x);
}
return acc; } // Haskell not tail call optimized (actual prelude code) foldr k z xs = go xs
where go [] = z
go (y:ys) = y `k` go ys
// Non-tail recursive version in Idealized-Java. Not as pretty as Haskell's, but what is? public static fold(k, z, xs) {
return xs.empty() ? z : k.apply(fold(k,z,xs.rest()), xs.first()); }
It's worse than that... it stripped out my pointy brackets...
// Working Java version public interface Functor2<R, T1, T2> {
R apply(T1 value1, T2 value2); }
public static <R, T> R fold(Collection<T> coll, R init, Functor2<R, R, T> func) {
R result = init;
for (T value : coll) {
result = func.apply(result, value);
}
return result; }
And here is what Java SHOULD look like if it were readable:
// Not Real Java public interface Functor2<R, T1, T2> {
R apply(T1, T2); }
public static fold(coll, init, func) {
result = init;
for (value : coll) {
result = func.apply(result, value);
}
return result; }
The second definition of fold doesn't seem so bad. Too bad it's not legal Java.
// Java's Readable syntax, using a fold function as an example
public interface Functor2 {
R apply(T1 value1, T2 value2); }
public static R fold(Collection coll, R init, Functor2 func) {
R result = init;
for (T value : coll) {
result = func.apply(result, value);
}
return result; }// Since the compiler already knows the types from context,// this is how it might be written with absolutely no loss of information.
public interface Functor2 {
R apply(T1, T2); }
public fold(coll, init, func) {
result = init;
for (value : coll) {
result = func.apply(result, value);
}
return result; }// This is a trivial example. More complex use of generics// make the readability difference more pronounced.
Your analogy only holds because you didn't buy a car, you bought a train that only runs on non standard gauge rails.
For some of us, we buy whatever hardware we like, and then recompile the software for the new platform, and we're off. My primary web server has switched entire platforms twice and is still running from it's original (albeit recompiled) image.
1) Cross machine boundary pooling of processes 2) Process failure recovery 3) Runtime swapping of code
I am very interested in both languages (and am learning Haskell). I like Haskell for it's purity, and Erlang for it's lightweight and failable processes. Can the same model be implemented in Haskell?
I don't think that _any_ language that I know (and that isn't saying much, I'm not boasting) is really thread-ready.
Check out Erlang and Haskell. Haskell does it by eliminating the concept of state and instruction ordering (so there is so concept of a thread of execution). The compiler can then do provably safe things on any number of threads it feels like. Erlang takes a different approach by making EVERYTHING it's own little thread (functions, variables, everything). Both of these are production languages.
You are using JVM threads. Most massively scalable threaded languages, like Erlang, use green threads. A green thread acts like a thread from the standpoint of the programmer, but carries little or no context switch cost (because it's not really a thread). The underlying platform then load balances these green threads across the actual hardware in an optimal pool of true threads.
What makes these programming languages easy to grasp the massive concurrency of is one of 2 things:
1) In Erlang and Termite (A scheme dialect) there is no mutable state, and no globals. Every function is in essence a "service" that simply gets messages and then responds with replies. There is no need to think about locking in such a system and very easy message passing idioms to do what you would normally do with mutable object orientation.
2) In languages like Haskell, there is no concept of a "thread" at all... not even a single thread. There is no concept of "ordering". Things are defined as they are in mathematics.. as relationships between functions and variables. There is no mutable state allowed. This strictness allows the compiler to make very deep conclusions as to what can be parallelized. The compiler can then load balance under the covers across any number of procs without exposing any issues of concurrency to the user at all.
So yes, in Java (and OO in general), concurrency is very, very difficult. In other paradigms though it can be trivial, or even transparent.
There is much competition in the software contract market. I've worked in it for years. I am at work right now.
My job will end in about 9 months time. During those 9 months I am being paid hourly. I choose to work with a contracting agency that provides me full benefits comparable with what I would get as a full-time employee (not quite as good, but pretty damn good benefits.) I get a slightly higher pay per hours worked than the salaried full time employees, but I work a bit less (both because I prefer to, and because I'm more expensive than salaried employees, so the company prefers I work only when I need to.) If the company really likes me, they might make an offer for full time in the next 9 months... I'll probably turn them down. At the end of my year, I must take 100 days off before working for THIS company again. I will use that as my vacation time, and cash out my paid vacation for a free 2 weeks pay, then I will probably hunt and peck the job market, seeing if there is anything interesting going on, and run my small software company during that time. With the software market being what it is, I can be working within 2 weeks maximum, even without this company I am at now being an option. When the 100 days is up, I can choose to hunt around this company for a position that really sounds interesting to work on for another year (The work environment at this particular company is very nice, so I'm a bit partial to coming back.) My 401K is fully vested with corporate matching through my contract company... as long as I work for them for any amount of time in a 5 year period, it will continue to remain fully vested, so that's no issue.
It's really not as bad as you make it out to be. I very much like my situation. I make a solid 6 figure income (when I decide to work year round), get as much time off per year as I'd like to take with no hard feelings, I get variety in my work, jumping to new projects yearly, or coming back to the same one if I really like it. You make it sound like I'm getting screwed royally, but I think it's at least as equitable a situation as full-time salaried, if not a leg up.
As you can see, MS checked this box already for you. Apparently they foresaw the fact that their user's enjoy hosing their systems, and saved you some steps in order to make it easier for you to do it.
I was trying to be humorously insightful. Actually, I half expected to get modded to oblivion if people didn't get the joke.
The insightful theme is the fact that incoming email is ACL'd owner|Full Control, when it should be ACL'd owner|Read. The MS justification is "What if our user's WANT to hose their system and bring the network to a crawl? We should make it easy for them, so they don't have to understand ACLs to be able to do stupid things." Hence, MS chmod +x's the file *for* the user, even though they have a perfectly adequate system for blocking such problems. This forces the poor ask slashdot poster to block incoming files at the server level because the OS is too insecure to be able to trust the users with it.
And no, a "You are trying to hose your company's network, cancel or allow?" is not sufficient. If the user can't turn on the execute flag on the script to be able to run it due to lack of knowledge of security ACLs, then he obviously is not knowledgeable enough to know if the script comes from a reliable source.
Do people really chmod +x email attachments?!? I'd say your problem is in user education. Hell, any user knowledgeable enough to know how to set the executable flag should KNOW better!
I'm a Libertarian and I admit that the people have the ability to attribute to themselves the right to any oppressive or downright stupid government they want to as long as such government is not explicitly forbidden by the enumerations in the constitution.
Now you have met one;)
Now, as a Libertarian, I would also stridently disagree with any group who supports the introduction of legislation that would give them the oppressive government they want, but in a strict constitutional sense, it's not *forbidden* (except where expressly forbidden). "Free medical care" is a great example. It's perfectly constitutional. I don't think it makes great sense, as it takes incentives out of the market, but I wouldn't attack the notion on it's constitutionality.
If you are born poor, you most probably stay poor, if you are born rich, you most probably stay rich. While some people might become rich because of their own choice, their situation is the exception, not the rule.
This is a correlation, true, but it does not show causality at all. It is perfectly plausible that those who are born poor are brought up in situations where they are likely to be more tolerant of the conditions endured by the poor. There is the question of motivation, genetics, environment, etc.. all being different between the 2 groups. For instance:
IQ scores have a strong correlation to income. They have an even stronger correlation to heredity. It is very possible that a strong causation for the trend you mention is that people of High IQ make more money, and then have children with High IQ who go on to make more money, whereas people of low IQ tend to make little money and have children of low IQ.
"All people, short of physical or mental disability, chose their own lifestyle in the United States." may be too inclusive (perhaps replacing that "all" with a "most" would be more palatable), and he cites no support references for the statement, but I wouldn't call it exceptionally retarded.
I was born poor, I now have a comfortable income well above the median for my age group and geographic location. That's not very empirical, I know, but I can say that through personal experience, the difference between being my personally being poor and my personally being "rich" are mostly a matter of being 1) motivated to change my economic strata and 2) knowledge of how to do so. The knowledge is freely available to all members of our society: there is no "secret" to getting rich (or, at least, comfortable.. but we will call that "rich" for the purposes of retaining the dichotomy). The formula is well known. Find something that needs doing. Educate yourself on how to do it. Do it. The more education needed to do it, typically the higher the profit. These are all "choices".
You could argue: 1) That the poor have little access to the knowledge of what "needs doing". 2) That the poor have little access to the education of "how to do it". 3) That the poor have little ability to do anything.
I disagree completely with #2, and #3. Resources are there. #1, is more salient, and I personally think is a driving for the poor "staying poor". There is much misinformation in their culture as to what "needs doing".
You *could* make that argument. You do need a thoroughfare though, even to walk. We need some method of transporting ourselves and good across a privately owned 2-D landscape without sprouting wings. At the very minimum we need legal access routes. Now, can real road infrastructure be privately funded? It would be wonderful if it could, but that's a very hard problem to solve, as it's tough to make decent profits on roadways. Technology might come to the rescue here in the future, but for the last 200 years it's been nearly impossible. So we have an example of an infrastructure that is 1) necessary and 2) difficult or impossible to privatize. That's a good candidate for taxation.
On to "funding for the arts" for contrast. We all have a different view of "what is good art?" Almost no public expenditure is going to be appreciated by even the majority, much less nearly unanimously. Personally, I spent thousands of dollars last year supporting the arts. I purchased tickets for Basketball games. I volunteered time and money supporting youth dressage training. I went to quite a few live plays. I saw a few movies. I went to a few museums. I listened to music regularly, purchasing some, and listening to advertising to fund other outlets. And attended one symphony, which wasn't very good. I also watched some TV, more than I'd liked to have. So, my thousands of dollars and my volunteer hours weren't enough for arts? I appreciate art, and would be perfectly willing to pay a bit more money for tickets if my most appreciated art forms weren't profitable in order to make them so. It might cut down on my overall attendance, but I can cut out those crappy basketball games to give more money to a good Tom Stoppard production. If the government opted to not fund the arts I'm already funding with my taxes, and let me keep them instead, I would be able to spend proportionally MORE money on the arts... and they would be the arts *I* appreciate, as displays of Jesus floating in piss (to allude to a particularly bad publicly funded example) aren't really all that attractive to me. Additionally, by applying my time and money directly to the artistic institutions, I eliminate all the administrative overhead required to redistribute my funds under the public funded scenario, meaning the arts get more money and the political juggernauts gets less. So, we have an example of an institution that is either 1) Not necessary for our society (we can live without statues and Basketball games) and/or 2) Easily privatized, as I am a perfect anecdotal example of someone who funds it well, and I doubt I am too far outside the norm.
When a public institution is doling out funds, you better believe I expect them to keep these analysis in mind and prioritize where the money should go, eliminating expenditures to pay for arts and television sets in favor of roads and safety nets. Preferably, they should get out of the TV and arts businesses altogether, and let people who cater to those economic niche's handle that stuff.
sponsoring arts programs... Silly. There are alternative funding methods. I would rather not pay taxes for this. paying for students to take field trips... Silly. There are alternative funding methods. I would rather not pay taxes for this. building monuments to fallen soldiers... Silly. There are alternative funding methods. I would rather not pay taxes for this. repaving roads... I can think of no one who does not utilize roads, they are a necessary infrastructure. Here's one we can agree goes into the homelessness problem level category! Buying me and my neighbors a television... Silly. There are alternative funding methods. I would rather not pay taxes for this.
Hey! You're right! *ALMOST* every government expenditure *IS* silly! I'd like the surplus back taxes I paid back so I can buy some good art, donate towards some educational field trips, give some more money to a homeless shelter, help build a monument to veterans and buy myself a new TV, please. I can do this with negligible red-tape expenses, and in addition, I can ensure that it goes towards the causes I believe most in, I'll get the warm fuzzies instead of my congressman spending my money, and I'll do it voluntarily and enthusiastically instead of begrudgingly!
I disagree completely. Hand writing simple code should not be difficult for a good engineer. You will miss semicolons on the whiteboard, no doubt, but you aren't being judged on how many stupid compiler errors the code will produce. Saying that you cannot write by hand a language you claim to produce fluently in, but rather you need a full compiler and editing environment, is like saying you can't speak anymore, but must use MS Word for all communications because of it's grammar checker and font changing ability. What goes on the whiteboard is pseudo-code, meant only for humans, that describes that 1) you have decent problem solving skills to come up with a halfway decent algorithm (primes are good because they don't need a "domain expert" hopefully, if you past grade school math and are in my office presenting yourself as an engineer) and 2) you can write something that at least approaches the structure of the language we want you to program in.
If not realizing that you can drop out of the calculations for prime verification early (not knowing it's the square root might be acceptable), and that you can again stop early if you find a divisor, are the level of optimizations that would have you hunting down "domain experts" in your world, then you aren't what we call an engineer in my world.
Now, granted, I have been on a couple interviews where I was judged on my ability to "correctly" write some silly algorithm, and was docked for not instantly seeing the best one right away, or for missing a semicolon here and there, but those types of interviewers completely miss the point of the exersize.
In my opinion, learn Haskell, and use if for your own projects. By learning Haskell you will be covering 90% of the stuff that they may neglect to teach you at school. Ideally you should learn Haskell, Scheme, Prolog, Erlang, Java | Smalltalk, and C, but if you can learn only one, learn Haskell.
Java isn't a bad toy teaching language;) It does do a decent job of showing you how to utilize OO, which is an important paradigm to know how to use these days. It doesn't go much further though. C is an obscure little language that compilers output to as bytecode before it goes to the final architecture dependant compilation stage. It's important to know how your high level constructs get implemented on the von-neuman architecture, so I recommend you do a little C too, as Java covers this up a little too much. Scheme will teach you mutable code structure (and is just too fun to pass up), Prolog teaches some nasty cool logics, Erlang teaches concurrency. Haskell will teach you how to think like a programmer should.
Slashdot Mirror
It would distribute the concentration of computational power and increase the security of bitcoin transactions. The security of the protocol is dependent upon individuals not being able to outcompute the rest of the network. A widespread distribution of computational power reduces the opportunity of individuals and bolsters the protocol security.
I was a Libertarian long before I read Atlas Shrugged. I read it this year and I was very disappointed actually. I found the book to have a very shallow plot and was very long winded and preachy. It should have been a short story. Marketing that book as the Libertarian Opus makes me realize why people think Libertarians are pseudo intellectual idiots.
> and the courts have ruled that you can't copyright an API.
Not to my knowledge. In the Oracle v. Google case the judge specifically avoided ruling on this. Non-expressive API's should be okay for some vague notion of non-expression.
It is kind of grey. The GPL says you cannot link, but in doing so it is governing usage, not copying, which could be considered outside of the copyright holder's jurisdiction. They are defining what it is to be a derivative work, which isn't something a copyright holder can necessarily do. They can have an *opinion* as to what defines a derivative work, and the FSF certainly does have a strong opinion on that. Someone can of course disagree with that opinion and link anyway. Personally, I sure as hell don't want to be the one defending the opposing opinion against the FSF in a court of law, so your interpretation is by far the safer one.
Linux is the primary component of android that cares about what chip is running. Most everything else in android just uses whatever linux gives it and couldn't care less what chip it's running on. If Android is not supported on a CPU, you can pretty much bet they mean the Linux part of Android.
Firefox alpha-6 segfaulted 6 minutes after it was installed here. Breakpad never bothered to report our progress. It was only through the power of my superior intellect that I was able to install a previous build.
Yes. Because policing or banning distributed file sharing is commonly what the **AA is asking for. This effects me greatly, and I don't even buy OR download their crap.
So, how do you take that diff, revert half of it back to server's version, begin coding a completely new direction, realize you were right the first time, go back to the original dif you took, then pull in half the stuff you did while doing the wrong thing, finish coding and push the commit back to the server?
You can't because subversion has no client side version control.
For fairness, lets compare Haskell's version, with this (fictional) Java-like syntax.
// Idealized-Java TCO
// Haskell not tail call optimized (actual prelude code)
// Non-tail recursive version in Idealized-Java. Not as pretty as Haskell's, but what is?
Being as the Java version has additional OO features (requiring the public and static keywords) and 2 of the 7 lines are brackets, because it doesn't use layout, which is purely stylistic, and it needs to use an accumulator, since it's strict and needs tail recursion, I still say it's not so bad. Any tail recursive fold is going to require the extra overhead of the accumulator, which is the bloat you see over Haskell's 3 line version (4 if we add type signature) since Haskell's laziness removes the need for the tail recursive version.
Java's horribly bloated (my original point), but this fictional language based on Java syntax is not a good example of it IMO.
public static fold(k, z, xs) {
acc = z;
for (x : xs) {
result = k.apply(acc, x);
}
return acc;
}
foldr k z xs = go xs
where go [] = z
go (y:ys) = y `k` go ys
public static fold(k, z, xs) {
return xs.empty() ? z : k.apply(fold(k,z,xs.rest()), xs.first());
}
It's worse than that... it stripped out my pointy brackets...
// Working Java version
// Not Real Java
public interface Functor2<R, T1, T2> {
R apply(T1 value1, T2 value2);
}
public static <R, T> R fold(Collection<T> coll, R init, Functor2<R, R, T> func) {
R result = init;
for (T value : coll) {
result = func.apply(result, value);
}
return result;
}
And here is what Java SHOULD look like if it were readable:
public interface Functor2<R, T1, T2> {
R apply(T1, T2);
}
public static fold(coll, init, func) {
result = init;
for (value : coll) {
result = func.apply(result, value);
}
return result;
}
The second definition of fold doesn't seem so bad. Too bad it's not legal Java.
// Java's Readable syntax, using a fold function as an example
// Since the compiler already knows the types from context, // this is how it might be written with absolutely no loss of information.
// This is a trivial example. More complex use of generics // make the readability difference more pronounced.
public interface Functor2 {
R apply(T1 value1, T2 value2);
}
public static R fold(Collection coll, R init, Functor2 func) {
R result = init;
for (T value : coll) {
result = func.apply(result, value);
}
return result;
}
public interface Functor2 {
R apply(T1, T2);
}
public fold(coll, init, func) {
result = init;
for (value : coll) {
result = func.apply(result, value);
}
return result;
}
Your analogy only holds because you didn't buy a car, you bought a train that only runs on non standard gauge rails.
For some of us, we buy whatever hardware we like, and then recompile the software for the new platform, and we're off. My primary web server has switched entire platforms twice and is still running from it's original (albeit recompiled) image.
So, how does STM compare to Erlang for:
1) Cross machine boundary pooling of processes
2) Process failure recovery
3) Runtime swapping of code
I am very interested in both languages (and am learning Haskell). I like Haskell for it's purity, and Erlang for it's lightweight and failable processes. Can the same model be implemented in Haskell?
Check out Erlang and Haskell. Haskell does it by eliminating the concept of state and instruction ordering (so there is so concept of a thread of execution). The compiler can then do provably safe things on any number of threads it feels like. Erlang takes a different approach by making EVERYTHING it's own little thread (functions, variables, everything). Both of these are production languages.
You are using JVM threads. Most massively scalable threaded languages, like Erlang, use green threads. A green thread acts like a thread from the standpoint of the programmer, but carries little or no context switch cost (because it's not really a thread). The underlying platform then load balances these green threads across the actual hardware in an optimal pool of true threads.
What makes these programming languages easy to grasp the massive concurrency of is one of 2 things:
1) In Erlang and Termite (A scheme dialect) there is no mutable state, and no globals. Every function is in essence a "service" that simply gets messages and then responds with replies. There is no need to think about locking in such a system and very easy message passing idioms to do what you would normally do with mutable object orientation.
2) In languages like Haskell, there is no concept of a "thread" at all... not even a single thread. There is no concept of "ordering". Things are defined as they are in mathematics.. as relationships between functions and variables. There is no mutable state allowed. This strictness allows the compiler to make very deep conclusions as to what can be parallelized. The compiler can then load balance under the covers across any number of procs without exposing any issues of concurrency to the user at all.
So yes, in Java (and OO in general), concurrency is very, very difficult. In other paradigms though it can be trivial, or even transparent.
There is much competition in the software contract market. I've worked in it for years. I am at work right now.
My job will end in about 9 months time. During those 9 months I am being paid hourly. I choose to work with a contracting agency that provides me full benefits comparable with what I would get as a full-time employee (not quite as good, but pretty damn good benefits.) I get a slightly higher pay per hours worked than the salaried full time employees, but I work a bit less (both because I prefer to, and because I'm more expensive than salaried employees, so the company prefers I work only when I need to.) If the company really likes me, they might make an offer for full time in the next 9 months... I'll probably turn them down. At the end of my year, I must take 100 days off before working for THIS company again. I will use that as my vacation time, and cash out my paid vacation for a free 2 weeks pay, then I will probably hunt and peck the job market, seeing if there is anything interesting going on, and run my small software company during that time. With the software market being what it is, I can be working within 2 weeks maximum, even without this company I am at now being an option. When the 100 days is up, I can choose to hunt around this company for a position that really sounds interesting to work on for another year (The work environment at this particular company is very nice, so I'm a bit partial to coming back.) My 401K is fully vested with corporate matching through my contract company... as long as I work for them for any amount of time in a 5 year period, it will continue to remain fully vested, so that's no issue.
It's really not as bad as you make it out to be. I very much like my situation. I make a solid 6 figure income (when I decide to work year round), get as much time off per year as I'd like to take with no hard feelings, I get variety in my work, jumping to new projects yearly, or coming back to the same one if I really like it. You make it sound like I'm getting screwed royally, but I think it's at least as equitable a situation as full-time salaried, if not a leg up.
in Windows click-speak (hehe.. that sounds like an African tribal language):
Right click, properties, security tab, click edit, select [you], check execute allow, click apply.
As you can see, MS checked this box already for you. Apparently they foresaw the fact that their user's enjoy hosing their systems, and saved you some steps in order to make it easier for you to do it.
I was trying to be humorously insightful. Actually, I half expected to get modded to oblivion if people didn't get the joke.
The insightful theme is the fact that incoming email is ACL'd owner|Full Control, when it should be ACL'd owner|Read. The MS justification is "What if our user's WANT to hose their system and bring the network to a crawl? We should make it easy for them, so they don't have to understand ACLs to be able to do stupid things." Hence, MS chmod +x's the file *for* the user, even though they have a perfectly adequate system for blocking such problems. This forces the poor ask slashdot poster to block incoming files at the server level because the OS is too insecure to be able to trust the users with it.
And no, a "You are trying to hose your company's network, cancel or allow?" is not sufficient. If the user can't turn on the execute flag on the script to be able to run it due to lack of knowledge of security ACLs, then he obviously is not knowledgeable enough to know if the script comes from a reliable source.
Do people really chmod +x email attachments?!? I'd say your problem is in user education. Hell, any user knowledgeable enough to know how to set the executable flag should KNOW better!
I'm a Libertarian and I admit that the people have the ability to attribute to themselves the right to any oppressive or downright stupid government they want to as long as such government is not explicitly forbidden by the enumerations in the constitution.
;)
Now you have met one
Now, as a Libertarian, I would also stridently disagree with any group who supports the introduction of legislation that would give them the oppressive government they want, but in a strict constitutional sense, it's not *forbidden* (except where expressly forbidden). "Free medical care" is a great example. It's perfectly constitutional. I don't think it makes great sense, as it takes incentives out of the market, but I wouldn't attack the notion on it's constitutionality.
This is a correlation, true, but it does not show causality at all. It is perfectly plausible that those who are born poor are brought up in situations where they are likely to be more tolerant of the conditions endured by the poor. There is the question of motivation, genetics, environment, etc.. all being different between the 2 groups. For instance:
IQ scores have a strong correlation to income. They have an even stronger correlation to heredity. It is very possible that a strong causation for the trend you mention is that people of High IQ make more money, and then have children with High IQ who go on to make more money, whereas people of low IQ tend to make little money and have children of low IQ.
"All people, short of physical or mental disability, chose their own lifestyle in the United States." may be too inclusive (perhaps replacing that "all" with a "most" would be more palatable), and he cites no support references for the statement, but I wouldn't call it exceptionally retarded.
I was born poor, I now have a comfortable income well above the median for my age group and geographic location. That's not very empirical, I know, but I can say that through personal experience, the difference between being my personally being poor and my personally being "rich" are mostly a matter of being 1) motivated to change my economic strata and 2) knowledge of how to do so. The knowledge is freely available to all members of our society: there is no "secret" to getting rich (or, at least, comfortable.. but we will call that "rich" for the purposes of retaining the dichotomy). The formula is well known. Find something that needs doing. Educate yourself on how to do it. Do it. The more education needed to do it, typically the higher the profit. These are all "choices".
You could argue:
1) That the poor have little access to the knowledge of what "needs doing".
2) That the poor have little access to the education of "how to do it".
3) That the poor have little ability to do anything.
I disagree completely with #2, and #3. Resources are there. #1, is more salient, and I personally think is a driving for the poor "staying poor". There is much misinformation in their culture as to what "needs doing".
Anyhoo. I'm rambling now. I'll shut up.
You *could* make that argument. You do need a thoroughfare though, even to walk. We need some method of transporting ourselves and good across a privately owned 2-D landscape without sprouting wings. At the very minimum we need legal access routes. Now, can real road infrastructure be privately funded? It would be wonderful if it could, but that's a very hard problem to solve, as it's tough to make decent profits on roadways. Technology might come to the rescue here in the future, but for the last 200 years it's been nearly impossible. So we have an example of an infrastructure that is 1) necessary and 2) difficult or impossible to privatize. That's a good candidate for taxation.
On to "funding for the arts" for contrast. We all have a different view of "what is good art?" Almost no public expenditure is going to be appreciated by even the majority, much less nearly unanimously. Personally, I spent thousands of dollars last year supporting the arts. I purchased tickets for Basketball games. I volunteered time and money supporting youth dressage training. I went to quite a few live plays. I saw a few movies. I went to a few museums. I listened to music regularly, purchasing some, and listening to advertising to fund other outlets. And attended one symphony, which wasn't very good. I also watched some TV, more than I'd liked to have. So, my thousands of dollars and my volunteer hours weren't enough for arts? I appreciate art, and would be perfectly willing to pay a bit more money for tickets if my most appreciated art forms weren't profitable in order to make them so. It might cut down on my overall attendance, but I can cut out those crappy basketball games to give more money to a good Tom Stoppard production. If the government opted to not fund the arts I'm already funding with my taxes, and let me keep them instead, I would be able to spend proportionally MORE money on the arts... and they would be the arts *I* appreciate, as displays of Jesus floating in piss (to allude to a particularly bad publicly funded example) aren't really all that attractive to me. Additionally, by applying my time and money directly to the artistic institutions, I eliminate all the administrative overhead required to redistribute my funds under the public funded scenario, meaning the arts get more money and the political juggernauts gets less. So, we have an example of an institution that is either 1) Not necessary for our society (we can live without statues and Basketball games) and/or 2) Easily privatized, as I am a perfect anecdotal example of someone who funds it well, and I doubt I am too far outside the norm.
When a public institution is doling out funds, you better believe I expect them to keep these analysis in mind and prioritize where the money should go, eliminating expenditures to pay for arts and television sets in favor of roads and safety nets. Preferably, they should get out of the TV and arts businesses altogether, and let people who cater to those economic niche's handle that stuff.
sponsoring arts programs... Silly. There are alternative funding methods. I would rather not pay taxes for this.
paying for students to take field trips... Silly. There are alternative funding methods. I would rather not pay taxes for this.
building monuments to fallen soldiers... Silly. There are alternative funding methods. I would rather not pay taxes for this.
repaving roads... I can think of no one who does not utilize roads, they are a necessary infrastructure. Here's one we can agree goes into the homelessness problem level category!
Buying me and my neighbors a television... Silly. There are alternative funding methods. I would rather not pay taxes for this.
Hey! You're right! *ALMOST* every government expenditure *IS* silly! I'd like the surplus back taxes I paid back so I can buy some good art, donate towards some educational field trips, give some more money to a homeless shelter, help build a monument to veterans and buy myself a new TV, please. I can do this with negligible red-tape expenses, and in addition, I can ensure that it goes towards the causes I believe most in, I'll get the warm fuzzies instead of my congressman spending my money, and I'll do it voluntarily and enthusiastically instead of begrudgingly!
You, my friend, are a visionary!
Oh, and sorry neighbor. Buy your own damn TV.
I disagree completely. Hand writing simple code should not be difficult for a good engineer. You will miss semicolons on the whiteboard, no doubt, but you aren't being judged on how many stupid compiler errors the code will produce. Saying that you cannot write by hand a language you claim to produce fluently in, but rather you need a full compiler and editing environment, is like saying you can't speak anymore, but must use MS Word for all communications because of it's grammar checker and font changing ability. What goes on the whiteboard is pseudo-code, meant only for humans, that describes that 1) you have decent problem solving skills to come up with a halfway decent algorithm (primes are good because they don't need a "domain expert" hopefully, if you past grade school math and are in my office presenting yourself as an engineer) and 2) you can write something that at least approaches the structure of the language we want you to program in.
If not realizing that you can drop out of the calculations for prime verification early (not knowing it's the square root might be acceptable), and that you can again stop early if you find a divisor, are the level of optimizations that would have you hunting down "domain experts" in your world, then you aren't what we call an engineer in my world.
Now, granted, I have been on a couple interviews where I was judged on my ability to "correctly" write some silly algorithm, and was docked for not instantly seeing the best one right away, or for missing a semicolon here and there, but those types of interviewers completely miss the point of the exersize.
In my opinion, learn Haskell, and use if for your own projects. By learning Haskell you will be covering 90% of the stuff that they may neglect to teach you at school. Ideally you should learn Haskell, Scheme, Prolog, Erlang, Java | Smalltalk, and C, but if you can learn only one, learn Haskell.
;) It does do a decent job of showing you how to utilize OO, which is an important paradigm to know how to use these days. It doesn't go much further though.
Java isn't a bad toy teaching language
C is an obscure little language that compilers output to as bytecode before it goes to the final architecture dependant compilation stage. It's important to know how your high level constructs get implemented on the von-neuman architecture, so I recommend you do a little C too, as Java covers this up a little too much.
Scheme will teach you mutable code structure (and is just too fun to pass up), Prolog teaches some nasty cool logics, Erlang teaches concurrency. Haskell will teach you how to think like a programmer should.