Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment: Re:From Jack Brennan's response (Score 1) 772

by naasking (#48559761) Attached to: CIA Lied Over Brutal Interrogations

I think that it's more protective of citizens to behave in a way that isn't morally reprehensible.

That's an excellent and underappreciated point. The only difference between a morally reprehensible government-sanctioned action against a terrorist, and an action against you is an easily manufactured excuse. If morally reprehensible actions were never permitted, then the citizens need never fear their own government, which was the whole point of the constitution to begin with.

Comment: Re:Really? .. it comes with the job (Score 4, Informative) 772

by naasking (#48559711) Attached to: CIA Lied Over Brutal Interrogations

you can separate them and ask them questions then torture them when their answers don't match.

Except that doesn't work, because people being tortured will say anything to make it stop. At no point when they change their stories can you be certain they're now telling the truth. Even if their stories suddenly match, it could be a complete fluke, or as a result of the interrogator asking leading questions. Torture is useless.

Comment: Can't decide WITH CERTAINTY (Score 1) 335

One curious corollary is that if the human brain is a Turing machine, then humans can never decide this issue either, a point that the authors deliberately steer well clear of.

It's not curious at all. The goal was to determine if a computer can decide with certainty whether another agent intends to do harm. This is obviously unsolvable, even for humans. Of course, we don't require humans to be absolutely certain in all cases before pulling the trigger, we just expect reasonable belief that oneself or others are in danger (for a self-defence argument). Reasonable belief is even easier to decide for computers, since the internal states resulting in that conclusion are fully available to us (unlike the human mind).

Comment: Re:Gnome3, systemd etc. (Score 1) 450

by naasking (#48341915) Attached to: Joey Hess Resigns From Debian

When Debian pushed Gnome3 and the community didn't like it [...] Now there is the systemd debacle. A large number of people have voiced their disapproval [...]

You seem to be speaking for "the community", but I don't see any hard numbers suggesting that the majority of said community actually shares your opinions. Just because many voices cry out and cry loudly, does not make those voices representative of anything meaningful.

Comment: Re:Other factors. (Score 1) 217

by naasking (#48324547) Attached to: The Effect of Programming Language On Software Quality

While they do have the necessary language support for functional programming, the fact that they are impure means that even when you're following the functional paradigm you can't count on the rest of the program playing by the same rules. Any call to external code may perform I/O or depend on or modify global mutable state.

Sure, but triggering side-effects during a fold can be perfectly sensible, and this doesn't make functional programming languages any less functional. Find me one person that considers this program to be non-functional, as your definition does:

let main = let list = [10; 2; 99; 30; 3] in
    map (fun x -> printf "%d\r\n" x);;

Comment: Re:More factors to normalise out. (Score 3, Interesting) 217

by naasking (#48318169) Attached to: The Effect of Programming Language On Software Quality

Oh, I also forgot to mention:

and that your resources are freed deterministically the instant you are done with them, rather than "at some time in the future, maybe".

Except this can lead to extremely high latency due to cascading deletions, which is another potential source of performance problems in C/C++. If you try to bound the amount of work to do to avoid this problem, you necessarily introduce reclamation latency. Reclamation latency isn't necessarily a bad thing.

Comment: Re:Other factors. (Score 3, Informative) 217

by naasking (#48317415) Attached to: The Effect of Programming Language On Software Quality

Having closures does not make a functional language, instead, what makes a functional language is referential transparency.

Scheme, Lisp, OCaml are all functional languages that are not referentially transparent. Pure functional languages require referential transparency, but impure functional languages do exist.

JavaScript is a functional language, but it's also procedural and object-oriented.

Comment: Re:More factors to normalise out. (Score 1) 217

by naasking (#48317397) Attached to: The Effect of Programming Language On Software Quality

C/C++ certainly let you shoot yourself in the foot regarding correctness, but they generally don't make it easy to shoot yourself in the foot regarding performance.

Sure they do, you're less likely to go through the hassle of creating a data structure that would be optimal for your domain simply because of the complicated memory management issues it raises. This is a complete non-issue with GC'd languages, so you're far more likely to do the (asymptotically) right thing.

Comment: Re:Redistribution (Score 1) 739

by naasking (#48287083) Attached to: Statisticians Study Who Was Helped Most By Obamacare

More people means more risk, more risk means more cost, that cost is distributed among the group by taking more of their income.

More people does not necessarily mean more risk. More people can in fact, and often does, mean less risk.

Ergo, more income is being redistributed. So although you are technically correct in your statement about causality; in the context of this scenario your statement is wrong.

Income redistribution plans apply to everyone. Obamacare applies only to those who get health insurance. Therefore, it's not an income redistribution plan.

Comment: Re:Non-system Admin Here (Score 1) 863

That aside, will people please stop this constant masturbation about startup times? There are way, way, way more important things to deal with than edging out a few more seconds. Systemd provides me with no perceivable gains.

Since you argue about systemd from a user's perspective, then your own argument implies that you shouldn't care at all what sort of init system is in place, so why be against systemd? Given your view, it's purely a distribution's choice what init system to use because it's largely invisible to the user.

"The identical is equal to itself, since it is different." -- Franco Spisani