Um, you realize that C came out at almost exactly the same time, don't you? Granted, I wasn't programming anything in the 1970s, but I know enough history to know that the Unix kernel was already being ported to C right around 1970.

Assuming that the obsolete compute modules are of standard size/pinout (or, more likely, that compute chassis are only produced for phones that ship in sufficiently massive volume to assure a supply of board-donors), this scheme would work; but I have to imagine that a phone SoC would make a pretty dreadful compute node: Aside from being a bit feeble, there would be no reason for the interconnect to be anything but abysmal. For efficiency's sake, SoCs tightly integrate all the parts that need to chat at high speed with one another(along with whatever else fits, just to save board space), and only such interfaces as are absolutely necessary are brought out of the package, much less broken out on the board in some sort of civilized connector. In terms of dedicated interfaces you'll have some dubiously appropriate wireless stuff, a USB slave or host/slave interface, and a few GPIOs. The only options with really serious bandwidth or low latency would probably involve creative(and not necessarily possible, depending on the situation) abuse of camera and screen interfaces.

For all those nice, tractable, problems that behave well on loosely coupled nodes, each individually quite feeble, I guess it'll work; but that certainly doesn't include most of the really obnoxious computational crunching problems.

"Lacks" is a strong word; it's just not inherent. Back when I used to write software in C and C++ for money, I would religiously put "}//end if" to make sure I could keep track of which braces went where. If I needed even more context, I would put " }//end if(var1 == var2). It's not that hard. Like many things in C, you have plenty of rope to hang yourself if you really want to, but you can also make it tidy and sensible if you care to. C is not your friend, and is not your enemy.

C is like an M1 rifle. Sturdy, proved in battle many times over, occasionally finnicky, and ready to put a high-powered round precisely where you aim it without apology. Whether you aim at your foot is your business.

Right. It doesn't seem like a threat to say 'if you pass this then we'll have to actually do our jobs!' It just makes you wonder what they're doing now instead...

As much as I'm deeply displeased that the attitude would be 'give us what we want or we'll take it, Stasi-style'; I'd see a situation where the spooks are forced to resort to physical intrusion as a vast improvement.

Implicit in the GCHQ flack's 'threat' is the idea that totally invisible 'no touch' surveillance is somehow better and nicer. In the sense that it has better PR, and is easier to maintain (and on a massive scale) without public outcry or logistically overwhelming amounts of black-bag work, this is true. In terms of the relationship between the clandestine agencies and even the pretense of democratic government, though, I'd say that it's exactly the opposite.

If team spook has the advantage of technology for scale and efficiency, and is capable of invisibly watching more or less everything without any visible signs of having done so, you have about as imbalanced a situation as one could reasonably imagine. A perfect panopticon; but so subtle that you sound like some sort of schizo nutjob for suggesting that it is happening. If they actually have to break and bug, this will mean more physical intrusion; but it also creates a de-facto limit on how broadly they can pursue fishing expeditions, and how reasonably they can make the assumption that they will never be caught.

If what he says about more encryption is true; bring it on.

explosives?

chemicals my friend

wouldn't take much of the right kind. nice aerosolizer already provided by the craft

biologic if you're exotic

nuclear just plain stupider

but for maximum shits and giggles and no loss of life, i'd load a degaussing coil on a drone and fly it through a target office. do a little tap over all the workstations to get the hard drives

oh shit, am i on some list now?

That's (among the) downsides of our obsession with risk-minimization, overwhelming force, and technological supremacy. Whether it's using $40k hellfires to destroy rust-eaten technicals in hellholistan or calling out the bomb squad every time somebody tosses a paper airplane over the white house fence, we really need to maintain that economic superiority if we want to survive the sheer attrition.

the topic is

Anonymous Asks Activists To Fight Pedophiles In 'Operation Deatheaters'

do you have anything useful to say on the topic?

that's what i tried to do, and i got many even tempered, thoughtful replies, on topic (except for yours)

http://slashdot.org/comments.p...

but for me to speak on topic, eliciting on topic responses... that's "trolling" according to you

meanwhile, all you seem to do is talk about *me*. why? how is that useful? how is that helpful to the topic? i'm not the topic douchebag

if you desire some sort of interpersonal friction, you might want to try a dating site. otherwise, shut the fuck up, and stay on topic, or you're a useless troll

What I find utterly insufferable about this 'argument'(if it rises to a level where you can call it that) is how badly it misses the point:

Netflix and a few friends say that 25/3 is needed because a household might be streaming multiple things while running a cloud backup and doing some skyping or something. Verizon et al. say that such usage is atypical, and therefore everyone can take the status quo and like it.

In both cases, the most important bit is being ignored: new uses for bandwidth are not going to emerge(or are going to be academic and deep-pocketed-corporate curiosities) unless there is at least some prospect of bandwidth being available. Does 'today's typical use case' need 25/3? Probably not; because it was developed under the constraints of a market where 25/3 is markedly above average, so anyone developing products and services is condemning themselves to a niche if they require very high bandwidth, especially upstream.

If just doing what you did last year, forever, was good enough, 'broadband' would still involve an acoustic coupler. Chicken/egg.

Actually, a lot of these games just use WINE's implementation of DirectX. This either translates the calls to OpenGL or implements a DirectX state tracker directly if you have Gallium drivers configured correctly. The same is true of a lot of Mac games. Good luck getting WINE to run on a console though...

Your typical GPU driver is about 10MB of object code. It contains a complex optimising compiler and controls a device that has complete DMA access to your computer. It is written with speed as the only significant goal. Making a GPU driver 1% faster contributes enough to sales to pay the salaries of several driver developers. Making the GPU driver more secure generates zero additional sales.

The shader code that's fed into this stack from WebGL is sanitised and is completely safe to run, assuming that your driver stack is 100% bug free. Still feel safe?

If you write a game that uses Direct3D, you can easily target Windows, XBox, and Windows Phone. If you write a game that uses OpenGL, then you can easily target all of the major desktop, mobile, and console platforms. If your game runs on a generation-old console, then it will run on current-generation mobiles as well. This gives you three markets: First release for high-end PCs, second for consoles, third for mobiles. You can get a solid revenue stream out of each one. You don't lose the Windows marked by choosing OpenGL, but you do lose every other market by using Direct3D.

That said, the APIs are so similar these days that you'll typically use some middleware to provide the abstraction. All of the important code is written in the shaders and these are much easier to port between GLSL and HLSL than they are to port between different GPUs and maintain performance.

Implementing this in the standard library means that the language needs to support pass-by-reference (which Pascal and C++ do, but C doesn't). This single feature does a lot to reduce readability. In C, I know that inc(x) is a function that does not modify the value of x, without reading any additional code[1]. In Pascal or C++, I need to look at the definition of inc() to know if x will be the same before and after the call.

An important idea at the core of readability for a language is the amount of code that I have to read to understand a single line. In any language that has pass-by-reference, this amount is larger than a language that doesn't. To achieve the same thing in C, I'd have to write inc(&x), and then everyone reading that code would know that x may be modified. (Note: the almost-equivalence of array and pointer types in C is a good counterexample where Pascal wins massively in readability).

[1] It could be a macro, but most coding conventions require macros that can't be used as if they were functions to be all-caps.

This would be true, except for two things:

• Lines with more than 66 non-whitespace characters decrease readability.
• Statements with more than 66 non-whitespace characters are common in most programming languages.

This means that you end up either with lots of continued statements or lots of overly-long lines in Python. If you have the former, then it's hard to see the indentation. If you have the latter, then you can see the indentation but the overall readability suffers. This can be fixed by using tabs for semantic indentation and spaces for alignment and an editor that supports highlighting tabs, but the Python style guides tell you not to do this.

There are some simple things where C is far more readable to a moderately experienced programmer. Consider the beginning and ending of blocks. In pascal, these are signified by begin and end. When you look at a chunk of Pascal code, they can be hard to pick out because they're just words in a sea of words. In C, you use the { and } symbols. These are symmetrical and the human brain has spent a lot of time evolving to be trivially able to spot symmetry because symmetry normally means 'predator about to try to eat me'. You can very quickly spot a column that has a { at the top and a } somewhere later (much more easily if they're aligned together and there's nothing else on the line). There were some studies done in the '80s that confirmed this, though sadly a lot of C coding conventions specify brace placement in a way that reduces readability.

The main strength of Pascal is that it forces you to think more than C. If you don't write what you mean in Pascal, it usually fails to compile. C will happily do... something. This level of redundant verbosity makes Pascal both quite a frustrating language for experienced developers and a great language for teaching. I find that people who learned Pascal tend to write better C code than those that didn't, but neither group has a strong desire to write Pascal.