We got the sentiment that we could do anything, yes. But it also gave us, at least briefly, a reason to be humble.

To me, at least, this is the most important thing to come out of the Apollo program.

It might be whack-a-mole, but the law is having smaller and smaller ground to stand on.

All information is just a number; this sounds like a facetious remark but it's really central to this whole ordeal. A 3 megabyte MP3 file is an extremely large number (by our standards), usually somewhere around 2^3,000,000. A magnet URI is a much smaller number, usually around 2^128, and magnet URIs are literally just numbers.

The problem here is that current copyright law says numbers can't be copyrighted, and common sense even among non-math-literate folks says that no number should be illegal. I'm not about to argue that all data cannot be copyrighted, I'm just pointing out that there's a rather glaring inconsistency in copyright law that can be exploited by moving data needed to torrent something into a smaller string. Most people would be okay copyrighting 3 megabytes of data, but fewer would be okay with copyrighting 128 bytes. Especially if those bytes have no meaning other than just a number.

Wikipedia has a good article on Illegal Numbers. It's going to be a fun day when this all finally comes to a head.

I thought this too, for about a second. There's a lot of good IP that EA holds that could do with a very long and loving Valve-style update. But this would be a very dangerous move to make.

Valve is flat. Everybody decides for themselves what to work on. This is a hard environment to maintain, and so their hiring process is extremely important. It would be almost impossible to work in former EA employees without causing a major upset in Valve's company culture. The other option would be buying them but running them as a separate studio, which might work, but I would still fear culture leak.

Everything that Wayland does is possible under X, it just might be hard to write the X code to do it.

The biggest point to Wayland is that it is extremely simple (compared to X... X is huge), and it's capable of doing 95% of what people use X for. The other 5% is network transparency, a feature I hold dearly but one that I acknowledge not many people care about.

So what's so great about simple? For one, it's easier to maintain. It's also easier to write clients for, since it's almost entirely OpenGL (the Wayland part is small). The X library is a horrible horrible thing, and I would die happy if I never have to use it again.

This is almost exactly what Wayland is doing. Wayland is a communication protocol between compositors and the things they composite: usually, between window managers and applications. This means that the window manager is responsible for communicating with applications, and for pushing video data on to the screen (via OpenGL + Kernel Mode Setting). So instead of launching X, then launching a window manager on top of that, you just launch the window manager.

This is the primary advantage of Wayland: it's simple. Really really simple. It's basically just OpenGL and a protocol for delegating render surfaces to other applications (to render on to using OpenGL). By comparison, an X server needs font rendering, shape rendering, and a ton of other things that aren't used today anyway because everyone uses freetype and cairo and such. Wayland leaves those out and expects you to get that from other places (like, say, freetype and cairo).

(Wayland is also the name of a C library implementing the Wayland protocol. The Wayland project also produces the Weston compositor, as a reference implementation of a simple "window manager".)

The DSL Linux CD disk is read by a LASER radiation beam.

I initially wrote this to be facetious but laser radiation beam actually sounds cool.

Be very careful here. Most applications written for iOS are written in Objective-C, while most applications written for Android are written in Java. Yes, they share very similar underlying design philosophies, and some of the same underlying tech (OpenGL, posix), but porting can still be very difficult. Compiling Objective-C for Android would be a nightmare, and converting Java bytecode into something compiled for iOS is similarly hard, and that's after you write an API compatibility layer.

Mobile programs are only easy to port if they were written from the beginning with porting in mind, either by using an intermediate API and langage (like MonoTouch), or by writing everything in C and keeping the Objective-C/Java parts to a minimum. Unless this was planned, most people don't go this route, and porting those programs would be more appropriately called "rewriting".

The situation between OSX and Linux is similar (though not quite as bad). Porting from Linux to OSX is easy, because most Linux programs are written in languages also available on OSX. However, OSX to Linux is hard because, again, most OSX apps are written in Objective-C. You can compile Objective-C on Linux, and a lot of OSX APIs are re-implemented by the GNUStep project, but GNUStep is missing proper support for some language features that are heavily used in OSX. Which means that native OSX apps that were not written with porting in mind become extremely hard to port.

The good news in the specific case of Steam for Linux is that almost anything available on Steam for OSX is also on Windows, which means it has already been ported, and porting to Linux shouldn't be that hard. So yes, this statement is correct in this specific case, but your comparison isn't and "it's easy to port from OSX to Linux" is an extremely common misconception.

As RMS mentioned, the danger is not in Linux becoming a locked down system, the danger is in people using Linux because it costs nothing rather than because it gives its users freedom. Whether you agree with RMS's stance on freedom or not, it is pretty clear that making Steam on Linux a major selling point of the platform would detract from the message of freedom.

I would also remind you that the choices we hold so dear as Linux users are a direct result of these freedoms, such as the freedom to change the software you run as you see fit. Linux itself, and the GNU tools that run on top of it, will always remain free. But Linux is also a tool for promoting the idea of freedom, and Steam on Linux might weaken that.

(Personally I can't wait for it, though.)

Me and my brother recieved the silver Buckyball cubes as Christmas gifts a few years back. These things are a blast to play with.

When one of the balls on my brothers set shattered, we called one of the listed numbers for the company to ask about maybe purchasing a replacement ball. The person on the other end was extremely interested in how this happened (apparently they hadn't had a report of a ball shattering before), and offered to send us an entire new set for free. On Christmas day. This was excellent, excellent support for an awesome product.

It's sad to hear about this.

-- Accelerando , by Charles Stross

BSD does not guarantee access to the source; it defers this choice to whoever is distributing it.

BSD lets distributors decide whether the user has access to the source, while the GPL guarantees it. You can't do both: it's impossible to let the distributor decide whether to give the source to users and also guarantee users have access. Often, authors of BSD-licensed code choose to distribute the source for free, and it's quite possible to create a much freer environment than you can with the GPL. But the GPL guarantees access to the source and the ability to run modified sources, on every project. With BSD, you have to research each individual project to see if these rights are available, then worry about whether they will be taken away.

I always thought about it this way: the GPL is about user freedom, and BSD is about developer freedom. If you're using GPL'd software, you are explicitly given the right to know what it's doing and the right to change it. If you're developing with BSD software, you're given the right to control how it's integrated into your project and how it's distributed. Unfortunately it's impossible to guarantee both rights at the same time; the correct choice for each project depends a lot on how that project is meant to be used.

I lean towards GPL, because there's nothing more frustrating for me as a programmer than not being able to control or fix something that's running on my computer. So when I write software, I try not to put anybody else in that position. I appreciate the appeal of BSD, though, especially when I'm working on something to sell, or on a restricted platform (like iOS).

Personally, I like the fact that the Objective-C parts of the code look completely different than the C parts of the code.

C++ tries really hard to look like a natural extension to C, and in some respects that's an admirable goal. Sometimes, though, it can be confusing. Consider the following bit of code:

void test_func() { SomeObject obj; }

In C, this function does nothing, and after a quick glance you'd be tempted to say it does nothing in C++ too. But in C++, declaring a variable calls its default constructor, which could actually do something. It looks like C, but it acts nothing like C.

With Objective-C, you avoid the problem entirely because it looks nothing like C. You're never tempted to think "oh, I know how this works in C so it must work similarly here". You might not like it, but I happen to fall into this trap a lot, so I appreciate the syntax.

From the perspective of an expert user, {thing the user is expert with} is the superior tool.

I'm a little out of my depth here, but I'd imagine it'd be much easier with UDP because UDP is connectionless. With this sort of roaming, the server isn't expected to change addresses, but the client is. So, have the client sign everything with a negotiated public key, and the server doesn't even have to care where each packet is coming from, or even open any new connections when the client moves across IPs.

Since this is an SSH replacement, I'd expect the key signing to be done already, so once you build an ordering and reliability protocol on top of UDP you essentially get the roaming for free.