Also ALL of Apple's documents currently present side by side the ObjC and Swift API.

Only the API reference documentation, not the conceptual docs, the sample code, etc.

There's going to be tons of Cocoa stuff to mess with. You're basically using all the Cocoa classes, just with a bunch of extra wrapper code, in a language that's slower than Objective-C, for little real benefit beyond syntactic sugar.

Worse, as things stand right now, if you start out using Swift, you're going to quickly start running into walls where the introductory documentation you need just doesn't exist yet. And when you get into trouble, you're going to go searching for code snippets on Stack Overflow and using Google, and approximately 100% of those snippets are going to be in Objective-C, not Swift, which means you'll have to know enough Objective-C to translate those snippets into Swift. In other words, if you don't already know Objective-C, learning Swift requires a fair degree of masochism right now.

So no, new developers to the platform should definitely start by learning Objective-C, and should reevaluate that decision after they have gotten comfortable with Objective-C. In two or three years, assuming Apple doesn't drop Swift like they did their last three or four scripting language bridges, there should be enough Swift documentation and code snippets to support developers who are just starting out, and companies will be just starting to hire a non-negligible number of Swift developers for serious work. Learn Swift then.

Encasing it in glass ingots doesn't waste it, it merely makes it a bit more difficult to access when you come up with a good use for it...but it keeps it relatively safe until you do.

Burying it at the bottom of a subduction trench, now, that's wasting it.

Geosync orbit is a bad idea. That orbit is very useful for other purposes and already a bit crowded.

OTOH, it wouldn't need to be *very* much higher to be much more reasonable...but be sure to put it all in one place. You don't want even more junk spread around.

Well, I'm a current Debian user, and I switched from testing to stable because of problems with systemd. OTOH, there's a good reason that it's called testing.

Still, while I don't hate systemd, I also don't trust it. My current intention is to remain on stable while things shake themselves out, and then decide what to do. And the Devuan timeline doesn't show it being available even as a "testing" distribution until next spring. (I gather the current version is sort of a compromise between prototype and unstable[sid], or even experimental.)

By the time I need to decide, I expect I'll know how things are going to shake out. But I expect that I'll be keeping an eye on Devuan, and a few others. And perhaps systemd won't be as bad as I expect. Still, any init system that marks problems with its logging system as "won't fix" is dubious. That the main logging system is binary just makes things much worse. So does expansions like having the "init system" include things like terminal manager, etc. It even makes me tempted to go back to Etch (yah, that's a rediculuous thing to suggest, as the current stable works fine without systemd).

Diversity is a good thing. I understand that, with increasing use of Linux as a desktop OS by people who don't run servers, systemd makes a lot of sense for some people.

I am the primary admin on servers in three different states. The benefits of using init for remote admin outweigh the simplicity and user-friendliness of systemd on my laptop.

I switched from Mandrake to Debian almost fifteen years ago when I first started doing heavy remote admin, I'll make a change again now, and the world will keep on spinning. Having both approaches is a good thing.

Why not? It's been our philosophy for centuries not to worry about the future and just expect that future generations will have more wits and basic decency than us.

Another problem is that it's based on the fallacy that economics is a zero-sum game. And that physical money is a good analog of financial money. Both are false.

Another assumption is that feeding the starving is a reasonable approach. But population growth is exponential until a limiting factor is reached, and exponential growth cannot be sustained. Ever. So if you plan to "feed the starving multitude" you'd better have some plan in mind to feed twice that number of people in 20 years.

Personally, I think we are already beyond the sustainable capacity of the planet. We're emptying the seas of fish and the land of anything we can't eat. At some point we're going to crash, and crash badly. It would be highly deisreable if at that point there were some self-sufficient colonies elsewhere. But we are, to be optomistic, decades away from being able to do that.

Your point, while partially valid, is nevertheless misguided. ALL viruses are specialist parasites. What you need to "infect" a planet with life is something like a lichen, bacteria, or plant.

None of what you're talking about has the slightest bearing on what we're talking about. I fully agree that screwing your customer to extort money out of Netflix (or whoever) is bad. What I'm saying is that if you're on a capped connection—capped in terms of total data quantity, not instantaneous speed—there's no neutrality violation involved if Netflix agrees to pay your ISP so that their usage doesn't count towards your cap. That's not a double dip. It is quite literally exactly the same as calling a toll-free number; you pay your ISP for service, plus you pay for your use, but the company on the other end chooses to pay for your use instead.

What would be a violation is if the ISP demands that Netflix do so, or else they won't provide the instantaneous bandwidth required for a satisfactory customer experience. Similarly, if an ISP charges extortionate overage fees for going beyond your data cap, rather than something reasonable and proportional, that's a potential net neutrality violation in that it essentially forces Netflix to become a toll-free service to avoid screwing over their customers.

It does violate net neutrality, because it affects the cost of delivery of data to and from the end user.

But it doesn't. The cost is still the same, regardless of who is paying it. What it does is shift the burden, at the request of one of the parties. That's not the same as shifting the burden at the request of someone who isn't a party to the communication (your ISP). And changing the cost of the communication isn't really any different from changing the cost of the content. If Apple (for example) chooses to pay your bandwidth bill for downloading a movie, they could lower the cost of the movie by a few bucks and it would have exactly the same effect on the customer in practice. In fact, they would probably be better served by lowering the price, because customers see the price of the movie, and probably pay for their bandwidth bill using auto-debit. :-)

Either way, the TCP/IP equivalent of toll-free calling certainly isn't in the same category of wrongness as your ISP limiting the rate of traffic in a way that makes your communication impossible or impractical, and the reason most of us want net neutrality is to prevent that sort of abuse, not to prevent any slight distortion of pricing.

If every other website on the Internet besides Netflix and Amazon pays a fee to be included in that "premium" quota, then yes, it is consistent with Net Neutrality. It is also about as likely as Santa Claus getting the Tooth Fairy pregnant.

They want all destinations to be equal

No - they want all internet connections to be paid for according to last-hop bandwidth to their endpoint and to work according to the standardized protocols of the internet when sending/recieving data to other destinations from that link, and for any other business related decisions concerning traffic to occur according to those same principles

Which is precisely the same thing as saying that traffic priority should not be dependent upon endpoint—i.e. that all destinations are treated equally—but with about forty-two extra words.

Firstly it's not about content delivery companies at all. It's about network operators, and network link pricing. Period.

Network operators are a pipe to content providers, so any definition of net neutrality that ignores the content providers is fundamentally missing the whole point of the network. The purpose of net neutrality is to ensure that your link provider cannot artificially distort traffic in a way that makes it impractical to use arbitrary services, forcing you to the services of their choosing. Manipulating network link pricing is just one mechanism for distorting traffic, and is quite possibly the least interesting, least effective way to do so.

And yes, when 'the tools at their disposal' include bandwidth tiering (free vs non-free) in an effort to distort end user preferences towards their internet-based service, and thereby shift the fundamental usage of the internet itself (away from free, open standards p2p protocols and towards proprietary 'walled-garden' services), this is, in fact, not a neutral practice, and is in fact a problem.

Your argument is illogical. There is no difference between a content provider paying for the user's data usage and lowering the price of the content provider's service by enough money that the user can pay for a connection with a higher data cap on his or her own. Thus, paying for the user's usage does not violate any fundamentally sound concept of net neutrality in any meaningful way. Admittedly, in the case of Wikipedia, they're taking it one step farther and charging a negative fee for their service, which is a little odd, but if that's the way they want to spend their donations, so be it.

Now taken to the extreme—unusably low data caps combined with provider-paid exceptions—could potentially be a net neutrality issue, if only because it would be harmful to free content providers. However, that scenario is pretty darn unlikely. There are too many dozens of free, moderately high-traffic content providers for that to happen in the foreseeable future. If that changes—if all the world's websites consolidated themselves into just a handful of server farms—then it would make sense to reevaluate things. Unless and until that happens, however, it makes little sense to create laws in an attempt to prevent problems that are purely hypothetical. Doing so adds extra regulatory burden without solving actual problems, and worse, gives businesses more time to look for ways around those regulations, ensuring that by the time they are actually needed, they don't work.

And more importantly, none of the proposed solutions for net neutrality that I've seen would prevent this sort of "collect calling" anyway.

All you're doing is delinking from a search engine. If someone else comes along and builds a search engine and spiders your false accusation, then your right back in.

The rule is moronic, passed down by malicious halfwits.

The thing is, every company could do those things if they want to. Individuals could do so if they wanted to. It's no different than having a 1-800 number. You pay so that the person calling you doesn't. There's no neutrality violation there; if anything, it improves net neutrality by providing a reasonably priced mechanism for allowing other companies to be on equal footing with Comcast, who almost certainly does not charge their customers for the use of their own, in-house video-on-demand service. You might reasonably argue, however, that it does so only if the cost of said toll-free service is regulated.