For the sake of argument, let's say that's true. Rights are inherently subjective; the only constraint is consistency. If you have the right, so does everyone else. On that basis, let's say someone did put you under surveillance, and you found out about it. What would be a proportional response? Your only "damage", if you can call it that, is the subjective emotional impact of being aware that you're under surveillance. Imprisonment and/or loss of property would clearly be out of proportion. Reciprocation would be fine, of course, but would also be unlikely to have much effect on someone who truly believes in ubiquitous surveillance.

Legal rights work because there are some rights that it simply doesn't pay to disagree with. The right to life, for example—if you disavowed that then anyone could try to kill you without any legal consequence. Or property rights—if you claim that property is a right then others can deprive you of the products of your labor at any time, leaving you with no more than the barest minimum you need to survive. The proposed "right to be free from ubiquitous government surveillance" doesn't work that way, because the people wanting to do the surveillance don't mind having it applied to them.

If you don't wish to mine bitcoins yourself then yes, you'll need someone else to do that for you. At that point you can buy them directly from the miner (e.g. via localbitcoins.com) or you can trade for them on an exchange. In the latter case, you can immediately withdraw the bitcoins to your own private wallet. Either way, there is no need to leave yourself vulnerable to any third-party after the transaction is complete.

You can't copy bitcoins, only private keys. (There's nothing to copy; the bitcoin is an abstract unit of account, not data.) If you have the other party send the bitcoins to an address for which only you know the private key, then only you can spend those bitcoins.

These "extra parts" consist of some containers and a length of pipe. Not exactly hard to come by. You're mainly paying to avoid doing the assembly yourself (est. one hour, probably more for the inexperienced).

Agreed, though you could mitigate that somewhat, at the expense of resolution, by moving the laser assembly further away from the resin. But to each his own.

I think you're just being cynical. They're a small group whose specialties clearly do not include marketing, and they're perhaps overly fond of trendy video effects, like the blurring you mentioned. There are some clear close-ups of the objects from the video in the December Kickstarter update, however, and an earlier update from November included photos of some additional prints.

None of this is to say that the Peachy is intended to compete with multi-thousand-dollar printers, because it isn't. It may or may not have the resolution for the object in the article; either way, you'd run into issues due to the size. The sample prints for the Peachy are tiny. The quality is quite a bit better than one would think from the image you posted, however, which is all I intended to say. It's pretty remarkable, really, for a device they plan to sell for only $100.

That's one of the earliest prints, with pre-alpha hardware and software and practically no calibration. Now that the project is getting close to completion there are more recent videos demonstrating higher print quality.

The Constitution doesn't say anything about "targeting" someone. What is unconstitutional is performing a search—that is, forcing you to grant the police access to your property as part of an investigation—or seizing your property without a warrant for that specific search or seizure, supported by documented probable cause to expect that the search or seizure will turn up evidence that the owner was involved in the particular crime being investigated.

On the other hand, no special police powers are required to simply record anything and everything visible to the public, even if the recording is ubiquitous and systematic. Doing so may be rude and uncivilized, but it doesn't violate anyone's rights.

It's always seemed kind of stupid to me that you pay your ISP to let some third party send you data, with the ISP paying some upstream transit provider to be on the receiving end, when the postal service and package delivery have always worked the other way around. When you order goods online you pay the retailer for the cost of shipping, and they in turn pay someone to deliver the goods to you. A fixed rate for maintaining a connection to your ISP would be reasonable, much like paying for your own local roads, but paying for what others send you (whether you requested it or not) makes no sense. Better to pay sources to send you content, with the payment covering the cost of delivery along with all the other hosting costs.

Bitcoins aren't numbers. If they were then you couldn't transfer fractions of a bitcoin, since each fraction would need its own unique number. They're fungible abstract units, much like dollars or euros, or even points in a game. The GP's understanding was closer to the mark. The hard-to-compute part comes in when you work toward confirming transactions by solving a block; as a reward, you're allowed to include a "coinbase" transaction in the block which credits a certain amount of freshly-minted bitcoins, plus any fees from transactions in the block, to an address of your choice. The coinbase transaction, like other transactions, is just a notation in a ledger associating a certain number of bitcoins with certain address(es).

To answer the GP's question, all Bitcoin transactions are public, but only in terms of the addresses, not real-world identities. If Mt. Gox were to publish the public part of the address the coins were in before they were "misplaced" then anyone could look that address up in the block chain and see which address(es) they were transferred to. Of course, that could just be another address belonging to Mt. Gox. There's no way to prove that they don't have the private key.

The GP already alluded to that. But that gives you control over the funds in a new wallet, not control over the original wallet. If someone sends new funds to the old address you won't have exclusive control over them until you've transferred them elsewhere.

Think of wallets as free, unbreakable safes with fixed combinations. If someone else learns the combination, you can move the contents to a different safe that only you know the combination to (as long as you get to it first), but the other party will always be able to get into the original safe.

And how often is that the case? If you want a table layout, you have to structure the underlying HTML as a table (even if you prefer to use divs instead of a table element) because CSS can't affect the presence or order of the tags. Given that you have to write the HTML with the layout in mind anyway, why not simply have a <gridlayout> tag (and <hbox> and <vbox> while we're at it) to distinguish table layouts from semantic <table>s, rather than relying on generic <div>s organized as tables—as opposed a way which would make sense semantically—but still ultimately dependent on a mass of boilerplate CSS to actually be presented as intended?

Of course, if they were actually serious about separating presentation and sematics, the top level of the page would probably look more like XUL or QML, with the main content (either embedded or pulled from separate files) written in a subset of HTML with no support for scripting, styling, or layout, just pure semantics.

That is true, but adding the RDP backend to Weston does not appear to have required very much in the way of actual code. Most of the work is left to the FreeRDP library. I expect that most Wayland compositors will prefer to share a common library of backends once we have more than one in actual use on the desktop, much as the Wayland protocol handling is delegated to libwayland. Until then, the E19 compositor should be able to simply copy from Weston to get the same capability.

As for stacking compositors, that might be possible. Weston supports Wayland as a backend; E19 may do the same. If so, you could forward the entire E19 compositor over RDP as a client of Weston.

You're talking about online wallets, not Bitcoin. Bitcoin isn't banking, and doesn't have deposits, just a note in a shared database that says a certain number of bitcoins were sent to your address, and can be sent on to someone else if you supply a transaction signed with a certain key (or set of keys). It's all just communication and consensus, which puts any attempt to regulate Bitcoin itself on fairly shaky ground with regard to the First Amendment in the U.S., or freedom of speech in general internationally. Online wallets and exchanges are a different matter, of course—particularly if they deal in national currencies alongside Bitcoin—but you don't have to use them.

The same place anyone else would get it from, if they bothered to look: research on how modern graphics pipelines work, how modern toolkits work, and the design of the X11 protocol. With a few exceptions (mainly text via the new XRender glyph extensions, excellent for terminal emulators but not much else) the X11 protocol encodes pixel-oriented drawing primitives which are no longer directly supported by current graphics cards, or even efficient to emulate (e.g. pixel-accurate aliased ellipses, stipple patterns) and which can't be efficiently mixed with direct rendering on the client side via OpenGL and DRM. Standard rendering these days—using GTK+ 2.8+, Qt 4+, or a custom toolkit based on Cairo or OpenGL—consists of drawing into a buffer with OpenGL or into a pixmap with the CPU, and then handing that buffer or pixmap to the X server just so that it can hand it over to the compositor. That works okay locally due to shared memory, despite the extra overhead of having the X server in the middle, but it's hardly "network transparent", especially given that the protocol doesn't provide for any means of compressing pixmaps.

It's simply more efficient to let the client do all the drawing with local graphics resources and push the resulting surface to a remote compositor, particularly if you can take advantage of hardware-accelerated video codecs. That's how the application is designed to work anyway, but with X11 it only works well if the application is local. Otherwise you have to use some sort of fallback in place of direct rendering (perhaps XRender, but more likely software raster), doubling the development and testing effort, and the resulting solution requires more bandwidth and lower latency than a properly designed remote video protocol.

You seem to be under the mistaken impression that I was quoting someone. I was not, therefore no quote was taken out of context.

Like I said, modern applications. That means applications designed for modern computers, not just ones written recently. Sure, you can stick to X11 primitives provided you don't care about performance or power consumption or your UI looking like it dates back to the 90s. Apps written for X11 will continue to work using the same network protocols they've always used via XWayland, inefficiently emulating ancient hardware. However, programs written with modern graphics subsystems in mind will benefit from the remoting approach taken by Wayland.