The problem is that you have to work it like a job in order to advance. People get pretty cross when what they've worked for hours to attain is lost in a matter of seconds, especially when it's just because someone is feeling like being an asshole.

No, it means "I don't have to spend hours and hours and hours grinding only to lose all my progress in seconds". Casual gamers don't want to grind.

You won't be able to do that with this game, because the game requires the server, and instead of giving the server to the backers so that they can run their own single-player games like they would do if they gave one fuck about the players, they are keeping it for themselves so that they can profit from it. They are keeping half of what they promised to deliver to the backers. That is bait and switch, and therefore fraud, because they are able to provide single-player: simply deliver the server component to the player.

I predict that if they have free servers that they will be shit, and that you will have to pay a monthly fee for access to a server that doesn't lag you into oblivion. As my internet connection is crap, an online-only game is simply not an option for me at all, so I would be livid if I had backed this kickstarter.

I've backed two kickstarters so far. The first one was the new space quest game, which the discerning reader will note is years overdue. YEARS. That is to say, it's still not there. The other was the infrablue photography kit which was actually delivered. Until I get the rewards from my first Kickstarter, though, I'm not even going to look at their site. I am not even considering contributing to any more projects.

Kickstarter is a Bad Deal if you don't have money to throw away.

A competent team would be able to do that on the client. And in fact, they are probably able to do that, too. But they made the decision to make it an online-only game for some reason; either they are going to sell subscriptions and all the people making excuses for them right now are going to be madly pissed off, or they're going to be selling advertisements in-game. Hence they don't want to include their server in the package, because you might figure out how to make it host games without them deriving benefit. And taking the goodies out of the server and putting them into the single player game (as in games of old) would actually be difficult and take work, so they're not doing that.

You gave your word to something you're now not receiving, you no longer have any obligation because in the quid pro quo which you actually gave something for, you're not getting the promised something in return. It may not legally be fraud, since you agreed to the terms, but it's still fraud.

Abject stupidity. At least, they're not changing instruction sets again any time soon. They won't do that until they feel bytecode translation becomes a viable option for a desktop OS.

Soot, CO, CO2, and nitric oxides, besides the water vapor. Just like burning diesel fuel, except the proportions are different and the soot is finer.

Different people will always care about different things. That's why the official "ratings" board's job should be to make objective descriptions of pieces of media (games, movies, whatever) and provide them to different groups which produce their own ratings. Then you get your ratings from whoever, but the information they're basing their ratings on is always the same — or you'll want to know why.

I, personally, would prefer to avoid movies with a lot of vomiting in them, because that puts me off my popcorn. I think there's room for a lot of different ratings systems, but I see the need for standardization. This option provides for both.

Stop me if this is a bad idea, but can't you just load it before and after?

There's no reason he can't move on to bigger and better things from here. Perhaps this has whetted his appetite.

I guess this is the age of Oracle but we used to say "Moron Confused by Sun Equipment"

Can we do Novell and Cisco certs next?

Yes, yes they are.

Yes, yes they will, because once systemd becomes the default init system, init scripts will suffer.

The base Debian system should use the basic init system. If they want to offer the option to switch to another init, so be it, but making something new and not fully tested the default is daft and we all know it. Debian is the rock that many of us depend on whether we run Debian or a downstream distribution. It's been my go-to for ages specifically because of this stability. Debian stable is boring and I love it.

Riiiiight, the team that's been pushing for its default inclusion?

I have this argument with my lady periodically, she speaks spanish fluently, italian moderately, and greek a bit. She claims that English is "stupid" because there's no consistency to it. I agree, but claim that's also what makes it powerful. English is never afraid to adopt a loanword, probably bastardizing it in the process. There's a lesson about the English and their colonies there, I imagine, but let us continue. Since the words come from so many different sources, there are many different rulesets depending on whether the word is from greek, latin, french, german... But since we unabashedly copy any word we like, we have words for anything. And when we don't, the influence of context on a word (down to something so simple as the order in which we construct the sentence) lets us say anything anyway.

Of course, the language is still frustrating and confusing for a lot of people. Hence the importance of reading in mass quantities. Simply making it familiar while the brain is at its squishiest pays massive dividends, which is why I wish I'd been exposed to many languages at a young age. I got a little bit of spanish education very young, but then got packed off to a public school and... sigh.

That's not a problem. Who cares if a check happens every 30 seconds? Who cares if it's done by a script? The system is designed to do stuff like let a script step every 30 seconds. The system is also designed with cheap process creation in mind; the time to fork a process is comparable to the time necessary to create a thread.

Well, in theory to me anyway, it would make sense to use a runlevel for sleep. This isn't what is normally done, but there's really no reason why you couldn't do that with init, and I think that might well make more sense. Any services which needed to stop themselves could do so, the network could be reconfigured on resume, et cetera. All without any ugly hacks. We would still run a bunch of scripts, but shell scripting and cheap process creation are central features of the Unix environment. Shell scripting is not a hack. Unix was invented for single-digit-MHz computers, and we can afford to toss off a few shells.

And yet, you have not addressed the claim that overprovisioning affects the need to use the TRIM command.

There's nothing wrong with run levels. Dependencies aren't handled through run levels alone, they're also handled through start order. But the proper answer is to add something to /etc/default/package or directly to the init script to handle dependency checking, it's actually really simple.