A push gone wrong in the name of what, exactly? - <AUTHOR> https://rachelbythebay.com/w/2019/10/25/enabler/ <comment><USER2> Too many details missing here to make any sort of conclusions. Yeah, of course bugs aren't supposed to make it to production. But they do. Is it easier to roll back than it is to roll forward? Usually it's not. How far along are things before you recognize what's happening? How critical is the service?

You can't draw life lessons from some vague description of "something" that happened to "someone". Continuing the rollout could very well have been the best option. Or not. Who knows.

<comment><USER3> > Is it easier to roll back than it is to roll forward? Usually it's not.

If downtime has consequences then you have every incentive to make rollbacks happen at the touch of a button. From personal experience I know that plenty of teams simply are not at that point for many reasons.

If rollbacks are "hard" in any way for you, then you should know the known consequences of difficult rollbacks—they incentivize you to push forward even when the new release is kind of broken.

For example, let's say that your team doesn't test rollbacks and doesn't have procedures in place. You know, in the corner of your mind, that a version rollout could potentially take your service completely down for days while people hunt down the bug or figure out how to do rollbacks on the fly. This is a predictable scenario to end up in, so at some point I recommend addressing it, or justifying why you don't.

> Continuing the rollout could very well have been the best option. Or not. > Who knows.

Rollback should be the default response in the face of uncertainty when you might have a bad rollout. Ideally. It should be the safe, one-button-press reset back to the way things were before.

Again, I know that's often not the case. Schema changes are the biggest sticking point, usually. I often see schema changes in two phases—first you update the schema, and then later you roll out functionality which uses the new schema, in a separate rollout. This is tricky, but most updates are not schema changes.

Teams generally learn these things as object lessons (as in "we had downtime, wrote a postmortem, and it won't happen again") but that's not the way things need to be. As the team evolves and the product matures, the release tooling gets better. You read articles like this and you can make the tooling better without the object lesson. No one-size-fits-all solution, obviously, but… painless, one-button rollbacks are one-size-fits-most for sure!

Someday, someone writes an integration test that sets up a new and old version and makes them talk to each other, checking that they both work correctly.

Another day, somebody writes an integration test that does a rollout from the previous version, followed by a rollback.

And someone else adds more monitoring signals so if they see service failures above some threshold it automatically rolls back.

These are all evolutionary steps. Yes, they don't apply to all services. But—most of the services I run are somehow making money for the company, or people depend on them for critical pieces of functionality related to the company's bottom line.

<comment> bloody-crow > If downtime has consequences then you have every incentive to make rollbacks > happen at the touch of a button.

Not all rollbacks are the same. Even in a theoretical scenario where you can roll back the code to a previous version with a push of a button, it's not always possible due to many factors.

Sometimes new code creates and persists state that the old code can't handle and rolling back would just make the old version blow up because of it. Sometimes clients can't talk to the old code after talking to new code and expecting new protocol.

The point is, there's a lot of factors that could make one or another remediation strategy more or less viable, and sometimes rolling forward is the best way to proceed.

The article tries to advocate that rolling back is ALWAYS the correct thing to do, which is demonstrably not true for certain circumstances.

<comment><USER4> Or sometimes rolling back has political consequences (rolling back could be construed as failure and an exec somewhere up the chain gets pissed off).

<comment><USER5> I get what you're saying, but by the time you are playing political games with your software you've already lost the technical battle.

</comment></comment></comment></comment></comment><comment><USER6> I'm not sure I agree with this viewpoint. Assuming nothing critical lived on the service, and the worst side effect of the deploy was the client failing once and reconnecting, I'm not sure there's anything wrong with just restarting the world.

Obviously if you know in advance you should not even start, but if you notice after you are halfway done? Meh, chances are that a rollback would take as long as finishing the push, and either way the service disruption continues until it's finished.

<comment><USER7> When I hear "It's one of those things that talks to other instances of itself" I think of a redundant, high-availability database.

Assuming every machine sends data to all its peers regularly, if I have a cluster of 10 A machines and upgrade 1 machine to B, and the A machines crash, that means I lose 90% of my capacity - likely making the sole survivor get overwhelmed too.

"Outages are OK, clients can always reconnect or try again later" isn't the usual standard HA databases are operated to :D

<comment><USER6> At that point the A machines are dead though. There is no point in restarting them as A when you can also restart them as B, so I assume they don't all die in one go.

But I guess we just have too little information to make a really informed decision about what you should do.

<comment><USER3> > There is no point in restarting them as A when you can also restart them as > B, so I assume they don't all die in one go.

A is "baked in", so it should be the default.

There are simply too many classes of bugs which take time to manifest. Memory leaks, cache staleness, etc. So, for very good reasons, you consider version A preferable to version B.

</comment></comment></comment></comment><comment> joatmon-snoo ITT: people who don't do incremental rollouts or run reliable software stacks.

Sure, there are scenarios where you can justify rolling forward when you're spraying packets of death everywhere. None of those scenarios are the default - the default is roll back. (Imagine if there was some latent bug in the new release corrupting data in transit that you didn't notice until 100%, and you're not sure where it is, just that it's happening - now you literally can't roll back, because your current release will hose the previous one. At this point all you can do is go ¯\\_(ツ)_/¯.)

Also, the title of the post screams pretty loudly to me that the people making the call to push the backwards-incompatible release didn't seriously think through the implications of their decision.

</comment><comment><USER8> Working in a much less formal environment, I still religiously abide by a backward compatible concept whereby new code can require new conditions (e.g. schema changes) but those new conditions must be invisible/transparent to old code.

It's generally very risky to put your state of world into a place where the old code can't even look at it. Because rollouts and fallbacks become much harder to orchestrate. Mostly it provides the property where you only need to worry about writing environmental _upgrades_ and never _downgrades_ even if you sometimes fall back to older builds.

However the story in TFA is a bit different. What we have is an incompatibility between two versions running side-by-side. Nothing wrong with Version A or Version B per say, but just that you cannot roll out B progressively. Obviously the only fix is to immediately get your environment homogenized in A or B, and maybe there is actually a valid decision / risk analysis to go one way or another. For example, if you _don't_ respect the backward compatibility edict outlined above, it could be tricky to downgrade your B instances back to A depending on what state changes in the data B may have already made.

But the real problem is actually one level deeper. The fact that B got to the point of being rolled out with a catastrophic incompatibility with A means that DEV is fundamentally not testing for the ability to do a progressive rollout before they actually start doing one. The new B code was never actually tested in a heterogenous environment with A, meaning these rollouts must have been happening on blind faith alone.

</comment><comment> th-th-throwaway People are saying there isn't enough info but I think the author definitely made the right analysis here.

The purpose of partial rollouts is to observe if there are bugs. The unusual case here is that version B's bug is forgetting backward compatibility, causing it to rapidly take down version A too. This means you can't _simply_ rollback B as usual. After you rollback you still need to fix broken A instances. It's a lot of work but it would be the right thing to do.

Instead, they went all in on version B to avoid the bug they _just_ introduced. This is completely reckless. You're skipping your usual process so you never get a chance to observe for other bugs in B. You should actually expect B to have even more bugs in it given you know it already has one major production breaking bug.

Going all in on a version that you're not confident in just to fix the one bug you know about is stupid.

<comment><USER9> With the info given, it's entirely possible that the bug was actually in version A. Perhaps sending it a payload that is perfectly acceptable by the spec of how the API should work caused A to crash.

In that world, "fixing" B could involve sending invalid or unintended data to work around the problem in A, or patching A before rolling out B (which, when you're at the point of rolling out A.2, you may as well just roll out B)

</comment></comment><comment><USER10> There aren't enough details... I feel like the author needed to at least make a token effort to support the level of conviction she has that the developers in question are so terribly wrong.

It sounds like A was buggy (it dies when it receives a particular sort of request that it doesn't understand).

Maybe the devs knew about the bug in A? Maybe they decided it was better to make version B work as intended rather than try to throw in a one time hack to be backwards compatible with a broken version that was going to be a thing of the past in... How long does deployment take? Is it even long enough to matter? Maybe the most efficient solution was to allow some of the instances to die during deployment? What kind of application is it? Possibly a few failed requests while you wait for B to fully deploy isn't a big deal. Maybe the client auto-retries quickly enough that the dropped connection is negligible. Maybe there isn't a client at all.

The possibilities are pretty much endless given what we know.

<comment><USER11> Or perhaps it's just a short opinion blog post and shouldn't be overanalyzed.

<comment><USER12> If that couple sentences of analysis (not counting the guesses of context) is too much then maybe it's not a great post to submit to HN.

</comment></comment></comment><comment><USER13> Knowing the code changes well and making the decision to push on or revert back cant be second guessed by arm chair observers.

And of course it shouldnt happen in the first place but hey shit does happen. No one has ever managed to figure that out, and testing isnt a silver bullet.

<comment><USER3> It absolutely can be second-guessed, because this is a very common scenario and there is a consensus about the default way to deal with it—roll back first, ask questions later. It's easier to fix bugs while production services are not on fire.

If you are seeing failures and want to roll forward, you should be able to clearly articulate why this is better than rolling back, and what makes this particular scenario different.

Otherwise, I'm going to be on the side of the armchair observers calling for rollbacks.

<comment><USER14> "roll back first, ask questions later"

Better yet: build code and processes appropriate for long-lived massively distributed systems that will be incrementally upgraded over time. If the system is architected right, it will never get into a state where a rollback recovery becomes necessary. This is why we have Content Negotiation. This is why we have Erlang. This is not a new challenge by _decades_ , and there is a huge body of expert knowledge and tools upon which to draw when implementing such systems, so any such complete catastrophic _basic_ failures now are entirely down to PEBKAC, and remedied by a swift clue-by-four with a pink slip nailed to the end.

There is a very simple principle underpinning distributed communication: servers should _never_ make assumptions about who their clients are and what they need. Talk to the client, find out what format(s) it's willing/able to accept, and serve it the best match. A client should _never_ need to know, nor care, if it's talking to a version A server or a version B server: if the client says "I only understand version A data" then it's the server's job to serve up data in that exact format, not to pique and whine about how old and out of date the client is, push it version B data instead, and then blame the client for choking on it.

Indolent developers who approach IPC the same as local messaging and then blame everything but themselves when it barfs all over the place are the absolute bane of this industry, and this shit is entirely on them. And shame on the equally inept management culture that continues to let such incompetent amateurs get away with it.

<comment><USER3> You're asking too much.

There will be bad rollouts. I know of no set of practices which prevent bad rollouts. You talk about "indolent web developers", well, that's not productive and pointing fingers doesn't make your software work. Your software will, in spite of your best practices, in spite of hiring the best people, in spite of experience, sometimes fall over.

Yes, it will sometimes segfault.

<comment><USER14> My software shits itself all the time. What matters is that it does so _safely_. And when it doesn't, I can tell you why, because I know what corners have been cut and why, and I'm not afraid to accept and acknowledge my responsibilities in such fuckups.

And yeah, I count on the fingers of one hand the number of web developers I've dealt with over the last decade who I'd be willing to cross the road to piss on were they on fire, and still have fingers to spare. They're just the worst of the worst.

There was NO excuse for the failure described in the article. There was NO excuse for the described response to that failure. Yet such base incompetence and gross irresponsibility is not only systemic but entrenched, rationalized, and embraced in this industry. With responses like yours, it's not hard to tell why. Buncha _Children_.

<comment><USER3> > There was NO excuse for the failure described in the article.

In this case, right. In general, stuff happens. There's a tradeoff between reliability and effort. The correct reliability target is not 100%, because you can't get 100% anyway, and as you approach 100% reliability the cost increases without bound.

I'm not sure what the rest of your comment is about besides taking a big shit on web developers and talking about how awful they are.

There is a precious small percentage of developers who are really good at making reliable systems and they have the burden / responsibility of spreading their knowledge. They work with the other actual developers you hire, those beautiful imperfect developers who cut corners, test in production, and don't write tests.

You make changes to your culture and your practices. You build monitoring and rollout automation. You increase test coverage.

If you just call people children you're going to be there, on the sidelines, watching other people build real products. You don't teach people by making fun of them.

</comment></comment></comment></comment></comment></comment><comment><USER15> This article fails to mention the consequences of the rush to push version B, rather than rollback to resolve. As far as I can tell the result met the needs of the business?

<comment><USER16> If it did that's pure luck. It could have also had another bug. Rolling back keeps your service up. Pushing forward faster maybe gets your service back up, or maybe breaks it some other way.

When dealing with a complex system, roll back first, then figure out why it broke and how to fix it for the next attempt.

<comment><USER15> I should clarify - I don't disagree that rolling back and fixing the bug (or in a continuous delivery world - fixing forward as a priority) is the right thing to do. I'm just saying the article leaves out a lot of details and fails to articulate the reasons why the road taken was bad.

</comment></comment></comment><comment><USER17> From experience with an app that doesn't auto-update, I know that the only thing that gets people to upgrade is a critical bug that affects them.

People generally keep using old versions of software for years. 90% of users don't care about new features or performance improvements or bug fixes that don't directly affect them.

So I understand what they did. If they indeed introduced a version C that had a workaround to avoid crashing A, then they would have never gotten rid of A. No matter how hard they pushed C, some people would just continue to use A.

But if A starts crashing, and there's an update available that fixes the issue, that's a really good motivator to get people to upgrade.

Sure, it'll suck for everyone for a short while, but it'll soon be over once everyone has upgraded.

And, as a dev, I also know that crashes are not the most serious kinds of bugs. They are usually easy to diagnose, and people realise that something is wrong right away -- much better than a bug that silently corrupts data, or a bug that causes subtly incorrect behavior.

<comment><USER18> If your goal is to get rid of A by any means necessary, make the business decision to turn off A at some point.

Not having the backbone to make that decision and allowing the call to forced at some arbitrary time by a bug and concluding the bug was a good thing (or at least had a silver lining) because it allowed the org to move away from A suggests a possible leadership decisiveness problem to me.

<comment><USER19> There is no organization of more than 500 employees that can take decisions like that.

Developers of one service simply don't have the power to force other developer in another part of the organization to do anything. That's assuming they're even aware of the existence of that service and who is supposed to own it.

<comment><USER20> counterexample:

the team I'm working on has successfully turned off ~10 systems with/without replacements, and got all of our clients within a much larger than 500 person org to migrate fully.

<comment><USER19> I am not saying it's impossible. I'm doing that with hundreds of systems covering 5000+ developers/clients.

Fact is, it's a nightmware to handle. It just takes one client who can't or won't upgrade and it's blocked forever.

</comment></comment></comment></comment></comment><comment><USER21> If this would be our situation, it would be a firmware update for our smart outlets in the field.

You definitely want to make sure that updates are backwards compatible. We use a mesh and once there was an incompatibility on the mesh protocol. You want to make sure this will never cause trouble. We decided to use another channel all together.

Our next update will update the bootloader and radio stack as well. Scary! This is an update that uses multiple intermediate bootloaders so we fall back to a working system at each step. We definitely do not want to have bricked devices out there. [https://github.com/naveenspace7/bluenet- bootloader/blob/inte...](https://github.com/naveenspace7/bluenet- bootloader/blob/intermediate-bl-2/intermediate/docs/flowchart.pdf)

We almost didn't find a bug nevertheless. In our older devices there were some programmed with a binary generated by objcopy without the --gap-fill 0xFF flag. It lead to an hardfault in initialization of the new file system. Brrr. [https://github.com/crownstone/bluenet/issues/73](https://github.com/crownstone/bluenet/issues/73)

</comment><comment><USER22> > When you're already in a hole, QUIT DIGGING.

Except this time they did seem to dig their way out of the hole :D

</comment><comment><USER23> I generally like rachels posts, but I don't know what the hell she's talking about here.

<comment><USER24> The updated version of the program, when pushed to servers, crashed the older version of the program on other servers which had yet to be updated. Rather than rolling back to diagnose and understand the cause, they charged on updating all the servers.

<comment><USER25> That part I understand. What wasn't elaborated on is what problems that caused and why it was a bad idea.

</comment></comment></comment><comment><USER26> It's not clear whether their strategy was a success or a failure. If it succeeded, the old bromides of "don't rush pushes" doesn't actually apply. I mean it worked didn't it? The reality of production software is that it's always pushed in somewhat of a rush, to meet a myriad of internal and external deadlines.

I would counter the "don't rush" bromide with "anything worth doing is worth doing adequately."

</comment><comment><USER27> It sounds like the team doubled down on the deployment without actually informing their managers or anyone at all.

</comment><comment><USER28> An interesting case of rollback vs rollforward from bitcoin.

[https://github.com/bitcoin/bips/blob/master/bip-0050.mediawi...](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki)

In that case they decided to rollback.

</comment><comment><USER29> I myself was in such a situation. Though after a heated argument we decided to revert to previous version (A) and not push forward.

Of course well-thought release policy will help immensely (how to test, when to release, staged rollouts, etc...)

</comment><comment><USER30> It seems odd to me that they do not version their exchange protocols, file formats, APIs etc. And then check if both participants have compatible versions when interacting..

</comment><comment><USER31> usually you want to a release to be all the way deployed or all the way rolled back not sitting in some half state.

because it gets really hard to reason about the state of mutable resources like databases and storage that is being written to by two different versions of the application simultaneously.

in this situation pushing on with the deploy or rolling it all back are valid options.

however everyone knows rollback are always more difficult than deploys

</comment><comment><USER32> I'd say this a good resiliency test. If anything, they should do this on purpose from time to time.

</comment><comment><USER33> Mistakes will happen, especially when your mantra is release early and release often.

<comment><USER19> Seems like a successful deployment as per "move fast and break things"

</comment></comment><comment><USER34> I would probably call that a feature...

<comment><USER35> The purpose of slow rollouts is to catch bugs before they affect everyone. We already have evidence this is buggy software, so slow rollouts are even more important.

And even if there aren't any other bugs, this scenario must have caused a lot of stress for the people in charge of the rollout.

</comment></comment><comment><USER36> Death by push

</comment><comment><USER37> It always amuses me how the HN collective tears apart whatever rachelbythebay writes. Maybe they should change their online identity to rossbythebay.

The tale they've shared should be obvious: When a deploy is causing problems, stop. And here are some generic techniques that could have been used to avoid ending up in a situation where one might choose to plow ahead instead of rolling back.

How is this controversial to anyone? This is Formalized Change Process 101.

<comment><USER38> I think that any post that is technical and related to software* go through some process of being tear apart collectively by HN.

I have the opposite impression that HN collectively appreciate Rachel posts very much, judging by the sheer number of her blog's posts that are upvoted to front page recurrently. Not many personal blogs reach that number of upvotes in HN.

*Maybe even all kind of posts, but the ones that are technical and about software are just the sweet spot because HN is full of software engineers.

</comment></comment><comment><USER39> Without some juicy details of customers being screwed over, or name-and- shaming evil cackling developers, this story is a bit mom-and-apple-pie.

</comment><comment><USER40> > What could have happened instead? Many things.

Yes, yes, many things, certainly. Obviously, fix-forward is very bad because of these many things.

As a highly compensated software engineer, of course _I_ know what these things are, but, just checking, what would _you_ say they are?

<comment><USER41> You misread that "many things", which refers to hypothetical actions the team could have taken (and which the post immediately describes), not hypothetical outcomes of their actual actions.

</comment></comment><comment><USER42> Since rachelbythebay didn't tell us what the result of these broken sessions was, I assume it wasn't critical. Or at least that's the attitude of the HN crowd complaining about a lack of details. Developers only pay attention to these kinds of stories when the tale involves someone getting fired or money being lost.

</comment><comment><USER43> I guess Rachel had a bad day at work? Rachel's writing is normally top-notch, but this is whiny, vague, and frankly annoying.</comment>


Lebanon's Crippling Economic Crisis - <AUTHOR> https://www.nbcnews.com/news/world/we-re-road-collapse-inside-lebanon-s-crippling-economic-crisis-n1234005 <comment><USER2> There may be an opportunity for Bitcoin to alleviate some of the inflation concerns and monetary controls the Lebanese face these days.

Bitcoin has been fairly stable in terms of exchange rate, relatively speaking from it's early days. Lebanon has high cellphone penetration rate with an educated population. Adoption may be necessary</comment>


PostmarketOS in 2020-02 - <AUTHOR> https://postmarketos.org/blog/2020/02/17/postmarketos-in-2020-02/ <comment><USER2> This is a great project. I've put it on my old tablet and it's surprisingly quick. Sadly, it's an old ARMv7 chip so there's not a lot of Alpine packages compiled for it and the graphics aren't hardware accelerated; would be nice to run Firefox...

I wish manufacturers would upstream their changes but that's probably never going to happen. Now my tablet is running Linux 3.0 so it won't even boot systemd let alone anything that requires GPU acceleration.

I also noticed the weird partition schema Android uses (6 different partitions larger than 100MB on my tablet) doesn't play well with normal operating systems. I don't know how many partitions are required to get the system booting so I can't really remove any.

That all being said, the devices running mainline are doing great on pmOS. I admire the people who build on the open source GPU code, I'd have no idea where to even start working on something like that.

I hope this project will be as successful as some of the custom ROM communities in a few years time when the project has had time to smoothen things out.

</comment><comment><USER3> > @afontain has impressive results to show regarding Anbox: the Android > compatibility layer, that was never tested much outside of Ubuntu, is for > the first time running on postmarketOS / Alpine Linux!

It's great to see this. With Anbox, Linux phones will gain access to a large selection of Android apps, which would make it easier for people to make the switch from Android/iOS.

<comment><USER4> Just a rant - I know why we need it, but I wish mobile OSes like Sailfish OS or postmarketOS didn't require crap like "Android compatibility layers", especially when we are turning to them to get away from Android in the first place!

<comment><AUTHOR> If it makes you feel better: this will always be optional, and we strongly advise against using Android apps on postmarketOS unless there is no alternative for one's use case.

With that being said, I find this an incredible technical achievement by Antoine Fontaine. I've tried to run it on postmarketOS myself, and ran into all kinds of problems with LXC and what not (since Ubuntu used another version than Alpine, at least at that point in time). All I got was this loading screen: [https://postmarketos.org/static/img/2018-06/anbox- starting.j...](https://postmarketos.org/static/img/2018-06/anbox-starting.jpg)

</comment></comment></comment><comment><AUTHOR> Why does Hacker News auto-capitalize the first letter? It's "postmarketOS" with a lowercase p, just like blink-182.

</comment><comment><USER5> this is really impressive.</comment>


Delayed Sleep Phase Syndrome - <AUTHOR> http://en.wikipedia.org/wiki/Delayed_sleep_phase_syndrome

<comment><USER2> I find disorders that are defined relative to the "norm" are weird. Also it being so vague makes it interesting.

I find that I fall asleep every night around 1:30-2. Is that sufficiently deviating from the "norm" that I have this DSPS? Or am I just a night owl?</comment>


Simple kernel attack: Eat 100% CPU, works under guest, no way to protect - <AUTHOR> http://lkml.org/lkml/2010/11/25/8 <comment><USER2> Has anybody launched this in a VM under Xen and/or EC2 to see if AWS is vulnerable? If this can mangle the Dom0 over a paravirt DomU, this would be awfully interesting.

/me off to test...

update: Would be nastier if it forked cpux2 times or something at startup. My test server is running fine for 15 minutes with it active. A bit slow, but still responsive and accepting new SSH connections. Server is Centos 5.5 with 2.6.18-194.26.1.el5

Proc net unix seems stable as below, maybe slowly growing now.

[root@xenpig net]# cat /proc/net/unix | wc -l

153406

I have kill -9 that process several times though, and it ain't dying, so that is an issue.

<comment><USER3> You can cap the amount of CPU utilization for VMs, so I don't think you could bring the server to a crawl, only the VM.

</comment></comment><comment><USER4> Apparently someone used this on the lkml.org web server.

</comment><comment><USER5> I would call it an attack if you can inject it into someone's else machine build it and run it as guest (or upload it as a binary and run it).

Writing a program which eats all available CPU and other resources it is not a big deal, is it?

<comment><USER6> There are other ways of gaining remote access. This is a pretty well- constructed local DoS attack you can run (without root access, I think!).

Attacks can take many forms, most new attacks are single components that one would combine to perform a real-world attack.

Here, you would combine some method of gaining remote access (maybe a webserver hole you can drop a shell with) with this and get an excellent remote DoS attack.

<comment><USER7> One really easy way of getting remote access is to ask for it. Local exploits and DoS attacks are important not just because other exploits may let you run code remotely: there are many situations in which computers are not single- user devices. At my university anyone can remotely log in to any of the machines used as lab workstations and there are numerous shared fileservers you can log in to as well. People also still routinely purchase "shell accounts" on shared hosting providers.

</comment></comment></comment><comment><USER8> The thread is also viewable here: [http://lkml.indiana.edu/hypermail/linux/kernel/1011.3/00630....](http://lkml.indiana.edu/hypermail/linux/kernel/1011.3/00630.html)

<comment><USER9> You linked to a thread that is not the original one.

The problem was originally reported 2 days earlier by Vegard Nossum: <http://thread.gmane.org/gmane.linux.kernel/1067149>

<comment><USER10> The problem reported there is slightly different; the program linked in the OP operates recursively, building a larger and larger graph of 'in flight' FDs, while the earlier report simply allocates a bunch of pairs and sends FDs to them. The earlier report is apparently fixable by triggering the GC in this case (as mentioned in the lkml followup), but that fix does _not_ address the exploit in the OP.

</comment></comment></comment><comment><USER11> By installing Flash player?

<comment><USER12> You made me laugh, but HN is no place for humor.

<comment> rw- Yeah.

</comment></comment></comment><comment><USER13> Not informed enough to say if the code is as interesting as the title implies. Hope someone comments to enlighten me, shall upvote if so!

<comment><USER14> You can send a file descriptor over a socket between two processes. (Google "SCM_RIGHTS").

This is one place in the kernel where it employs a garbage collector (hey, they need to start somewhere ...). The reason is that there's an uncomfortable part about this API: the reader doesn't necessarily have to pick up the file descriptor it is sent. If the sender closes the fd, the kernel needs to detect that the reader didn't pick up the fd and deallocate the underlying file resource. Hence GC needed.

This code makes sure that many such fds are "in flight" over the socketpair, and by closing the socket instead of reading from it, ensures they are leaked. The GC doesn't get invoked under this particular set of circumstances so eventually you consume all system file resources. (I think even ulimit doesn't stop this).

Solution as in the follow up message is to run the GC in an extra place.

<comment><USER15> > and by closing the socket instead of reading from it, ensures they are > leaked.

It does:

        create socketpair N+1
        send socketpair N over socketpair N+1
        close socketpair N
        repeat

So the only ones that are ever closed are the local copy of something that was sent over another socketpair. So all of the fd's are reachable, assuming that an in-flight fd is (like a received fd) a copy of the original fd rather than a reference to it.

<comment><USER8> Seems like in-flight fds should still count against the sending process's open file limit. (So that all fds are counted against _some_ processes open file limit).

</comment></comment></comment></comment><comment><USER16> Wait, is this run locally because I could just do :(){:|:&}; :& which is pretty effective.

<comment><USER17> Am I the only one who initially thought this was a sequence of emoticons?

<comment><USER18> I'm not sure why : has been chosen as the canonical fork bomb function name, but it's more readable with something like

resurse() { recurse | recurse &}; recurse

<comment><USER19> In this example, the poor readability is a feature. Nevertheless the ":" character is bash inner function, which tells the shell to do nothing (except the arguments expansion), like pass in python. This means that you can redefine it and use it to confuse others. Most of other special characters are not functions so you are not able to redefine them that easily.

</comment></comment></comment></comment><comment><USER20> What happens if you renice the process so everything else takes priority?

<comment><USER21> Probably nothing, since it happens in the kernel, not in userspace.

</comment></comment><comment><USER22> Isn't it possible to mitigate the problem in limiting the number of sockets an user process may open?

</comment><comment><USER23> Despite knowing it was aimed at Linux, which I don't use, I still had to try it out to settle my curiosity: it's completely harmless on OpenBSD and Mac OS X; it does not hang either of these OS' kernels, and does not eat FDs.

<comment><USER24> BSD doesn't support SOCK_SEQPACKET on unix domain sockets. The app exits early.

</comment></comment><comment> rw- Shame on you, Марк Коренберг! Releasing ready-to-use exploits harms everybody.

<comment><USER25> It also let's people prepare for it and create solutions. It's not a bad policy, and not releasing the exploit can in many cases be more harmful.

<comment><USER26> Exactly. Disclosure is best.</comment></comment></comment>


Alternatives to using Google - <AUTHOR> http://www.bbc.co.uk/news/technology-23318889

<comment><USER2> Coincidence that the link is down?

</comment><comment><USER3> Wow, Yahoo not listed there.. burn!

<comment><USER2> It's not REALLY an alternative, as it uses Bing's technology</comment></comment>


This Wearable Device Turns Your Skin into a Touchscreen - <AUTHOR> http://naijafixer.com/science_tech/this-wearable-device-turns-your-skin-into-a-touchscreen/new/#new <comment><USER2> How do people use sites like this? The whole thing is a mess of pop us and meaningless extra information, and adds absolutely nothing to the original announcement (which incidentally is at [https://cicret.com/wordpress/](https://cicret.com/wordpress/) )

<comment><USER3> It's essentially spam, flag it and move on.

I'm not sure which is the original source, because the same text is in many places. Probably all of them just copied the press release.

[https://www.google.com.ar/search?q=We%E2%80%99ve+seen+futuri...](https://www.google.com.ar/search?q=We%E2%80%99ve+seen+futuristic+wearables+in+movies+like+Iron+Man%2C+where+Robert+Downey+Jr.+maneuvers+a+Google+Glass- look- alike+and+makes+a+touchscreen+appear+out+of+thin+air.+Now+there%E2%80%99s+a+company+that+is+bringing+that+touchscreen+even+closer%E2%80%A6+skin+close!+This+new+wearable+could+have+you+saying+good- bye+to+your+smartphones+for+good.&sourceid=ie7&rls=com.microsoft:en-US:IE- ContextMenu&ie=&oe=&gfe_rd=cr&ei=KPjwV7WsB4PX8ges7oSIDQ)</comment></comment>


Show HN: #LikeNoise: Make FB more expensive for advertisers targeting you - <AUTHOR> https://likenoise.com/ <comment><USER2> But this will no doubt be tied to that access token and so can trivially be separated from the "real" activity by Facebook. What you should be doing instead is have like a Chrome extension or Userscript that does the liking from the user's own browser, indistinguishable from the real activity.

<comment><AUTHOR> Very good point. How likely would people use this? [https://youtu.be/1nvYGi7-Lxo?t=36m41s](https://youtu.be/1nvYGi7-Lxo?t=36m41s) Interesting watch

</comment></comment><comment><USER3> I always make sure to "like" political opponents from across the aisle. I liked Donald J Trump, Hillary Clinton, Bernie Sanders...

But I only did that to see what they were saying, given primary sources are often better than the media. It doesn't mean I "like" them. Do all of Trump's twitter followers like him? I don't think so...

Really, it's the "likes" of more obscure pages that provide demographic signaling. I can infer a lot more about someone who likes a bike repair shop in Portland than I can about someone who likes yahoo.com. For that reason advertisers are unlikely to be targeting people who like a top-200 website like yahoo.com; the top 200 websites are _already_ noise. Someone liking one is meaningless.

</comment><comment><USER4> This will end up making facebook a more expensive place to advertise, but I doubt advertisers would stop given how much screen-time facebook gets per user per day. So really this is an overall benefit for FB, because people will spend more for the same amount of sales.

</comment><comment><USER5> Or... #deletefacebook

<comment><USER6> For better or for worse for quite a large portion of the world Facebook is the internet. The sentiment is admirable but I have a feeling the people able to #deletefacebook, are the ones in the least need to delete facebook.

<comment><USER5> Definitely for worse. Especially if there are any areas where that Facebook is being zero rated to continue that horrible narrative.</comment></comment></comment>


Airpush Wants to Destroy Android - <AUTHOR> http://joshuascholl.posterous.com/airpush-wants-to-destroy-android

<comment><USER2> Self policing is working fairly well so far. Any developer who uses AirPush is taking a huge gamble. Personally I will uninstall the app, report it as malicious malware, and write a scathing review of any app that uses AirPush. I hope others are doing the same. The problem is going to be what happens when the carriers pre-load applications using AirPush along with a locked boot loader to prevent you from rooting your phone to remove it. That's the point where you'll see an exodus from Android. I really don't think people will put up with it. The carriers will almost certainly try it because what do they have to lose? They will probably start up-selling ad/bloatware removal like Best Buy does with PCs.

<comment><USER3> How will you know which app is using AirPush? There is no way to know where a notification comes from in Android, and as the article explains, it's possible for developers to delay the notification for days.

</comment></comment><comment><USER4> I don't get why people would say Airpush would never exist on iOS. It already does. I have seen quite a few app that use push notifications for advertisements. Not just scammy apps, but popular well recieved apps like Boxcar that hide it by labelling it App Recommendations.

Push notifications' promise always included ads. It is just a matter of presenting them well. It is like nagware. The annoying ones will be punished, the effective ones will be rewarded.

<comment><AUTHOR> Except half of Boxcar's functionality is to provide advertising. That's a lot like saying "I don't know why people complain about the Huffington Post and all of their advertising when reputable sites like eBay are nothing but people trying to sell me stuff."

And let's not get ahead of ourselves with the whole "push notifications have always been ads" - push notifications have always been with providing the end user with desired information. That may well come to include advertising, but up until this point advertising in push notifications has been an outlier at best.

<comment><USER4> Outlier now, but a pretty unavoidable future. Telemarketers and spammers were outliers at one point.

</comment></comment></comment><comment><USER5> People went rabid went some apps started showing ads as notifications. They will continue to do so for any app that implements it. This is going to police itself initially, and I'm guessing Google will do something about eventually.</comment>


Michael Arrington Removed From PandoDaily's board - <AUTHOR> http://pandodaily.com/2012/04/09/investor-update/ <comment><USER2> If I wanted to hear about inside politics, I'd subscribe to pandodaily.

</comment><comment><USER3> Seriously; why does anyone care about this attention-seeking assclown?

</comment><comment><USER4> There's some fairly silly competition between tech blogs.

You can see from some of Sarah Lacy's tweets (<https://twitter.com/#!/sarahcuda/status/189224285204783104>) that PandoDaily and TechCrunch don't see eye to eye at all.

Arrington has recently been getting involved in TechCrunch again. (<http://techcrunch.com/2012/04/04/im-back/>)

I'd surmise that the folks at PandoDaily felt weird about him having his hand in two techblogs.

Seems pretty silly, especially considering that CrunchFund is invested in PandoDaily and not TechCrunch, but that's what I'd guess.

</comment><comment><USER5> Now the whole drama will rehash itself all over again :(

</comment><comment><USER6> Any idea on what caused it?

<comment><USER7> I don't, but two things have happened that I can see.

Michael Arrington posted on TechCrunch a week ago and is helping out with a new TechCrunch event: <http://techcrunch.com/2012/04/04/im-back/>

Today, it was announced that CrunchFund invested in rover.com: [http://www.geekwire.com/2012/crunchfund-madrona-bite- doggie-...](http://www.geekwire.com/2012/crunchfund-madrona-bite-doggie-care- service-rovercom/)

Not saying either of these things are connected to the split but there's clash potential in them, I guess.

<comment><USER8> How does his investment in rover.com have clash potential?

<comment><USER7> No _specific_ actions come to mind, but as has already been discussed with regards to investors, Pando and TC, investing in companies within your beat is tricky and open to all sorts of potential conflicts of interest, accidental or otherwise.

</comment></comment></comment></comment><comment><USER9> "We have nothing more to say about the move"

Not publicly, anyway. Which I commend. If it was anything but amicable, there's plenty other people willing to sling mud on that guy for them.

</comment><comment><USER10> Maybe b/c pando is a total bust and he doesn't need to be a part of it. Even the site design makes it hard to read. I figure if there's something ever good on there I can read it here.

</comment><comment><USER11> Arrington is a joke

TechCrunch is a joke

PandoDaily is a joke and has a hideous design.</comment>


Convert ASCII scribbles to SVG - <AUTHOR> https://github.com/ivanceras/svgbob <comment><USER2> Author here and I'm surprise to see this here. I haven't maintained this elm version. I've created a rust version[0] and it's practical usage incorporated into markdown[1]. A MacOS app can be downloaded [2]. Pay what you want so I can improve the app in the future.

[0] [https://github.com/ivanceras/svgbobrus](https://github.com/ivanceras/svgbobrus)

[1] [https://ivanceras.github.io/spongedown](https://ivanceras.github.io/spongedown)

[2] [https://sellfy.com/p/SsQS/](https://sellfy.com/p/SsQS/)

<comment><USER3> [https://ivanceras.github.io/spongedown/complex/Ascii_art.htm...](https://ivanceras.github.io/spongedown/complex/Ascii_art.html) errors out

        rustc 1.17.0 (56124baa9 2017-04-24)
        error: unknown start of token: `
         --> <anon>:8:1
          |
        8 | ```bob
          | ^

<comment><USER2> Oh, the playpen was a hack to just display the source code of the graph, but not for rust execution.

</comment></comment></comment><comment><USER4> If you wonder where ASCII scribbles come from, I use [http://asciiflow.com/](http://asciiflow.com/) all the time for READMEs.

<comment><USER5> Sorry for shameless plug, but there's also my [http://textik.com](http://textik.com), which is for more structured editing, and also written in Elm.

</comment></comment><comment><USER6> This is awesome! I'm trying to dig out early 90s warez/gamez nfo files to run through this thing!

</comment><comment><USER7> [https://ivanceras.github.io/svgbob/build/](https://ivanceras.github.io/svgbob/build/) is a working demo of the project, showcasing a good deal of the lines and features available.

</comment><comment><USER8> Don't know when I would use this, but that doesn't stop me from being very impressed.

</comment><comment><USER9> Nevermind the svg, what is used to generate those ASCII charts!?

<comment><USER2> There is a graphical app for linux called asciio. Allows you to draw ascii graphs</comment></comment>


Ask HN: What will you buy for black friday? - <AUTHOR> <comment><USER2> Nothing.

For me, black friday is a day to lay low and avoid all retail establishments to the greatest degree possible.

</comment><comment><USER3> I wasn't planning on buying anything on (or "for") black friday.

</comment><comment><USER4> I'd buy a laptop, but I'd probably get better value for my money by buying it used though eBay anyways, so there's no point in rushing.</comment>


Show HN: Kalk.io – a text-based calculator - <AUTHOR> http://kalk.io/ <comment><USER2> For a moment, I thought it as a fully functional calculator. However, I couldn't go beyond the basic math operations on the predefined values. It would be awesome, if you could provide some guideline or a short statement on the basic purpose of the system.</comment>


The new Director General of ESA wants to build a village on the Moon - <AUTHOR> http://www.bbc.com/future/story/20150712-should-we-build-a-village-on-the-moon

<comment><USER2> It's going to be strange looking up at the moon one day and seeing human made structures.</comment>


US Department of Homeland Security looking for (more than) a few good drones - <AUTHOR> http://www.networkworld.com/community/blog/us-department-homeland-security-looking-more-few-good-drones <comment><USER3> I know this is going to sound like hyperbole, and I apologize, but I believe that the networked computer is a bigger danger to mankind than nuclear weapons. We are completely destroying the innate quality that we've had as humans since we came out of the trees - anonymity and privacy.

I'm not saying technology is bad; I'm no Luddite. But we are entering places in our societal structures that we've never been before even in the strictest police states. Maybe it's grumpy old guy day again, but I do not feel that this is going to turn out well over the long run.

ADD: Of all the things I thought 20 years ago that I might be concerned about in the 2010s, "swarms of flying robots able to watch and record my every move" was not one of them. The future is not only stranger than you imagine; it is stranger than you _can_ imagine. And that's just robotic drone surveillance. There's a dozen other networked technology devices that are much more worrying.

<comment><USER4> We've always been social creatures and when we came out of the trees did we really have anonymity and privacy? Village life has been the norm for most of your history and I believe that anonymity and privacy aren't the norm in village life. Am I wrong?

It seems to me that only since mass urbanization has there been anonymity and privacy and we begin to revert back to the historical mean. Although at a much grander scale. Is it the scale that is the danger? In the past one could leave the village for another location (in theory) and get away from stigma. Maybe now it is much harder.

Of course now there is much more information and many more instances of instant fame. Perhaps the noise will be anonymize us except to the powers that be.

<comment><USER3> There's another thread that makes the same case: these things are not old.

As far as I know, we come from clan-like nomads, varying between a alpha-male- harem model with young males on the outskirts and a pair-bonding model with young males striking out on their own. That means that those in your clan have generally had a very close and intimate view of your activities -- and you of theirs. But also that 1) clans were by necessity small, and 2) you always had the ability to walk away. Village life gets a little more complicated, but there is a span of control issue at work: you simply can only be concerned with so many things at the same time. People who are not physically near you have privacy from your oversight. In fact, much of human social behavior is about the trading of information about other people, their thoughts and behaviors. The trust engendered forms alliances and creates a communal atmosphere.

The state of nature is that I can choose to talk away from any group of humans. Once I am several hundred meters away, whatever I am doing is anonymous and private. I can choose to share something with one or a few special friends. I can choose not to share something with somebody who has offended me. And so on.

But now it's possible to be concerned with millions of things at the same time. Computers can watch millions very closely. You can't walk away from a group of humans and have privacy and anonymity. The system will track you. Your call phone, for instance, has capabilities that make it more or less something akin to a cross between a surveillance device and a wildlife tracking tag. The natural limits that draconian states have over their people are melting away. That's completely new.

So yes, we've always been social creatures, but society has been defined by the physical and natural limits on cognition and communication. What we're turning into is not just a more social version of man. It's something completely different. As the other commenter pointed out, it's really more savage than social.

<comment><USER4> I understood your first comment to be in relation to governmental spying and neighbors (the whole world) spying. I agree the former is a serious problem and will likely have radical consequences but the latter I think won't be a problem. There is too much noise for you and I to keep on top of all the latest rumors and whatnot. I can retain anonymity and privacy from the average person but not from the government or corporations.

</comment></comment></comment></comment><comment><USER5> That's federal level. State and local police are already shopping and some are already working with local military bases to use theirs.

All warrantless, no oversight. The mission creep is going to be scary.

They'll have to find a way to justify their incredible expense for the 99% of time they would be idle, so imagine the equal to speeding ticket quotas that will emerge.

</comment><comment><USER6> I was at a law enforcement show this week and drones were the big new thing. Most were either quadcopters with GoPros while others looked like mini helicopters with PTZ cameras strapped to them.

Better funded departments are starting to test them out, but the demand from local police still isn't quite there. They require obtaining a special FAA license and lots of training, which makes the sales cycles on drones long and unattractive to vendors selling one at a time to local PDs.

Still though, their pitch is: "A helicopter flight cost is $450/hr. A drone is $14." Saving PDs the cost of flying a drone to/over an accident scene is more the draw than snooping into buildings.

</comment><comment><USER7> There are many perfectly good uses for drones, but we all know the regulatory oversight will be completely negligent and insufficient.

It's in light of that that I have to wonder whether drones should just be vilified altogther.

<comment><USER8> _I have to wonder whether drones should just be vilified altogther._

Good question. I can see uses for drones. I know guys who will personally benefit from automation like this.

I say take a hard stand against them: no drones, period.

Because 'give them an inch they'll take a mile' is why.

</comment></comment><comment><USER9> Excellent podcast on the ethics of automated systems deployed by military, LEOs, etc. featuring Noel Sharkey:

<http://ieet.org/index.php/IEET/print/6600>

From the teaser:

"Noel Sharkey is Professor of Artificial Intelligence and Robotics, and Professor of Public Engagement at the University of Sheffield. He holds a Doctorate in Experimental Psychology and a Doctorate of Science, and lectures extensively across academic disciplines, including engineering, philosophy, psychology, cognitive science, linguistics, artificial intelligence and computer science. In addition to having published well over a hundred academic articles and books, Sharkey has worked closely with policy makers and the military to create awareness about the limitations of AI and the dangers of automated warfare."

</comment><comment><USER10> I was watching a documentary the other day about border smuggling - <USER2> it's only a matter of time before drones are used for that, in which case what hope has domestic law enforcement got if they don't go down the same path.

<comment><USER11> Smugglers have used submarines. Law enforcement has already "no hope", and that is entirely by design. If you want LE and criminals to be equal then you end up in a country run by criminals.

<comment><USER12> No, there is more than the technical advantage held by police which factors into this. There is also the extent to which the mass of people tend to believe whether it is better to do things in a law-abiding manner or whether legal authority is completely disrespectable and not worth obeying.

</comment></comment></comment><comment><USER13> Speaking of drones:

[http://www.theage.com.au/technology/technology-news/drone- fi...](http://www.theage.com.au/technology/technology-news/drone-finds-dummy- bushwalker-in-worldfirst-20121005-273lv.html)

</comment><comment><USER14> Obligatory book recommendation: [http://www.amazon.de/Kill-Decision-Daniel- Suarez/dp/05259526...](http://www.amazon.de/Kill-Decision-Daniel- Suarez/dp/0525952616)

</comment><comment><USER15> The scariest thing about drones is that if both sides have drones, the winning strategy would seem to be in having millions of cheap drones directed by the sort of algorithms currently used in high frequency trading. Putting humans in the decision making loop for all of those just slows them down and vastly increases the expense and manpower requirements.

<comment><USER16> There's very, very little work going on with AI in drones. We're not there yet. We're still working on getting the sensors right and dealing with datalinks. The vast majority are remotely piloted, some are remotely directed (point and click to location, the drone maneuvers to get there), all are controlled by humans.

This "robot drone aircraft freakout" sounds as silly to me as an aerospace engineer as worries about malicious hackers shutting down the US power grid sound to you.

<comment><USER17> I'm fairly knowledgeable about computer security and slightly to somewhat about power distribution, and for a well-resourced hacker ($10-50mm), shutting down the US power grid actually wouldn't be terribly difficult.

Leaving aside any attacks on the control system, the actual physical infrastructure is quite vulnerable. It operates close to breakdown on many days anyway, so it would just take the loss of some critical lines and maybe substations to cause (if lucky) widespread controlled blackouts and load shedding, or if unlucky, uncontrolled massive blackouts.

Since 9/11 they've fortified certain pieces (in the late 1990s, a 3 guys with crowbars and pistols could have broken into major grid operations centers and shut them down), but a lot of it is still fairly vulnerable.

<comment><USER18> The UK experienced chaos when a small group of farmers and lorry drivers blocked oil refineries.

([http://en.wikipedia.org/wiki/Fuel_protests_in_the_United_Kin...](http://en.wikipedia.org/wiki/Fuel_protests_in_the_United_Kingdom))

Some aspects of security are purely reactive (One man with a shoe bomb? All passengers now remove their shoes. One man with an underwear bomb? All passengers now go through millimetre wave scanners) and so this vulnerability has been fixed. Other protests were much less successful.

</comment></comment></comment></comment><comment><USER15> UK already has these for police. The Merseyside Police managed to ditch one of theirs into a lake. <http://www.bbc.co.uk/news/uk-england-merseyside-15520279>

<comment><USER19> That does it. I'm defending my airspace with anti-drone drones (until they are illegal).

<comment><USER20> As soon as I saw the Parrot AR Drone I imagined putting a small stripped down pellet gun on it.

I bet AR Drone will mysteriously become illegal soon.

<comment><USER15> Technically, it already is for outdoor use in the UK, unless the person flying it is not the person looking at the first person view, as the pilot has to keep visual contact with the aircraft. Also if you use one for anything commercial you are required to hold a civil pilots licence.

<http://www.buzzflyer.co.uk/aerial-photo-uav-fpv-law.asp></comment></comment></comment></comment>


Ask HN: Who moved from Angular to React and why? - <AUTHOR> <comment><USER2> I move from angular 4 to react TS for my side projects. Mostly because of the main philosophy (components vs functional, my back-end is in scala) but for using redux as well. The capacity to replay user behavior is a killer feature. And a well designed tools enable a development velocity I didn't have with angular.

<comment><USER3> Hi, I'm a Redux maintainer. Glad to hear it's useful for you! Any particular extensions or approaches you're using to capture user behavior?

</comment></comment><comment><USER4> When angular 2 was released and I noticed that I had to re-learn angular I changed frameworks as I thought it was more work than learning react.

Best decision ever, react api hasn't changed much.

<comment><AUTHOR> Thanks, appreciate the answer.</comment></comment>


Thousands of EVE online players riot over microtransactions - <AUTHOR> http://mmodata.blogspot.com/2011/06/riots-in-eve-against-microtransactions.html <comment><USER2> You know what the best way to protest a game is? Stop playing for a while and send an email.

I know this sounds absurdly little, but look at it this way: If you're out doing other things, you might find something you like and -never come back-.

This scares the bejeezus out of game developers who exist solely on the fact that people are addicted. If their playerbase actually went and did other things, they couldn't keep going.

So yeah, a few thousand people clogging up the arteries of the system is impressive, but having your numbers drop from 30,000 people at a time to 25,000 at a time is really scary.

<comment><USER3> Okay, two things that are relevant to this particular instance of outrage that you may not be familiar with regarding EVE:

1) The real rage is not over the Incarna vanity items, which are priced silly, but ultimately pointless. It is over a leaked memo which suggested that RMT was planned for game affecting items like ships, weapons, and faction standing.

2) If you quit EVE for even a little while, you are ceding control over space and resources to other players in the game. EVE is one of the few games that has fulfilled the promise of a truly persistent and meaningful game world. In the major alliances, there are political and military structures designed to ensure control over null-sec systems and the planets and facilities that can produce high-grade equipment.

For your suggestion to work, either players would have to decide that their protest is worth throwing away the time and effort they've put into territorial control and asset development OR that everyone in the game would have to agree not to take territory while the protest was going on.

<comment><USER4> People in empire corps could take a month off without risking anything. When I was playing all the action was in 0.0, but most of the _players_ were in high security space.

<comment><USER5> Yeah, but the impact of a RMT system on non-vanity items has the greatest effect on the players who actually engage in pvp a lot, the null sec players.

</comment></comment></comment></comment><comment><USER6> > for people not familiar with EVE: Jita is the main trade hub of the game. > Since EVE only has one server, that makes Jita the de-facto capital of the > game, and it's main system. There are other simmilar (but smaller) trade > hubs (Amarr and Rens, among others), and those are seeing protests as well. > Those systems have a hard limit to their population, and when it's capped, > the gates close. The protests seem to have capped both Amarr and Jita, and > are therefore stopping people from entering the picketed systems, slowing > down the player-driven market inside them.

[http://www.ps3trophies.com/forums/pc/63552-eve-online- virtua...](http://www.ps3trophies.com/forums/pc/63552-eve-online-virtual-jita- protest-over-ccps-microtransaction-system.html)

<comment><USER7> This has a much bigger impact than canceling your own subscription. It raises the danger that you might impact other players to quit. If I were a new player and I found that the servers were too clogged over protests, I might be inclined not to continue. If I were a more casual player, I might go outside, go play another game, or do something else and find I have better things to do than play Eve every night.

This is actually how I quit MMOs in college. When it started to feel like a job when I logged in every evening due to the commitments the game placed on a guild for "serious progression" I stopped logging into avoid it. Then I realized fairly quickly that were many other things I'd rather be doing and I cancelled.

Get someone to stop logging in for a week and you could very well lose them.

</comment></comment><comment><USER8> i don't know much about this, but it seems that they've introduced vanity items at "real world" prices. so you can buy, say, "designer" clothing for several hundred dollars. at the same time, the hardware you use in the game is staying at a much lower level. now obviously they can't charge realistic prices for spaceships, but the resulting contrast seems to be surprising a lot of people.

from a non-involved viewpoint it's an interesting take on what "price" might mean in post-scarcity environments.

<comment><USER9> There are no prices without scarcity.

<comment><USER10> In this case, it's what the market will bear. If people buy $500 designer clothes in EVE, the management will continue to sell them.

<comment><USER9> There are NO prices without scarcity.

<comment><USER11> yes, and in this case it's an artificial scarcity. CCP controls access to the items, and thus has complete control over their price and scarcity.

</comment></comment></comment></comment></comment><comment><USER12> Virtual riots. Fascinating. SPACE ANARCHY!

Are they destroying in-game property by their actions? Or is it just noise? The post talks about the capital 'burning.'

All we need now is lulzsec to inject their galleon into the server to take everyone's credits in some kind of hilarious mirroring of the mtgox debacle.

Surely the opportunity for nautical/piratical double entendre, _and_ apocalyptic nerd-drama is too much for them to resist?

EDIT: do the SA forums still control the eve universe these days?

<comment><USER13> Just creating noise mostly.

<http://dl.eve-files.com/media/corp/verite/influence.png>

The top left yellow area is SA forums. Below them TEST ALLIANCE PLEASE IGNORE is mostly Reddit.

</comment></comment><comment><USER14> When I played Runescape, we had similar massive riots over the removal of free trade and the old pvp system (wilderness pking). The pkers were on average decidedly less mature than the average player, so there was really poor communication from them, but also from the company Jagex, who struggled to explain the 'why' behind the changes.

Can anyone who plays Eve comment on how the company is responding?

<comment><USER15> I'm a (retired) director of one of the larger corps in EVE, and I've been discussing the points of contention with members today.

Most of it stems from the fact that those rioting feel the prioritization of the walking-in-stations expansion and the addition "vanity items" is poor judgement. There are bugs, missing features, and new changes that are viewed by the rioters to be of far greater importance than the time spent on this latest update.

There's a semi-offical "voice of the riot" here:<http://eve.beyondreality.se/NeXCQResponse.html>

And CCP's response here: [http://www.eveonline.com/devblog.asp?a=blog&bid=932](http://www.eveonline.com/devblog.asp?a=blog&bid=932)

<comment><USER15> And now that you've read that, I'll keep my opinion separate: I think the riots are out of line and unnecessary. CCP does need to do a better job at addressing the complaints (requests are listed here [http://wiki.eveonline.com/en/wiki/November_2010_Prioritizati...](http://wiki.eveonline.com/en/wiki/November_2010_Prioritization_Crowdsourcing_\(CSM\))) and explaining their prioritization... but I think the riots have trouble focusing on the real issue, which is simply communication.

</comment></comment></comment><comment><USER16> And now an email from the CCP CEO has leaked, which ignores the significant problems with the deployment and essentially says that he will not listen to the users (cloaked in some otherwise reasonable language).

[http://www.evenews24.com/2011/06/25/ccp-hilmar-global- email-...](http://www.evenews24.com/2011/06/25/ccp-hilmar-global-email-shows- the-reasoning-behind-ccp-zulu-devblog/)

</comment><comment><USER17> Emergent gameplay!

</comment><comment><USER18> Live video of the Jita protest: <http://en.justin.tv/deamosseraph> It's really quite impressive!

Edit: there's another one at Amarr, <http://www.justin.tv/dnah_pmip#/w/1381178160/2> but it's not as big.

<comment><USER19> I wonder if Concorde will destroy their ships and camp whatever station they're around, forcing them to stay in the same place for bloody hours, deprived of resources needed to stay alive.

</comment></comment><comment><USER20> I partially believe that CCP will end up being okay after the dust settles just because I have never known of any gaming community to have a truly successful protest. The sad part is that the precedence this sets is antithesis to good customer service.

</comment><comment><USER19> Really, people are getting this raged about shit in an online game? Take to the streets, my friends. Fight for the real world, not an imaginary one.

<comment><USER21> You shouldn't shit on what other people do for fun or in their free time.

Some people use online games like this to escape their real life, whether its to escape disease, sickness or other less serious things.

<comment><USER22> I don't have a problem with people using games to escape their real, shitty life. But then picking a game that makes you so angry you want to riot sounds like a strange choice. I mean, if you _are_ going to riot, there's plenty of things to protest about in your real, shitty life that impact you more. (Granted, it also takes a lot more effort to deal with.)

</comment></comment></comment><comment><USER23> i believe also that a lot of players weren't happy with the upcoming Dust514 being Playstation only.

Some would like it on other consoles (XBOX) and the rest feels betrayed for playing eve for so long and not being able to play on the PC.

Thats it! I'm quitting this game and giving all my ISK away for this 1 Tritanium!!!</comment>


Pervasive functional translation of noncanonical human open reading frames - <AUTHOR> https://science.sciencemag.org/content/367/6482/1140 <comment><USER2> What? Can somebody explain this like I am a software engineer?</comment>