Task_t considered harmful - <AUTHOR> https://googleprojectzero.blogspot.com/2016/10/taskt-considered-harmful.html <comment><USER2> Copying my comment from the earlier submission that didn't gain much traction here:

What an absolutely amazing tour-de-force of a devastating design flaw in all versions of macOS and iOS and tvOS and watchOS!

The negotiations detailed in the bug report timeline about meetings between "senior apple and google leadership" for keeping this secret past the general deadline really underlines that.

<comment><USER3> Yeah - the failed mitigations followed by a "long term" fix was interesting as well. Apple literally had to change execve() this late in the OS's development cycle to allocate new task and thread structs(that's two extra allocations and copies in hot path!) to fix it for good. That this design problem lingered around for so long doesn't look good for Apple - it's one thing for a use after free bug in obscure piece of code to linger but bad design affecting a ton of their own frequently used code to stand so long is somewhat brown bag category!

I wonder what other fallout we might experience from this.

<comment><USER4> Business as usual with macOS. The other day I was browsing the ocspd source code. Turns out it calls openssl using system(). So openssl is officially deprecated on macOS and yet they're using it internally to handle certificates?! And there's an enlightening comment:

        /* Given a path to a DER-encoded CRL file and a path to a PEM-encoded
         * CA issuers file, use OpenSSL to validate the CRL. This is a hack,
         * necessitated by performance issues with inserting extremely large
         * numbers of CRL entries into a CSSM DB (see <rdar://8934440>).

[http://opensource.apple.com/source/security_ocspd/security_o...](http://opensource.apple.com/source/security_ocspd/security_ocspd-55128.40.1/server/ocspdServer.cpp)

ocspd was introduced with 10.4. A decade ago. And that's really the problem with macOS: There's no refactoring of old hacks, but rather just bolting on of ever more new stuff.

<comment><USER5> Apple needs to take a bit of those tens of billions of dollars they have sitting around and spend it on starting from scratch with something that's not horrifically crufty. The quality of their software is lagging so far behind the quality of their hardware right now. Realistically, I think we may just be at the point where operating systems and all the stuff the companies put on top of them are too complicated to keep developing in the traditional way with traditional tools. Formal verification might be the cheapest way forward at this point.

<comment><USER6> So far as the current state of the art in computer engineering goes, we don't know how to completely rewrite a system as complicated as XNU without creating fresh batches of implementation errors. So this is a little like suggesting Apple use its hundreds of billions of dollars to build an iPhone battery that only needs to be recharged once a month.

We may someday get an XNU rewrite, but probably not until software engineering produces a new approach to building complex systems reliably that works at the scale (here: number of developers and shipping schedule) Apple needs.

<comment><USER7> This is so, so true, that I wish there were enough beer in this world to gift you with. There's a lot of cruft in XNU, and there's even more of it in the rest of the system, _but_ all this heap of hacks isn't just useless cruft that we'll be better off without. That heap of code also contains almost twenty years' worth of bugfixes and optimizations from more smart engineers than Apple can hope to hire and get to work together in a productive and meaningful manner. All this unpleasant cruft is what keeps the system alive and well and the users happy enough to continue using it.

More often than not, systems that get boldly rewritten from scratch end up playing catch-up for years. Frankly, I can't remember a single case when a full rewrite with an ambitious timetable wasn't a full-scale disaster. The few success stories, like (what eventually became) Firefox have taken a vastly different approach and took a lot more than users would have wanted.

A lot of idealistic (I was about to write naive) engineers think it's all a matter of throwing everything away. That's the easy part. Coming up with something _better_ is the really hard part, and it's not achieved by just throwing the cruft away. If you innocent souls don't believe me, come on over to the Linux side, we have Gnome 3 cookies. You'll swear you're never going to touch anything that isn't xterm or macOS again.

<comment><USER8> > This is so, so true, that I wish there were enough beer in this world to > gift you with. There's a lot of cruft in XNU, and there's even more of it in > the rest of the system, but all this heap of hacks isn't just useless cruft > that we'll be better off without. That heap of code also contains almost > twenty years' worth of bugfixes and optimizations from more smart engineers > than Apple can hope to hire and get to work together in a productive and > meaningful manner. All this unpleasant cruft is what keeps the system alive > and well and the users happy enough to continue using it.

This whole premise is a false dichotomy. Apple does not have to throw away Mac OS X, and it does not have to keep piling crap on without fixing things. If you stop the excuses and rationalizations and commit to code quality you can ship an operating system with quality code and minimal bugs. The OpenBSD project has been doing this for two decades with minimal resources. There is no valid excuse other than "we are too lazy and incompetent."

<comment><USER7> I was (obviously...) responding to this:

> Apple needs to take a bit of those tens of billions of dollars they have > sitting around and spend it on _starting from scratch with something that 's > not horrifically crufty_.

They certainly don't have to throw everything away. Not having thrown everything away is one of the reasons why OpenBSD is a good example here. Remember all that quality code that was in place before Cranor's UVM? (Edit: actually, the fact that UVM is an improvement over it should say something, too...)

And, at the risk of sounding bitter, in my experience, very few companies have the capability to "commit to code quality", and I don't think Apple is one of them.

Edit: BTW, I really like your blog. You should write more often :-).

<comment><USER8> > Remember all that quality code that was in place before Cranor's UVM?

So much before my time I was not even aware of it. For the uninitiated: [https://www.usenix.org/legacy/events/usenix99/full_papers/cr...](https://www.usenix.org/legacy/events/usenix99/full_papers/cranor/cranor.pdf)

> Edit: BTW, I really like your blog. You should write more often :-).

Thank you. :) Just this week I started thinking of getting back into it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment> a-no-n Ever since installing 10.12.1, I've been having a bunch of processes randomly entering a quasi-paused SIGSTOP-ish state (neither closable, apps not "bouncing" (loading) and just not responding. Running Instruments, correlating logs and such doesn't identify any clear cause. I'm having to `sudo kill -CONT -1` in order to get things moving again. I'm wondering if it's related to XNU mitigations or just some spurious "system configuration entropy" on my box.

<comment><USER9> I did exactly this when my Mac ran out of memory yesterday. Safari hung with a 'your computer is running out of memory' warning (168 tabs open!) and I didn't want to lose them all by force quitting. But the Safari process itself wasn't "Not Responding" and we were back to 0% CPU.

So I quit everything else, SIGCONT'd Safari, and it started responding again, so I tried unsuccessfully to close some tabs. Of course, Safari somewhat isolates pages in separate processes, so I ran `ps aux | grep WebContent | grep -v grep | cut -d' ' -f11 | xargs kill -SIGCONT` as well.

It all sprang back to life, and all the tabs I'd shut in vain zipped away. Got that one saved for later. It's probably easier just to use -1 now I've learned what that is!

I do wonder what's suspending these processes indefinitely. I should have done more inspection to see what state they were in. I'm not familiar with how WebKit content threads communicate though, so that's for another day.

<comment> a-no-n I have 16 GiB and 0 GiB was occurring.

</comment></comment></comment><comment><USER10> Interesting timeline stuff here:

[https://bugs.chromium.org/p/project- zero/issues/detail?id=83...](https://bugs.chromium.org/p/project- zero/issues/detail?id=837)

<comment><USER6> It's funny, but I think it's written that way on purpose, not just as snark.

It's a little tricky to keep track of what happened here. There are 4 bugs in this post, and (I think) 2 different timelines: the UAF timeline for the first bug, and the TOCTTOU timeline for the 3 subsequent bugs. What's important to understand about the three TOCTTOU bugs is that there's a "right" fix for that bug, and a series of wrong fixes that delay the inevitable. Ian Beer and GPZ probably go into this whole process knowing what the right fix is, and with predictions on how they'll defeat any of the wrong fixes.

So it looks like GPZ reported a bug and then found flaws in the mitigations, but really all three of the flaws they found were known, at least conceptually, when GPZ reported the TOCTTOU race to Apple.

In the TOCTTOU timeline, Apple got an extension. Subtextually, it sounds like Tim Cook called Sundar Pichai. GPZ does not want to give extensions. They have a 90 day disclosure timeline, it's very well known, and probably the healthiest disclosure process in the industry. It's problematic for GPZ to give extensions because next time Tavis Ormandy finds a vulnerability in Norton Antivirus, Symantec is going to try to play chicken, and GPZ doesn't want to be at day 89 having to decide whether to drop zero-day versus being held hostage by a patch schedule.

But if a bug escalates all the way to Tim Cook, GPZ is probably pretty OK just with the degree to which that raises the profile of their bug --- it's hard to look at that and think Apple isn't taking your bug extremely seriously. So they'll trade the raised profile for the 5 week extension.

So they include a bunch of fuck-yous to Apple in the disclosure timeline, messaging to other vendors that GPZ is not going to budge even if your dumb original fix turns out to have a flaw that Ian Beer will notice and exploit. If you want the extension, you'd better have a Tim Cook.

Or maybe they're just having fun. Either way, a good read!

<comment><USER11> I wonder if it was really the CEO or was it someone else, and who it is probably is here.

<comment><USER6> It could have been Craig, too.

</comment></comment></comment></comment><comment><USER12> I'm still with 10.11. I don't plan to update soon, since the benefit of Siri, Photos and the other major features is quite small, compared to the risk that I might loose working days if something goes wrong ( I'm a freelancer ).

As far as I read in the article there will be 10.12.1 ( the final fix ) which will have that part of the kernel refactored. I hope Apple will also support 10.11 and issue an update with the same fix.

<comment><USER13> I got an update to 10.11 El Capitan yesterday, which probably fixes the vulnerability. You can see the fix in Apple's support page, have a look at the bottom of the page about "System Boot":

[https://support.apple.com/en-us/HT207275](https://support.apple.com/en- us/HT207275)

It looks like even 10.10 Yosemite got a fix. Here's a full list of security fixes Apple has made to its software:

[https://support.apple.com/en-us/HT201222](https://support.apple.com/en- us/HT201222)

<comment><USER2> Sure looks like it, 10.10 + 10.11 + 10.12 is listed under the "System boot" CVE-2016-4669 entry. That must have taken quite the effort to backport!

</comment></comment></comment><comment><USER14> I would argue that the original underlying problem here is the idea that having execve() increase privilege is acceptable. It's necessary for legacy reasons (sudo, anyone?), but even then, it's barely necessary. "sudo foo" could be implemented by asking a privileged daemon to run foo and handing off access to the console to the daemon.

On Linux, you can do PR_SET_NO_NEW_PRIVS to turn off this type of privilege gain, and it's even required for certain purposes. I would _love_ to see someone develop a distribution that enables no_new_privs for all processes.

<comment><USER15> > "sudo foo" could be implemented by asking a privileged daemon to run foo and > handing off access to the console to the daemon.

FYI that exists, it's called pkexec (yes, from polkit) :)

</comment></comment><comment><USER16> Can someone explain what this means for the end user?

<comment><USER6> It's a pattern of privilege escalation bugs. If you run untrusted code on your machine, that code can obtain root or alter the kernel, potentially even if it's running as nobody.

There is a relatively long sequence of attempts to band-aid the bug, all of which failed, because Ian Beer found a systemic flaw, not just a single point flaw. So, the other implication for users is a general sense of foreboding.

<comment><USER17> So Apple still has no real solution to this bug?

<comment><USER18> The real solution (refactoring how execve creates tasks) was release with 10.12.1 (and updates to prior versions of OS X too).

</comment></comment></comment></comment><comment><USER6> Bug 1: Many XNU drivers save task_t's on the heap without bumping their refcount.

        1. Attacker creates process A and B
        2. B->A send task port Bt
        3. A->XNU request IOKit framebuffer client for Bt
        4. A ditches Bt, retains client
        5. Kill B; Bt in client now dangling
        6. Trigger creation of privileged C, unrelated to A & B
        7. C inherits memory once used by Bt
        8. A use retained framebuffer client to write C's memory

What's important to understand is that this is not just a single UAF, but a pattern of UAFs scattered throughout XNU.

Fix: at step 3, check to make sure the task being given to IOKit is owned by the task making the IOKit request.

Bug 2: IOKit drivers cache task details on their stack; the lifetime of that cached task is the lifetime of the IOKit kernel object, not of the program that made the request. In particular: if you execve() an SUID, the task_t is repurposed.

        1. Attacker creates process A and B
        2. B->XNU request IOKit framebuffer for Bt, Bc
        3. B->A send client Bc
        4. B execve /bin/su. B is now running as root.
        5. A use retained framebuffer client to write B's memory

The tricky thing here is that this isn't just one bug, but a pattern of bugs: every place where a driver stashes a task_t on the heap and exposes functionality through a passable object is a place where colluding processes can potentially take advantage of SUIDs to raise privileges.

Fix: Lifetime of IOKit clients now tied to lifetime of creating process.

Bug 3: Even if a driver doesn't save a task_t on the heap, they're saved on the stack during the servicing of system calls and kernel mach message handlers, so there are race conditions.

        1. Attacker creates process A and B
        2. B->A send task port Bt
        3a. A->XNU task_threads(Bt), retrieving thread ports for Bt
        3b. (simultaneously) execve /bin/su. B is now running as root.
        4a. task_threads converts Bt to a task_t
        4b. execve modifies the same task_t to replace thread ports
        4c. task_threads retrieves the (now privileged) thread ports.
        5. A uses thread ports to overwrite registers and take control of B.

Fix: Kernel objects now check to see if a task_t has been touched by execve before returning them to userland. Even if you win the race, that failsafe prevents the kernel from giving you privileged objects.

Bug 4: You don't need the kernel to give you a privileged object directly; all you need is to be able to influence a privileged object.

        1. Attacker creates process A and B
        2. B->A send task port Bt
        3a. A->XNU task_set_exception_port(Bt), wiring A to B's exceptions
        3b. (simultaneously) execve /bin/su with rlimited stack. B is now running as root, briefly.
        4a. task_set_exception_port converts Bt to a task_t
        4b. execve modifies the same task_t to replace thread ports
        4c. task_set_exception_port rewrites the exception port.
        5. stack access in B, running /bin/su as root, causes a SEGV
        6. XNU generates an exception message, passing with it the thread ports, to A
        7. A uses thread ports to overwrite registers and take control of B.

Fix: table flip. Rewrite execve so it generates entirely new task_ts when loading binaries, rather than repurposing old task_t.

This is all pretty magnificent. What's best about it is that it totally justifies the title of the post: pretty much every place in XNU where they save a task_t creates a TOCTTOU bug.

<comment><USER2> In particular about "pattern of UAFs scattered throughout XNU", there was missing memory management of task_t references in the _sample code for kext drivers_. So it wouldn't be enough to just add the missing retain calls in the Apple XNU kexts, because there may be an unknown number of third party kexts out there. Perhaps not as many as windows has device drivers, but it's still the same type of thing. Can you imagine if every windows device driver turns out to have copy-pasted privesc bugs?

In fact I think there was a similar bug-in-the-templates requiring a world- wide recompile in Microsoft MFC/ATL, perhaps it was this one [https://blogs.msdn.microsoft.com/vcblog/2009/08/05/active- te...](https://blogs.msdn.microsoft.com/vcblog/2009/08/05/active-template- library-atl-security-updates/)

</comment></comment><comment><USER19> The sad reality is that black hats have been exploiting this class of bugs for _years_.

<comment><USER20> GPZ finds a entirely new class of vulnerability, Apple takes 4 months to patch and resolve. And you claim this has been exploited for years. There is 0 evidence of this, and such a claim demands proof.

I would be happy to apologise if you could find one example of exploitation prior to a few days ago when it became public.

<comment><USER19> The point of the 0-day black market is to not reveal these attacks publicly. If there were public proof of this in the past it would have been fixed in the past.

Take my word for it when I say there are upper echelons of black hats that are stockpiling unknown 0-day exploits like this and presently using them in the wild.

Or dismiss me as irrational and continue with the belief that all bugs are unknown until white hats share them with Apple.

<comment><USER21> There is a middle ground between "all bugs are known on the black market" and "no bugs are known only on the black market."</comment></comment></comment></comment>


Working with Mark Zuckerberg - <AUTHOR> http://www.facebook.com/note.php?note_id=339013388919

<comment><USER2> No offence, but am I supposed to expect a blog post on the Company blog about working with the founder to be unbiased?

Given that and the reverential tone, I am inclined to discount it.

Bonus exercise: Replace "Zuck" with "Chuck Norris" in the entire post and note how it doesn't seem any less ridiculous :)

<comment><AUTHOR> One sentence that caught my attention was "He doesn't care what he said yesterday, even if he was presented with the same product."

<comment><USER2> I am beginning to wonder if the guy who wrote the post put some of this stuff in intentionally.

<comment><USER3> I work at facebook (not speaking offically, mind) and can vouch for the fact that this was originally not intended for public consumption. It was written and circulated on an internal mailing list months ago. We only put it up on the engineering blog after it "leaked" in a WSJ article yesterday, and we realized the "leak" really did more good than harm.

I can see how this email can make it sound like there's a "personality cult" surrounding Mark Zuckerberg. It's not really that strange. Inside facbeook, he's a force of nature, like all other founder-CEOs: "working with Zuck" is properly a special topic, and facebook employees pay special attention to it, as I assume Apple employees do to "working with Steve", google employees do to "working with Larry and Sergey", and I did to "working with Diane" while at VMware.

<comment><USER2> O.K. It makes more sense now.

</comment></comment></comment></comment></comment><comment><USER4> I would argue with the assertion that he doesn't look at other products when evaluating Facebook. Its clear they've been copying from Twitter and FriendFeed for years, so I don't know where the Boz is getting that from.

<comment><USER5> He had the same idea as Twitter, some time before it launched. His version involved aggregating AOL Instant Messenger away messages--and that's the closest thing to Twitter, before Twitter.

<comment><USER6> I had that idea too, and so did thousands of other people. Twitter is the one who executed on that idea.

</comment></comment></comment><comment><USER7> clearly change is a big part of the facebook environment, and I guess we can credit Zuck fostering that.

The question I have is, seeing as most users don't come to the computer with fresh-eyes every day, can too much change eventually end up hurting the company.

They clearly do change extraordinarily quickly, and so far it has worked well for them, but is it just a matter of time before they go too far. The most recent redisign, I don't think added any benefit to the site, I don't think it looks as good, and I don't see where there was an improvement in functionality.

</comment><comment><USER8> Yes, I've heard. Kills competitors by the hundreds. And if HE were here, he'd consume the Google with fireballs from his eyes, and bolts of lightning from his arse!

</comment><comment><USER9> How cretinous the comments are. Facebook clearly fails as a blogging platform for this sort of content.

<comment><USER10> I am getting very close to writing a Firefox extension called "CommentBlock". If people want to comment on blog posts and newspaper articles, fine, but I don't want to see them. They just make me mad.

<comment><USER11> You might like <http://stevenf.com/pages/shutup/>

<comment><USER10> Brilliant. Thanks for the link.

</comment></comment></comment></comment><comment><USER12> I dislike the fact that "zuck" is worthy of writing about like this. He's no genius, he seems to have gotten very lucky, which is fine.

He's a terrible public speaker and he's terrible at conveying his ideas. This smells, given that it's written on FACEBOOK's blog. What's the point of this?

<comment><USER13> IIRC he built a million dollar product while still in hs. "Luck favors the prepared mind."

I see an inordinate amount of vitriol directed at him online. I assume it's mostly jealousy. He built a monster product that in hindsight seems very obvious, and you didn't.

<comment><USER14> IMO, the bulk of the vitriol comes from two issues (not that I think much of it is sound):

\- Multiple claims of outright dishonest behavior and undue credit-taking entitlement from his co-founders (even prior to the lawsuits)

\- His extremely privileged background. Given his family's political connections, wealth, ivy-league legacy, and prep-school pedigree, he risked very little (compared to most entrepreneurs) when giving a pre-undergrad start-up a go.

<comment><USER15> I'm not impressed by Mark, but I don't see a good reason to hate him, especially regarding the second, which is not at all his fault.

<comment><USER14> Exactly. It's the silver-spoon opportunity cost fallacy over which he has ZERO control.

It's irrational and wrong, but sadly makes for more "press" and "drama". A prime example is the plethora of rich-kid "reality" t.v. shows which leverage those atavistic reactions it to the hilt.</comment></comment></comment></comment></comment>


All-New Kindle Paperwhite - <AUTHOR> http://www.amazon.com/gp/product/B00AWH595M/ref=amb_link_382772722_1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=gateway-center-column&pf_rd_r=19GTC3R8APHYGEX1JDJG&pf_rd_t=101&pf_rd_p=1611850642&pf_rd_i=507846

<comment><USER2> Amazon URL without all the extra stuff: [http://www.amazon.com/gp/product/B00AWH595M/](http://www.amazon.com/gp/product/B00AWH595M/)</comment>


Satoshi: "I am not Craig Wright. We are all Satoshi." - <AUTHOR> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011936.html <comment><USER2> Obviously this is fake. I can't imagine satoshi saying "we are all satoshi" \- so much cringe...

Plus, we know that the gmx account was hacked and it seems it was hacked through a simple guess of his birthday. As such, it seems reasonable to suggest that satoshi wanted that (gmx) email to be hacked since it had such a weak password. If that is the case I think we can assume that the vistomail is probably hacked too for the same reasons satoshi would have wanted the gmx email to be hacked.

Plus, I think it is now sort of obvious that Craig is not satoshi. There is speculations that this guy does not even have a supercomputer:

[https://www.reddit.com/r/Buttcoin/comments/3w5ro9/wright_not...](https://www.reddit.com/r/Buttcoin/comments/3w5ro9/wright_not_only_isnt_satoshi_but_hes_pretending/)

As such it may be the case that he conned the ATO out of a 45 million tax "rebate" and then tried to claim he is satoshi to perhaps keep the scam going or make it more credible (although his silence and even his apparent deletion of his online presence is somewhat puzzling.)

Moreover, the "trust fund" smoking gun document reads like one of those phishing emails you get - a puzzling misstated amount, an unended sentence, peculiar "against my advice" comments and looks overall amateurish. Furthermore, people have been trying to find peer reviewed journals from this guy (he claims he has 100) with no success so there is much doubt of his claims he has a PHD, well two PHDs and a dozen or more Masters.

Not to mention his seemingly inability to spell.

If, thus, it is somewhat obvious that this guy is not satoshi, I don't see why the real satoshi would find it necessary to make the somewhat cringy comment above which sounds like a "commoner". Same goes for the "I am not Dorian". Neither is in anyway evidence or in anyway proves anything and in both cases it is/was obvious the person was not satoshi so the comment was unnecessary.

Therefore, I think these accounts have simply been hacked and the real satoshi never made such comments in either case.

<comment><USER3> If Wright wanted to make it look like he was Satoshi, it would seem a bit absurd for him to try to claim that he would no longer be able to provide financial accommodation to Hotwire due to losing a substantial sum of money because of the Mt. Gox collapse (given that Satoshi is assumed to hold a lot more, and also because Satoshi wouldn't have been so stupid as to store such a large sum there, not being in control of the private keys):

"Hotwire hit problems in April of last year when it failed to receive another expected tax rebate worth millions of dollars, killing its cash flow. McGrath Nicol wrote to creditors in May 2014:

"The Directors have attributed the failure of the Company to:

– delays in receiving the $3.1 million GST refund for the September 2013 quarter; and

– Dr Wright, as the major shareholder no longer being able to provide financial accommodation to the Company due to the collapse of the Mount Gox Bitcoin registry where we understand Dr Wright had a significant exposure.""

[http://www.businessinsider.com.au/revealed-the-ato-hit- suspe...](http://www.businessinsider.com.au/revealed-the-ato-hit-suspected- bitcoin-creator-craig-steven-wrights-company-with-a-1-7-million- penalty-2015-12)

</comment></comment><comment><USER4> So now that Satoshi has said he is not Craig Wright, can we take the other path of the Wired story, that "he's a brilliant hoaxer who very badly wants us to believe he did."

Sad.

Edit to add PS: Also what is Satoshi's original mail. I hope firstname.lastname@example.com is the original, ans satoshin was created later on, which was the _non evidence_ kanzure was so unhappy about yesterday?

<comment><USER5> > Edit to add PS: Also what is Satoshi's original mail. I hope > email@example.com is the original, ans satoshin was created later on, > which was the non evidence kanzure was so unhappy about yesterday?

I feel that in the interest of disclosure I should inform you that I am one of the moderators of the bitcoin-dev mailing list and I approved that email. I regret it already. (Email is trivially forged, it's off-topic, etc. To my credit, there's some nebulous moderation policy in effect, and hopefully we will get that cleared up very soon.)

re: gwern stuff, i assume you are talking about [https://news.ycombinator.com/item?id=10702001](https://news.ycombinator.com/item?id=10702001)

<comment><AUTHOR> I think rejecting it would have been the wrong action. On what grounds?

<comment><USER5> > I think rejecting it would have been the wrong action. On what grounds?

[http://bitcoinstats.com/irc/bitcoin- dev/logs/2015/12/10#l144...](http://bitcoinstats.com/irc/bitcoin- dev/logs/2015/12/10#l1449730961.0)

<comment><AUTHOR> "i was told _not_ to moderate for signal-to-noise"

I am not a moderator, but that was my impression (and hope) for how the moderators would act. To determine what is signal and what is noise would be to inject subjectivity into the decision.

There is nothing about this new email that I would consider on-topic. But under the circumstances I wouldn't consider it disruptive either (on-list replies might be; watch out for them). And arguments could be made that using a communication medium other than the one Satoshi has traditionally used would be _more_ disruptive, even if this email would be more on topic at bitcoin- discuss, due to the speculation that might ensue.

It is also worth pointing out that the system of moderation is that a person's FIRST post to the mailing list is moderated. After passing that hurdle your emails are auto-approved until such time as a moderator choose to re-enable moderation. It is because we changed servers that the satoshi email address was considered a 'new' user. This is also the case of everyone else, including me. But I hope the irony of Satoshi being subject to moderation because he is a 'new' user is not lost?

Anyway, the best reason for not moderating was that such a message had potential to keep people from getting hurt. I can only speculate that to be the reason Satoshi (if it is Satoshi) intervened at all. We don't know for sure, and it may even be low probability, but interfering with the distribution of that email could have gotten people hurt.

<comment><USER5> > I wouldn't consider it disruptive either (on-list replies might be; watch > out for them)

Already happened, but looks like the reject mailing list isn't configured correctly: [https://lists.ozlabs.org/pipermail/bitcoin-dev- moderation/](https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/)

> It is also worth pointing out that the system of moderation is that a > person's FIRST post to the mailing list is moderated.

Hard to moderate for signal-to-noise with that, eh?

edit: for reference, this is also discussed over at [https://www.reddit.com/r/Bitcoin/comments/3w6vy4/i_am_not_cr...](https://www.reddit.com/r/Bitcoin/comments/3w6vy4/i_am_not_craig_wright_we_are_all_satoshi_satoshi/cxtv3hn)

</comment></comment></comment></comment></comment></comment><comment><USER6> How can one know that this message is from Satoshi?

<comment><USER7> One can't. That's the whole point.

<comment><USER8> It could have been signed with Satoshi's PGP key.

<comment><AUTHOR> Which key is that? He never used PGP...

<comment><USER9> Aren't bitcoin addresses public keys? If it's good enough for signing a blockchain transaction it should be good enough for signing a short email message.

<comment><USER10> Yes they are, and that's definitely possible as well.

</comment></comment></comment></comment></comment></comment><comment><USER11> GPG or it didn't happen. Until then, this is just noise.

<comment><AUTHOR> Satoshi never signed anything ever. How would a signature from a key Satoshi never used prove anything?

<comment><USER11> Sorry for nitpicking. People _claiming_ to be Satoshi did so and didn't sign. It could be the real deal, or not. Maybe I wrote all of those, and just typed "Satoshi" in the "from" field?

I also want to believe, but as long as something isn't signed cryptographically, it's likely just someone pulling things out of their arse (or SMTP server)

<comment><AUTHOR> Actually this is a case of people claiming to be Satoshi and signing with back-dated, fraudulent keys.

</comment></comment></comment></comment><comment><USER12> Got in touch with a friend last night who is one the Bitcoin inner circle and he said the PGP key used a different hash algorithm than the real Satoshi and it's a hoax. That was a good twelve hours before that story was in the press. I have a feeling if the inner circle doesn't know for certain who Satoshi might be they've got a pretty good idea.

<comment><AUTHOR> We don't. (And don't want to know.)

</comment></comment><comment><USER13> It's not signed with the one legitimate Satoshi key, its just another hoax

</comment><comment><USER14> Well. That is the end of that. It did seem pretty unlikely that a rather disheveled dude that seemed to have pretty bad opsec would be Satoshi.

Guy clearly wants to remain away from the public eye, no idea why it's so hard for people to respect that.</comment>


The world is finally coming around to Starship Troopers - <AUTHOR> https://www.theverge.com/21319886/starship-troopers-movie-yesterdays-future <comment><USER2> I love the movie and the book and love the review but you have to be careful with that "f"-word, particularly I don't think you can say any movement outside of 1900-1950 is "fascist" because of the unique historical circumstances (Mussolini beat Lenin to the punch of revolution by one year!)

I remember the blue-and-white "Stronger Together" signs that were rushed out by the opposition during Brexit that were copied almost exactly by the Hillary Clinton campaign. I'd talk to people who were putting the signs up and although they were allegedly "globally minded" they did not know that the same signs had been test-marketed and failed in the U.K. (You'd know if you read The Economist.)

The feeling behind "Stronger Together" is the same as the bundle of sticks after which Facism is named (the "fasces") each which would break individually but would be unbreakable together.

It's a bad lawn sign because people don't believe it. There is cynicism and an expectation of irony. There is the "fear of a fascist planet", or just the reality that (as K.R.S. One says) "The [police] officer has the right to arrest, and if you fight back he put a hole in your chest".

Yet people sometimes do need to come together to fight a threat and it something we're going to have to figure out how to do with this virus, which is only a fire drill for what to do about global warming.

<comment><USER3> Here the key sentiment is solidarity, and "together" (without any "stronger") was the anti-viral theme.

[https://news.ycombinator.com/item?id=23438101](https://news.ycombinator.com/item?id=23438101)

(update: after a nearly two month interlude, briefly down to single digit new cases, we have now entered a second wave which has hit triple digits. Unemployment hit 3,4% but has since decreased.)</comment></comment>


Monetize your Flutter App using Ads - <AUTHOR> https://levelup.gitconnected.com/monetize-your-flutter-app-using-ads-3e1a15d94ded?source=friends_link&sk=6060e36e5bde78eda5e2bacc9543c429 <comment><AUTHOR> Were you lost in the internet, searching the best possible way to integrate Ads into your Flutter mobile app? Lucky You! You've found the best and easiest explanation to your issue. This article will explain how to integrate Google's Admob with Flutter.</comment>


Race conditions on Facebook, DigitalOcean and others (fixed) - <AUTHOR> http://josipfranjkovic.blogspot.com/2015/04/race-conditions-on-facebook.html <comment><USER2> I actually fixed the issue that was reported to LastPass.

I could be mistaken but I believe he reported the security issue through our regular support channel which is why it took three days to see (instead of our security channel). From the time I saw it, I fixed it with the patch going live within an hour or two.

When I DID see it, tried it myself with a quick shell script that that curled and backgrounded the same request a bunch of times, I just kind of chuckled. It was a good bug. Josip is top notch.

<comment><AUTHOR> Thanks! I reported the bug to security@ email, and one of your team's members replied on the same day (January 6th). Either way, good job on fixing this really fast. I wish more teams are as responsive as yours.

<comment><USER2> Oh okay I was mistaken then.

I believe the race condition is on the rise in terms of severity and importance. Developers are aware of common OWASP bugs, but this type of race condition is often overlooked and developers are going to NEED to be just as aware of. Way to go.

</comment></comment></comment><comment><USER3> We should see lots more of these if people embrace eventual consistency instead of "slow" ACID transactions. And interestingly, the more larger scale a system, the more likely that globally consistent operations are too expensive to enable in general, and developers will overlook cases where they must implement some locking or double checking.

<comment><USER4> when did eventual consistency equate to race conditions, or even increased susceptibility to race conditions? I don't follow. could you explain your reasoning further?

<comment><USER3> It's probably just an ease-of-use question. The more guarantees your database can deliver, the easier it is to reason about things and make sure you aren't being caught on a gotcha.

It's not necessarily different than using a normal RDBMS, right - you could do a check in SQL outside a transaction and end up writing multiple times. But with an RDBMS, you can easily solve the situation by turning on a transaction and leaving no question about things.

This is why things like VoltDB ("NewSQL") are pushing to keep SQL and ACID, and figure out a way to scale, instead of throwing it all aside and making the developer deal with consistency issues.

It's not that you can't end up with the same functionality using eventual consistency, just that it's harder. Just look at Amazon's "apology based computing" (I think that was the name) and how they structure their systems to be resilient by being able to resolve multiple conflicting commands in a proper way (deciding, without communication, which command wins, figuring out rollbacks, etc.) It's fantastic, and perhaps it's the only feasible way to operate at their scale. But it's also a hell of a lot more complicated than "UseTransaction = true".

(So my predictions/guesses: If developers that'd otherwise use a traditional ACID RDBMS switch to non-ACID (BASE?) systems, they'll end up introducing bugs due to the shifted responsibility of handling data consistency. And seeing how big servers are, and even how far sharding can take you with normal RDBMS, the scale at which people "need" to drop ACID is probably far higher than the point at which people are dropping it.)

<comment><USER5> I've always wondered, (but apparently not enough to figure it out by reading the Spanner whitepaper), but how do these systems typically handle it?

I guess if you were using an append only log that recorded the exact timestamp of the transcation, your datastore would eventually reconcile that for example promo code 1 was applied twice. But what do you do then? Rollback the 2nd application of promo code and deduct the credit from user account?

Where would the logic for that be programmed?

</comment></comment></comment></comment><comment><USER6> appreciating the joke (?) in the comments. [https://i.imgur.com/zWE5ABQ.png](https://i.imgur.com/zWE5ABQ.png)

</comment><comment><USER7> Wow, it seems like there is room here for a 3rd party vendor to implement promo code handling as a service, and to do it right once and for all.

</comment><comment><USER8> No bounty for bug report? Should at least have a nominal fee of $100 (else no one would bother to report it).

<comment><USER9> The economics of bug bounty programs could lead to misaligned incentives. Because the overhead cost to validate and communicate around bug reports isn't zero, the % of non-bugs submitted could become imbalanced because it is free to submit.

In most systems the reward is zero, so you can infer if a person has taken the time to submit a bug report it is because he/she is invested in seeing it fixed.

Context: I work at a decent sized company in SV on this type of problem.

<comment><USER10> So when I find a bug in say Paypal which allows complete account takeover and could sell it to an organized hacker group for say $100,000 or report it to Paypal "because I'm invested in seeing it fixed" and receive nothing - that is only an easy decision for the whitest of white hat hacker.

Properly designed bug bounty programs are a cornerstone to any company who remotely cares about the security of their product, period.

The idea of misaligned incentives due to poor bug reports being free to submit is ignorant - and worse toxic, because it sounds so true to an executive who has no actual understanding of the issue.

A quality bug report should take no more than 1 minute for a reviewer to look at and know if it's really a bug or not. If it can't, it should be rejected saying provide more clear details. For example a dom based xss attack could be reported with just a target URL and it is quite clear what the problem is. That would take 10 seconds to analyze.

Additionally, most bugs reported to most decent sized companies are reported by someone who has previously reported a bug to the company before. If someone is constantly reporting good bugs or the opposite, its quite easy to prioritize which of those individuals gets their emails read first.

<comment><USER11> Hi, I'm a security engineer. I work at one of the largest private infosec firms and I've done research on bug bounties that Google, Facebook, Twitter, CERT and 50+ other companies participated in.

Now that I've sufficiently named my experience, allow me to give my side:

1\. You will never receive $100,000 for selling a vulnerability in PayPal. You probably couldn't even find a buyer for it on the "black market." I have explained why repeatedly on Hacker News before, so I'm just going to link this: [http://breakingbits.net/2015/04/01/understanding- vulnerabili...](http://breakingbits.net/2015/04/01/understanding- vulnerability-half-life/)

2\. Bug bounties are not always a net positive for an organization. They are also not a cornerstone of good security posture. A foundational focus on robust software security would start with various other things until the financials are worked out and there is someone knowledgable to read incoming reports.

Only 7% of submitted reported to companies for a responsible disclosure program are valid. This is especially true for paid programs, where the validity percentage often drops to 3% or 4%. Loads of people who know nothing about software security try to find bugs, desperate for the gold rush of bounties they see headlining places like HN. They submit spurious reports and as a result the signal to noise ratio of responsible disclosure is fantastically bad. What this means practically is that the average organization spends between 50 and 300 hours a month investigating incoming security reports.

You can quickly see how the cost adds up here. I'm not an executive or manager trying to cut costs - I've managed bug bounties for plenty of startups and Fortune 500 companies. I've also reported bugs that loads of people tell me I could have sold for "millions" of dollars - and received nothing for it.

I love bug bounties. I run them, I participate in them. But they can be a frivolous waste of time for development teams without a solid enough grasp of security to review incoming reports, and a waste of money in the worst case.

3\. I'm sorry, but you lose credibility by claiming most security reports can be qualified in a minute or less. You can certainly _throw out_ many in a similar time frame, perhaps five minutes, but real vulnerabilities? No.

If I report a server-side request forgery in your API that requires a very specific set of actions to occur in an obscure, undocumented application function, you will not qualify this quickly. Unless you are literally verifying a CSRF issue, it is completely unrealistic to assume this.

A race condition will not be qualified in a minute. A buffer overflow will not be qualified in a minute. Budget an hour per report, and be happy when you come across the reports that take you a few minutes. XSS and CSRF are comparatively simple to verify with a _good report_ , yes, but most other classes aren't.

Let's add to this the folks who can find great vulns but write bad reports. No exploit code, but he found something real? Good luck verifying. I spoke to a fellow infosec engineer the other day and he told me he spent an entire morning out of his work day verifying a report that came in. Not patching or even triaging mind you - verifying. Most security teams do not have the olympic level efficiency and skillset diversity that Google's and Facebook's do - it is unreasonable to assume a report can or even should be verified quickly.

This is all to say that I believe your outlook is not consistent with reality, with all due respect. Bug bounties are not a simple decision to make. I've seen development teams swamped, overwhelmed and jaded from the reports they receive.

<comment><USER10> > 3\. I'm sorry, but you lose credibility by claiming most security reports > can be qualified in a minute or less. You can certainly throw out many in a > similar time frame, perhaps five minutes, but real vulnerabilities? No.

That was exactly what I was trying to convey: real vulnerabilities can easily be separated from non-issues quite quickly because the later mostly entail things which can be checked in a matter of minutes.

> You will never receive $100,000 for selling a vulnerability in PayPal. You > probably couldn't even find a buyer for it on the "black market."

$100,000 may have been slightly inflated, but with a bit of creativity it isn't that hard to believe. Orchestrated correctly one could walk away with a few million dollars from exploiting such a vulnerability.

> This is all to say that I believe your outlook is not consistent with > reality, with all due respect. Bug bounties are not a simple decision to > make. I've seen development teams swamped, overwhelmed and jaded from the > reports they receive.

Or perhaps you and I simply have experienced different realities - as I have not seen development teams swamped from them and have seen major security improvements come about as a direct result to a bug bounty program.

Of the perhaps 15-20 companies (albeit all < $1b market cap) I've spoken/worked with in regards to bug bounty programs or security in general - none of them were receiving more than a handful of reports a week which took up perhaps 2 hours of an engineer's time.

<comment><USER3> >That was exactly what I was trying to convey: real vulnerabilities can easily be separated from non-issues quite quickly because the later mostly entail things which can be checked in a matter of minutes.

What about the non-issues that are reported with complicated conditions but don't actually work? Just because you can throw out the obviously bad items doesn't mean the rest are real.

>Orchestrated correctly one could walk away with a few million dollars from exploiting such a vulnerability.

Exploiting it is rather different from selling it, though, right? And since a vuln in a website can literally be closed immediately, and PayPal's got whole divisions dedicated to preventing and undoing the damage you can do even with "account takeover", it'd be rather much a risk to pay someone cash for a vulnerability. At the first slip, the value drops to $0. Plus all the issues of verifying the bug and establishing trust for both parties. Seems rather difficult.

<comment><USER10> > What about the non-issues that are reported with complicated conditions but > don't actually work? Just because you can throw out the obviously bad items > doesn't mean the rest are real.

Yes. There will be some which don't fit into the overly simplistic categories I provided.

However in what I've seen the complicated condition requiring reports which turn out to not actually be bugs are rare enough where they aren't relevant to the discussion.

> Exploiting it is rather different from selling it, though, right? And since > a vuln in a website can literally be closed immediately, and PayPal's got > whole divisions dedicated to preventing and undoing the damage you can do > even with "account takeover", it'd be rather much a risk to pay someone cash > for a vulnerability. At the first slip, the value drops to $0. Plus all the > issues of verifying the bug and establishing trust for both parties. Seems > rather difficult.

You are hung up on what was an arbitrary example.

My point simply is if the reward for serious vulnerabilities is orders of magnitude higher if the researchers chooses the black hat instead of the white one - the overall result is a huge net negative for the world.

<comment><USER3> The arbitrary example is a good one though, because it nicely illustrates why a bug in a website just isn't worth a whole lot to sell. No matter what the issue, from a PayPal account issue to a Facebook privacy bypass, the ops teams are monitoring for this kinda thing and will shut it down quick.

Do you have first hand knowledge of selling such an exploit?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I'm a novice but would like to know how these issues can arise. What kind of backend setup is needed for it to be a problem? What is happening when a race condition occurs in these examples?

<comment><USER13> Its actually quite simple as example for the promo code the code looks like this:

1\. Code sent.

2\. Check if valid.

3\. Redeem code.

4\. Invalid code.

Now if i send 10 requests at the same time with the same code maybe 4-6 will hit the code part after 2.

And your window of opportunity is the time it takes to go from 3 to 4. Sometimes certain tasks are put inside async queue, you have a slight delay to your database server or you need to wait for db replication to kick in.

Because normally there is no code part to recheck how often this code was used.

<comment><USER14> Can this issue be prevented if we use the promo code as the table primary key or document ID?

<comment><USER15> That won't be enough because the promo codes are shared amongst many users. If the promo code became the primary key, then only one user would be able to redeem it.

If you introduced some combination of a user ID and promo code, then it won't prevent a race of one user firing many queries with different promo codes and stacking them up. It would, however, fix the original problem.

<comment><USER16> A simple Discount domain model with validations:

      Class Discount
        belongs_to :promo_code
        belongs_to :customer
        belongs_to :order

        validates_presence_of :promo_code, :customer, :order
        validates_associated :promo_code
        validates_uniqueness_of :promo_code_id, :scope => [:customer_id, :order_id]
      end

Limiting down to a single Promo-code per order:

      Class Discount
        # ...
        validates_uniqueness_of :order_id, :scope => :customer_id
      end

<comment><USER17> This right here is the heart of race condition bugs, and is NOT race condition safe. When running multiple web servers and without a "validates_uniqueness_of" constraint on your database, multiple requests hitting multiple different web servers can claim multiple discounts for the same user. Problem only grows as your number of web servers grow!

</comment></comment></comment></comment></comment></comment><comment><USER18> It would be cool if there was a browser addon that let you submit a form N times in parallel.

<comment><USER2> I do a lot of App Sec related things and I actually use mostly Chrome dev tools and command line instead of burp and other tools. The way I reproduced the bug when it was reported was by using the "Copy to curl" feature in Chrome, and then using it as follows

        for i in `seq 1 16`;do
            curl.*&               #copied from chrome dev tools. & to background
        done

<comment><USER19> Also, curl gained a --next command line option somewhat recently. It lets you send off multiple requests in the same curl invocation. These requests will all be pipelined in the same HTTP connection, which might trigger slightly different behavior in the website.

I have considered writing a program that will let me send of a bunch of HTTP requests at once, but wait to close all the connections at the exact same time. That would probably be the most effective way to trigger race conditions.

</comment></comment></comment><comment><USER20> More interesting than the bounty itself is to understand which defense works best at scale and the nitty gritty details of those kind of attacks. Intuitively I think that we just need to avoid inconsistencies between the Time of Check (TOC) and Time of Use (TOU), so veryfing the existence of a discount coupon while inserting it in one query should do the trick (INSERT INTO coupons (...) Values (...) WHERE NOT EXISTS (SELECT 1 FROM coupons WHERE (...)) instead of increasing the time between the TOC/TOU, e.g. one query to check if the coupon exists and a second one to insert the coupon. Besides it I am wondering if I am missing something, e.g. is this really a problem limited to the application layer or are the databases unable to prevent such attacks? I think I am right regarding the app protection, but let's see what people have to say :)

<comment><USER21> In many databases, your suggested "where not exists" sub query might not actually protect you but just make the possible window to hit the race much smaller. What happens is that your database would evaluate the subquery, the rest of the where, commit another transaction and then finally run the insert part of your query.

There are no guarantees in the SQL standard that queries with subqueries should be atomic.

The only truly safe way to protect yourself is to fix the schema in a way that you can make use of unique indexes. Those are guaranteed to be unique no matter what.

<comment><USER3> >only truly safe way

Or put the whole thing in a transaction, right?

<comment><USER21> Not if you don't have a unique index or put the transaction in a different mode than the default which often is "READ COMMITTED".

You could put the transaction in SERIALIZABLE mode, but that would mean that your database has a lot of additional locking to do which you might or might not want to pay the price for:

Your two-part query now block all other transactions from writing to the table(!) and conversely also has to wait until everybody else has finished their write operation.

Doing an opportunistic attempt with READ COMMITTED and reacting to the unique index violation (official SQLSTATE 23505) is probably the better option.

Resist the temptation of READ UNCOMMITED in this case because that might lead to false-positives as competing transactions might yet be aborted in the future.

</comment></comment></comment></comment><comment><USER22> So the review bug was a security issue but the username bug wasn't? I wonder what else the review bug affected.

<comment><AUTHOR> I think they did not reward me because you cannot really hurt anyone by having multiple usernames.

<comment><USER23> What about squatting on valuable ones? But probably not a big deal unless it relates to Pages.

</comment></comment></comment><comment><USER24> Can anyone comment on how the author flooded HTTP requests to the endpoint URLs? Did he use developer tools in his browser and execute his own JavaScript, or use CURL in a tight loop with the cookie and CSRF token from his browser session?

<comment><USER25> Without knowing exactly how he did it I assume this is possible by doing a POST with cURL inside a loop or with parallel.

You can then get the exact request by using Chrome developer-tools. (Find the POST-request in the network-tab, right-click and select copy as cURL)

</comment></comment><comment><USER26> I have reported the same issue with Digital Ocean (security) in November 2014, and they told me I was using the wrong address and that they forwarded it to the proper team. I triggered it by accident, using the same GitHub code twice, and I (or the DO staffer) didn't realize it was a race condition. I never heard back but they let me keep the balance :)

</comment><comment><USER27> I would be really interested to know how various forms of this bug are resolved. This seems like a problem that, on its surface, seems easy to fix, but isn't. Especially if you've designed your architecture for real-time-ness and global redundancy. Google's servers with atomic clocks come to mind...

<comment><USER28> cynical answer: I've seen alot of races get "fixed" by adding a sleep() or similar

less cynical answer: Commonly you already have some kind of means to handle races - locking, transactions, some other variety of extra check - and the fix for newly discovered races is "oh, I didn't realise that could happen. _add lock_ "

<comment><USER29> If you get three requests in at the same time, and sleep the tree for N (say, 400) miliseconds they'll all still run concurrently.

Adding a random time to sleep might work, but some requests would run noticeably slower.

<comment><USER3> Unless the code is doing read-write-read. If you're using a system that doesn't reflect writes immediately (like Elasticsearch), waiting after the writes can give time for the system to flush and make the other writes visible then you can execute rollback logic.

It'd be much better to make sure you're updating the same unique key and/or use the DB's conflict resolution system.

</comment></comment></comment></comment><comment><USER30> Now that race condition bugs have been widely exposed, I have a feeling we'll start seeing more of these "attacks" in the near future. They are relatively easy to execute and don't raise a high suspicion.

</comment><comment><USER31> Now please fix race conditions everywhere else, like Baltimore.

</comment><comment><USER32> $3k for the facebook review bug. that's a little bit too much

\- update

thanks for the downvotes guys. keep up the good work

<comment><AUTHOR> The bounty actually surprised me, too. I expected between $1000-$2000. That is one of reasons I like reporting bugs to Facebook - they pay really good, critical bugs are fixed really fast (<1 day).

One time they paid me $5000 for a bug I never could have found, but they did internally based on my low severity report. ([http://josipfranjkovic.blogspot.com/2013/11/facebook-bug- bou...](http://josipfranjkovic.blogspot.com/2013/11/facebook-bug-bounty- secondary-damage.html))

<comment><USER33> It's impressive that they are able to fix them so quickly – one needs to imagine they get a non-trivial number of reports, and that some majority of them are junk. They have a good triage + repro + escalation system.

<comment><AUTHOR> Facebook puts out stats from their bug bounty program once a year. Most of bugs are invalid reports - in 2013 they had 14,763 reports, with 687 being valid.

([https://www.fb.com/818902394790655](https://www.fb.com/818902394790655))

They probably got a couple people working exclusively on bug bounty reports. I also have to say they did a great job changing communication channels from emails to tickets which show in /support/, it is way easier now. The downside is that you must have a Facebook account, not sure if it was needed before the change.</comment></comment></comment></comment>


The Minimally-Nice Open Source Software Maintainer - <AUTHOR> http://brson.github.io/2017/04/05/minimally-nice-maintainer <comment><USER2> All excellent points. I would like to add that I personally think one word was missing in the article that being sincere. Praise needs to be sincere as well or it will be sniffed out as feigned.

</comment><comment><USER3> More discussion here: [https://news.ycombinator.com/item?id=14051106](https://news.ycombinator.com/item?id=14051106)</comment>


Ask HN: Have you ever refused to work on a project? - <AUTHOR> What happened? <comment><USER2> About a decade ago, I was offered a gig that ended up being implementation of a national firewall-- exactly like the ultra-censorship one that supposedly keeps Saudi men from seeing what girls look like, or how the rest of the world manages to function without constant brainwashing rituals.

As soon as I found out what it was, I said there wasn't a pay rate that would make it worthwhile for me. I cannot bring myself down to that level.</comment>


I took my family on the run for 19 years - <AUTHOR> http://www.bbc.co.uk/news/magazine-39849458 <comment><USER2> It sounds like this guy never committed another crime (except to keep his identity hidden), and was a productive member of society for decades. If so, then what was the point of locking him up for 5 years? Who did that help?

I think the inability to just disappear has a lot to do with increasing recidivism. If you can't wipe your record clean, and are always going to be tarnished, then why bother following the rules?

<comment><USER3> >If so, then what was the point of locking him up for 5 years? Who did that help?

If someone can get away with a huge robbery and not suffer any consequences, that completely undermines the justice system.

<comment><USER4> The purpose of the justice system shouldn't be to exact retribution — it should be to rehabilitate. It's not about consequences, it's about putting people back on the right track.

<comment><USER5> Let me guess just based on these posts (no peeking at user pages) : capncrunch is American while stouset is European.

<comment><USER6> stouset would probably have a different viewpoint if they were the victim of a robbery, while capncrunch would have a different viewpoint if they had been imprisoned or knew someone who was.

<comment><USER4> I have been the victim of a robbery. And I have a close family member who just started a 6.5 year sentence in federal prison. My current views were formed before the events leading up to this (and before the robbery).

I also recognize that arguing for political change based on n=1 sample size and personal experience is an horrible way to approach problems at a state, city, or country level.

</comment></comment></comment></comment></comment></comment><comment><USER7> Since it appears that nobody was physically injured by his theft, I really feel the stature of limitations should apply here. Nobody is better off by his extradition, imprisonment, and exile.

Nonviolent bank robbery is pretty low on the social ills scale. That opinion will annoy a lot of people, but get back to me when white-collar crime is prosecuted with the same enthusiasm. This guy is being made an example of for political reasons, nothing more. His crime is to have broken the rules that were designed to keep him in his place in the working class.

<comment><USER3> You probably wouldn't have the same opinion if your bank collapsed due to people constantly robbing it, and you lost your entire life savings.

<comment><USER7> I'm not arguing for abandoning security or crime investigation completely, am I? Please don't mischaracterize my argument.

</comment></comment></comment><comment><USER8> I wonder how difficult it would be to disappear like that today. Is it even possible in first world countries ?

<comment><USER9> The US for example has several million 'undocumented' people. That's a rather pool of people to consider something impossible.

<comment><USER10> True. However, they are not being actively pursued.

<comment><USER9> It's not enough if your 'Americas Most Wanted'. But, there are a lot of 'deadbeat' dads that are actively pursued. They often use similar methods and cash only jobs.

EX: Bike couriers are a good example of relatively high pay and often minimal documentation.

<comment><USER11> perhaps thats not disappearing though, merely hiding. I mean, being a cash in hand bike courier isn't going to set up a pension fund, is it? Old age is a long way off when you are 25, but it comes along eventually

<comment><USER12> The easiest thing to do would probably be to buy gold, which is not inflationary like money is supposed to be. Of course that's not as good as an index fund, but at least it's not cash.

You could also become a loan shark, which can be lucrative, but your illegal status would give your customers leverage against you, which is something you really don't want if this is your retirement savings...

<comment><USER7> Keeping money under the mattress is a good way to get cleaned out if anyone gets too curious about how such a person saves.

Becoming a loan shark is a possibility, I suppose, but puts someone in direct competition with professional criminals and creates a whole new set of existential and legal problems.

One low-risk strategy I've heard of being used by cash-savvy people is purchasing food stamps at a discount to their face value. Again, pretty much any kind of black market activity comes with legal risks.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> He did all that for $160,000 ???

For ten times as much I get it, but that's very little to live your entire life in an unsettled manner.

<comment><USER14> That's what makes his claim that he was pressured to do this by some gang, seem dubious. More probable is the idea that he was the one who kept the full 1.6 million.

<comment><USER15> If that were the case then were the money go? He ran out of cash pretty quick in that small Colorado town and the only extravagant purchase in the story was a $16k light aircraft.

I have to wonder how much he went "Why did I spend almost two decades looking over my shoulder for a mere 3 year jail term?"

I also have to wonder just how much he hated the fake ID guy after the millionth It joke.

<comment><USER14> He paid for the 4 bedroom house in cash, paid for the aircraft, didn't have a job for some time so house expenses. I'm guessing he bought cars, etc. Every move he made probably came with expenses. Since he had to purchase houses in cash as he wouldn't have been able to get a loan.</comment></comment></comment></comment>


Emulating a 6502 in JavaScript [video] - <AUTHOR> https://www.youtube.com/watch?v=7WuRq-Wmw5o <comment><AUTHOR> Convenient clickable link to the emulation site itself: [https://bbc.godbolt.org/](https://bbc.godbolt.org/)

</comment><comment><USER2> Thanks for bringing back so many fond memories of the Beeb. Does you mother know you're doing this?

Anyone else remember ILTDN and what it stands for?</comment>


How is the recruitment process in 2017? - <AUTHOR> I was supposed to have 4 phone interviews this week but every single one of them has been delayed. Are recruiters just busy or am I being paranoid? <comment><USER2> It could be employers still nailing down their budget? I know that there are (in Salt Lake City) fewer companies hiring at the beginning and end of the year than during other times.</comment>


Brother to replace AA & AAA with shake-to-wake batteries - <AUTHOR> http://www.geek.com/articles/gadgets/brother-to-replace-aa-aaa-with-shake-to-wake-batteries-20100716/

<comment><USER2> I have been using Eneloop rechargeable batteries in my remotes for almost a year now. It's pretty awesome. Unlike NiMH or Li-Ion, they still have ~80%+ of their life after being charged and left on a shelf for 6 months. So they are a perfect application for this type of thing.

Only downside is that they're 1.2v and don't have enough power for some applications (like my lighted & battery-powered pepper mill. It was a gift.).

The shake&wake batteries are still awesome! I would love to have them. But Eneloop is here now, and very cost-effective.

<comment><USER3> Non-rechargeable 1.5v batteries only start at 1.5v. As you use them up, the voltage drops, going down to about 1v just before the battery poops out. The curve is not linear.

These batteries are down to 1.2v around 30-50% of the way through their life.

The rechargeable batteries start around 1.2v, but their discharge curve is much more level. They stay near 1.2v right up to the end.

If a device has trouble with rechargeable batteries because of the voltage, that device is also going to have problems with non-rechargeables, as the non- rechargeables spend at least half their service life below 1.2v.

There are some good graphs showing discharge curves here: <http://www.powerstream.com/AA-tests.htm>

The rechargeable batteries can confuse battery meters on some devices, though. If the device assumes non-rechargeable batteries, and then tries to estimate remaining battery by comparing the voltage to a typical non-rechanrgeable discharge curve, and you put rechargeable batteries in, the device is going to think they are starting out at 50-80%, and then is going to think they are draining very very slowly.

<comment><USER2> It's a good point, but in practice I have found some devices won't even power on with the 1.2v batteries.

A good example being the Microsoft Bluetooth Mobile Keyboard 6000. The batteries don't last for 5 minutes even. Alkaline batteries last for months.

</comment></comment></comment><comment><USER4> Sounds well-suited for the Wii controller. It's like shake to reload in old arcade games.

<comment><USER5> I would imagine that it won't generate enough power for a Wii controller. At the very least it would be bad user experience if for some reason your ability to interact with the game occasionally dropped out because you weren't in a 'vigorous' enough part of the game.

The wii controller is constantly using (relatively) large amounts energy to measure/process/send sensor data for however long you play. A remote on the other hand is intermittently transmitting short messages. My guess is that a large amount of the energy dissipated in the remote batteries is self- discharge, which makes putting a normal battery in one a little bit of a waste.

<comment><USER4> Looking at the power consumption of the various components in the Wiimote, the only thing that really eats a lot of energy is the radio. Data is not processed on the Wiimote. Looking at the data stream coming out, the only processed data is the camera at the front, which does it super-efficiently in an ASIC/DSP. Maybe a supercapacitor or normal battery in addition to one of those could store energy from the vigorous parts and allow for unbroken interaction. Games are already designed to pause on battery low, so it would not be critical, just annoying.

<comment><USER6>
      * Loudspeaker
      * Vibration

Those 2 functions in the wiimote eat battery.

<comment><USER7> Sure, if they were in constant use, but they're used pretty sparingly. The bluetooth radio is on whenever the game hasn't been paused for a few minutes, and that dominates the power usage.

</comment></comment></comment></comment></comment><comment><USER8> If they can produce this cheaply enough and if it doesn't need too much shaking to make it work it could revolutionize children's toys. A lot of kids carry around their toys a lot in comparison to the amount of time the electrical parts are actually in use, so there should be ample charging time. Lots of toys only need their batteries replacing every six months to a year, so I assume they are fairly low drain and would suit this well.

Edit: Battery compartments that children cannot get into a also no doubt a part of the manufacturing cost, so batteries that never need replacing that can truly be built into the toy wouldn't need battery compartments and could simplify design.

</comment><comment><USER9> I had a shake-to-charge flashlight once. The movement to charge it would get you arrested for indecent exposure in the South of the US. OTOH, But it worked beautifully, and, yeah, no batteries needed.

<comment><USER10> I'm guessing these batteries are the same thing.

The shake-to-charge flashlights appear to be a long tube with a coil of wire wrapped around it at the middle, with a permanent magnet with soft bumpers able to slide up and down the tube. You can feel the bump when the magnetic field hits the coil; I'm guessing that the rest of the circuitry consists of a bridge rectifier and a capacitor. (And an LED, of course.)

Presumably in the "battery", the LED is replaced with a power supply that can boost 0.8V or whatever up to 1.5V, or reduce 2V down to 1.5V when needed.

<comment><USER11> Make your own mini shake light: <http://www.instructables.com/id/Shake-it- like-a-Tic-Tac!/>

</comment></comment></comment><comment><USER12> So this turns anything battery powered into a shake-weight?

Cultural reference point (maybe not safe for your work): [http://www.hulu.com/watch/143264/saturday-night-live- shake-w...](http://www.hulu.com/watch/143264/saturday-night-live-shake-weight- dvd)

</comment><comment><USER13> Love it, how many times have you seen someone shaking and hitting something in a vain attempt to make it work?

</comment><comment><USER14> It would be nice if remotes were solar charged, like pocket calculators.

<comment><USER15> I thought this was a terrible idea at first, because a significant portion of television viewing time is spent at night time.

However, if the cells were on the front of the remote and were good enough that they could power it based upon only the glow from the TV, that would be great. You're already pointing the remote that direction.

<comment><USER14> And it would be charging all the time, too, not just when you're using it.

</comment></comment></comment><comment><USER16> this is clever. but the question becomes how much does it need to be shaken. if its just a few shakes, cool. if its tons of shaking to change channels, people will get annoyed (remember, people are lazy as f#$k)

<comment><USER17> Hung the remote to an elastic cord, shake it, and let physics do their work.

</comment></comment><comment><USER18> We did this for one of our university design projects (back in 2007). With a rudimentary prototype we created in a couple months, we were able to charge an LED light for a second after 30 seconds of shaking the battery.

So what I'd like to know for this is the same thing, how long would I have to shake the remote to get a single button push?

<comment><USER18> Found our poster for this project: [http://sphotos.ak.fbcdn.net/hphotos-ak- ash2/hs031.ash2/34894...](http://sphotos.ak.fbcdn.net/hphotos-ak- ash2/hs031.ash2/34894_1544343691951_1335774917_1451059_3113184_n.jpg)

</comment></comment><comment><USER19> YES! I was just thinking of something like this last night for things like car-key transmitters and the like.

Lots of stuff (like remotes) sits around not being used except for a few seconds every couple of hours (or days).

Really awesome, good job, Brother.

</comment><comment><USER20> I got 2 free samples AA batteries from <http://www.USBcell.com> in 2007 during their demo (at DEMO), and I've been using them ever since to this date with my wireless Microsoft mouse. I found out that my mouse will work with just 1 AA, so while one is being used, I stick the other in the USB drive (to charge), and I just swap when the one in the mouse runs out. And it's been 3 years!!!

No shaking required.

Whenever I replace the AA from my mouse with the one I just unplugged from the USB drive, I time how fast I can "reload" <\-- used to play Time Crisis 1 and 2 obsessively back in high school :D

</comment><comment><USER21> I'm not sure how practical this will be.

The magnet in a shake-light is large, and the coil probably has at least a hundred turns of wire. A magnet and coil that can fit into a battery is going to be _much_ smaller-- and then you still have to fit in the rectifier and capacitor.

All of this in the AAA form factor? Implausible.

<comment><USER11> Not really. You can see a smaller homemade version of the shake light here: <http://www.instructables.com/id/Shake-it-like-a-Tic-Tac!/>

That could almost fit in a AAA. The capacitor or battery would be the largest part after the magnet/coil mechanism.

</comment></comment><comment><USER22> I think it will be very effective. However, the control options will be limited with a shake operation. Though, the innovative thinking needs a hats off..

</comment><comment><USER23> Tesla should put these in the shocks of their cars and they could self charge as you bounce down the road :)

</comment><comment><USER15> That sounds very useful, but what's the price? I doubt it will catch on if it is $10 per "battery".

<comment><USER24> If that battery never needs replacement I would pay even more than $10 for it.

(And assuming it has a reasonable shake/runtime ratio)

</comment></comment><comment><USER25> Is anyone else thinking that they could pair these with teenage boys with fleshlights and power the planet?</comment>


Dealing With Workaholism On Web Teams - <AUTHOR> http://www.smashingmagazine.com/2014/01/20/dealing-with-workaholism-on-web-teams/ <comment><USER2> Workaholism? Our team might have more problems with alcoholism. Oh wait, maybe it's just me on the team with the problem.</comment>


Amazon Aurora PostgreSQL Serverless - sahin-boydas https://aws.amazon.com/blogs/aws/amazon-aurora-postgresql-serverless-now-generally-available/ <comment><AUTHOR> Our experience with pg aurora was awful. I cannot recommend it to anyone. Our primary would run out of memory and fail over every few hours and all amazon support had to say is that it's a known issue.

We ended up adding even more functionality to our audit trigger package (based on a SecondQuadrant fork, [https://github.com/icheishvili/audit- trigger](https://github.com/icheishvili/audit-trigger)) to allow us to get off of aurora. AWS does a good job at locking you in.

<comment><USER2> Here's another recent report of a bad experience with a reply from the Principal Product Manager for Aurora PostgreSQL:

[https://www.reddit.com/r/aws/comments/bv70k8/aurora_postgres...](https://www.reddit.com/r/aws/comments/bv70k8/aurora_postgres_disastrous_experience/)

</comment></comment><comment><USER3> At the risk of sounding like an AWS apologist, this is really great if you have a use case for it. Don't use it if you don't.

We've been waiting to use this for our dev and test environments - the devs and testers work irregular schedules, sometimes only a few hours a day and obviously 5 days a week. We currently have manual and semi automatic start and stop switches for those environments, can get rid of all that.

Some of our systems are low volume high value - they kick into high gear once or twice a week (not necessarily on a schedule, whenever customers feel like placing and order) at which point hundreds of thousands of queries need to be run. We currently run large or extra large DB servers 24x7 at 0.01% overall utilisation because of this.

Some of the services are used only during daytime at a single timezone, but once in a while there are a few night owls.

It's perfect for use cases like this. Sure, if you compare it cost wise to a similar 24x7 instance it'll be more expensive. Sure, it takes lots of seconds at for a cold boot. Both these things are not the point. The tool is what it is, and it's clear about its shortcomings in the same way that a Gatling gun is clear that it has a non negotiable spin up time. That doesn't mean it's not useful, it needs to be matched to the work it can do effectively.

</comment><comment><USER4> Add me to the chorus of those with severe Aurora Postgres regrets. We are in the process of shutting down a very large installation of it.

I strongly discourage use of this product. It has serious problems that serverless does not fix.

<comment><USER5> Could you name some of these problems?

</comment></comment><comment><USER6> In response to some of the complaints about Aurora PostgreSQL in this thread:

Aurora PostgreSQL Serverless should be considered a different product with different performance characteristics. We've been experimenting with Aurora PostgreSQL and have encountered the same memory issues mentioned here and elsewhere. It's impossible to autoscale read replicas based on memory usage, and there's no swap for temporary spikes. We haven't yet seen those problems with Aurora PostgreSQL Serverless. There is swap, which handles spikes, and whatever automatic scaling Amazon has implemented adequately deals with increased memory usage (if you're okay with a few terminated connections). I can't comment on the index-related issues, but I do suggest considering this product separately from Aurora PostgreSQL.

<comment><AUTHOR> The index related issues themselves should be a show stopper. I couldn't believe it until I ran into other people saying the same thing, but having secondary indices on your tables slows writes down by something like an order of a magnitude.

I've yet to see an OLTP system that doesn't use secondary indices on tables. And if your workload is OLAP, there are far better relational tools.

</comment></comment><comment><USER7> The biggest roadblock to me using Aurora Serverless is cold start times. Last time I checked it was over 20 seconds.

<comment><USER8> I experienced this with Lambdas behind a VPC, and yeah it's completely crazy. This is true with the DB offerings as well?

I don't see what the use case is then. Intermittent background jobs or something?

</comment></comment><comment><USER9> Aurora Database + auto-scaling #instances = Serverless??

<comment><USER10> No, that was Aurora Autoscaling[0]. Is there an actual difference in implementation? Not sure, but there are many limitations in serverless not present with aurora auto scaling[1].

[0] [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html)

[1] [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora- serverless.html#aurora-serverless.limitations)

</comment></comment><comment><USER11> I wish it allowed to install community extensions which are not part of core software.

</comment><comment><USER12> Can anyone comment on how this compares to CitusDB? Probably is a lot more expensive?

How about things like support for PostGIS, etc? Is that moot since Aurora is mostly at the storage layer?

<comment><USER13> Citus is a fork of Postgresql and you would need to run it on it's own infrastructure.

AWS Aurora Postgresql regular flavor does support some of the popular extensions but that may not be the case with this flavor since it has some memory, image space and execution time limits that the other managed Aurora solution would not.

That said, being able to keep a pool of warm database clients at the ready for unpredictable write loads looks like it would be a winner and AWS has reliably improved to add requested features.

<comment><USER14> Citus isn't a fork any longer, it's just an extension.

</comment></comment></comment><comment><USER15> I have a basic question here. While RDS manages everything that we typically need, how is it different from the Serverless counterpart in the form of Aurora Postgres here?

</comment><comment><USER16> Curios - what's the use case for a Serverless DB?

<comment><USER17> It says it's ideal for unpredictable load or infrequent demand. My reading is that billing is done per minute only while the database is being read / written to (active), but what I'm not sure about is if the storage is completely free whilst it's inactive. If that's the case it would seem like a great solution for BI and analytics type applications where you want to collect data over time (and are able to batch writes) and produce reports relatively infrequently.

<comment><USER18> The storage is definitely not free, even while inactive.</comment></comment></comment>


U.S. Loses 533,000 Jobs in November - <AUTHOR> http://www.nytimes.com/2008/12/06/business/economy/06jobs.html?_r=1&hp <comment><USER2> Have you checked behind the sofa?</comment>


Java as we know it is over. Time to fork? - <AUTHOR> http://gregluck.com/blog/archives/2010/10/is-it-time-to-fork-java/

<comment><USER2> I've noticed a trend. When people sit around and talk about forking a project, it doesn't happen.

When someone forks a project, there's a chance it'll take off.

You can't convince someone else to fork something. If they had the drive to fork it, they wouldn't need convincing in the first place.

<comment><USER3> I was watching a video on TED the other day about this phenomenon. If you talk about your goals your brain releases the chemicals that are needed to make you feel that you have actually done something. You "feel good" about doing something even if you haven't actually done it. Having already felt good about your self you have little to no motivation to start doing it.

In contrast, if you don't talk about your goals then you really try to achieve them because you know at the end you will "feel good".

<comment><USER4> That sounds interesting, which TED talk was it?

<comment><USER5> He probably meant this talk: [http://www.ted.com/talks/lang/eng/derek_sivers_keep_your_goa...](http://www.ted.com/talks/lang/eng/derek_sivers_keep_your_goals_to_yourself.html)

<comment><USER3> yes, that's it

</comment></comment></comment></comment></comment><comment><USER6> I'm surprised that IcedTea (<http://en.wikipedia.org/wiki/Icedtea> ) has not been mentioned yet.

From the link:

"On June 2008, it was announced that IcedTea6 (as the packaged version of OpenJDK on Fedora 9) has passed the Technology Compatibility Kit tests and can claim to be a fully compatible Java 6 implementation."

I'm not a Java developer -- is there something about the project that makes it less appealing than a fork from scratch?

<comment><USER7> My personal anecdotal experience from using it on Ubuntu is that Iced Tea isn't as reliable or compatible with Java code as the Sun java. Maybe that's changed recently?

<comment><USER8> Definitely not true in my experience. The only difference I've noticed is that the Sun one forces you to manually download some jars in order to get strong crypto because of some outdated US legal BS, while openJDK bundles them.

<comment><USER9> The last time I used the openJDK on ubuntu was version 9.10 and then JGoodies LaF looked abysmal. Well, by abysmal I mean that the openJDK inserted spacing between most components and the sun JDK looked consistent with the rendering on Windows and AIX.

<comment><USER8> Hmm; I haven't done any GUI work with OpenJDK, but now that you mention it I do remember some caveats about the font rendering engine being one of the pieces that they were having difficult tracking down provenance on for open- sourcing.

</comment></comment></comment></comment></comment><comment><USER10> Wouldn't a fork be running smack into a patent suit? I confess to not understanding the Java ecosystem _at all_ , but I do know that Oracle just sued Google over their alternative Java implementation...how could a fork avoid this?

<comment><USER11> If you start with existing GPL code from Oracle, then you have an implicit patent license. But your code has to be under the GPL.

If you meet the "Technology Compatibility Kit", then you're an official Java and have a license. Unfortunately Sun was not in the habit of giving access to the TCK to people who were doing things they did not like with Java, and there is no reason to believe that Oracle will be more generous.

Google's problem was that they didn't want GPLed code (wouldn't work for the vendors who want to customize Android), and Sun wouldn't give them access to the TCK.

So anyone can create a GPLed fork, or someone who already has access to the TCK (eg IBM) can fork as long as they maintain complete compatibility with the TCK.

<comment><USER12> The GPLv2 patents provision is rather weak, and it is extremely unclear if derivate works of OpenJDK are protected.

In case you haven't realized it, Oracle's intent is to effectively kill open- source Java.

<comment><USER13> It would be extremely difficult to sue someone who for patent infringement when they were following the letter of a GPL _you_ issued. The law still involves a modicum of common sense. Stepping up to a judge and saying "yeah, I did say he could do that but I had an extra secret thing written on my shirtsleeve saying he couldn't" just doesn't wouldn't fly well however you try to reword it...

IANAL YMMV of course...

The weird system of Microsoft-Novel is closer to the way a sinister patent take-over could work, though; a third party who never GPL'd any code walks in and claims everyone owes them royalties, maybe. They then play divide and conquer, with the aid of some shills in the audience.

</comment></comment></comment></comment><comment><USER14> Oracle hasn't canceled JavaFX - they're discontinuing JavaFX _script_. JavaFX is going to live on through an API (third time's the charm for a Java UI API?).

<comment><USER15> Still, having a separate markup/scripting language for the UI layout has become an established paradigm for anyone writing apps that need to run in a browser.

side note: this action I guess has prompted the creation of "visage" <http://steveonjava.com/accouncing-visage/> as a JavaFX scripting alternative.

</comment></comment><comment><USER16> What is wrong with <http://harmony.apache.org/> ?

It is a from scratch implementation of the JVM. And is backed by IBM AFAIK.

<comment><USER17> What's wrong is that Oracle won't (ever) allow Harmony to be called Java Compatible™, even though it is.

<comment><USER16> > What's wrong is that Oracle won't (ever) allow Harmony to be called Java > Compatible, even though it is.

The same can be said of a fork. It will not be allowed to run the Java test suite (I forget the name) and certify itself Java.

Edit : Typo

</comment></comment></comment><comment><USER18> Can't we just get IBM to make J9 free & open? Last I checked, they supported more OSes than Sun did and the VM was pretty speedy too.

<comment><USER19> I wonder how encumbered it is with Oracle contractual restrictions? Didn't IBM at one point license Sun code to build its own version of the JVM?

<comment><USER16> Much of high performance modern VMs (not just JVM) are built on Self project and StrongTalk acquisiotion by Sun. I think Oracle would have quite a few key patents due to this.

Though the Visual works contribution to VM technology cannot be discounted. And it is owned by IBM. So probably IBM and Oracle will not use these patents against each other.

<comment><USER16> The excellent research done under Jikes project in IBM cannot be forgotten. It to contributed to IBM's patent portofolio.

Bad to reply to own comment, but can't edit it anymore.

</comment></comment></comment></comment><comment><USER20> The only part of this that makes me think that a fork will have to happen is the fact that IBM, HP, Google, RedHat, etc… have _got_ to be more than a little uncomfortable with Oracle in the driver's seat.

</comment><comment><USER21> It seems the Lava name has already been taken: <http://en.wikipedia.org/wiki/Lava_%28programming_language%29>

<comment><USER22> Lava = Libre Java?

</comment></comment><comment><USER23> Time to fork? Yes.

Practical to fork? I hope so, but the pessimist in me doubts it.

</comment><comment><USER24> Why fork? Just go with Scala! <http://www.scala-lang.org/>

<comment><USER25> Why the downvotes? That's a perfectly reasonable suggestion.

Java is attractive because it's mostly sane, and it's backed by The Enterprise in a big way. Sure, if Google, RedHat, HP and IBM gets behind a fork, it could work - but I can't really see what RH and HP has to gain there. They both need to keep support for Oracle Java to stay relevant. IBMs primary interest in Java is consulting - and the consulting-money going to stay with Oracle Java. Google has a lot of stuff in Java, but they're by no means married to it, except for Android/Dalvik. I'd bet they're more keen to push something like Go (or even Scala for that matter).

But without the enterprise backing, Java is just a pretty dated language. Scala, on the other hand, is a very modern language by most measures, _and it will integrate seamlessly with your Java legacy stuff_.

Sure, it doesn't solve the problem of depending on the JVM, but if Oracle kills Dalvik, getting a good open source drop-in replacement to the JVM is not going to happen. If not, well, then we have Dalvik :)

<comment><USER26> Depending on the JVM is a bigger issue than you suggest. Without an unencumbered open source JVM, any languages which rely on the JVM will ultimately be dependent on Oracle. Bugs can't get fixed, new platforms can't be ported to, improvements to the VM can't be added.

Jumping to Scala or any other language is just ignoring the more fundamental issues that have _always_ made a proper open source JVM important, regardless of Java's corporate owner.

</comment></comment></comment><comment><USER27> Apache Harmony is something to look at, although of course the Oracle/Android patent suit seems like it might have implications for Harmony.

</comment><comment><USER28> I doubt that even the best quality fork can compete with Oracles sales machine, no matter how badly they ruin Java. Even if all the great and passionate Java developers leave to become Python programmers, Java will still be the most common language out there.

<comment><USER29> On top of that Java has the brand.

Programmers may not feel positive about it but it's embedded in a lot of large organisations, many of whom will, at the management level, be perfectly happy with the Oracle acquisition. They won't see the need or the appeal to move to something else until there is a strong incentive to do so.

Against that sort of entrenchment programmers will struggle to influence things a whole load in a lot of Java's key markets.

<comment><USER30> Users have little obligation with respect to the Java trademark. My organization can use the word "Java" internally to remind our execs that we're doing the safe, boring thing, and there's no problem if we actually deploy Lava or Fava or Cava (my pick) to our servers. As long as we don't publicly advertise that our services rely on Java technology (and who does that anymore?) we're free to call anything Java internally.

If Oracle targets an "OMG Don't Get Caught Using Fake Low-Quality Java" marketing campaign at our upper management, we'll talk to management ourselves and paint Oracle as losers who lost their grasp on everything but the trademark and no longer offer the premier, industry-standard implementation that we require.

<comment><USER31> Oracle doesn't do marketing like that.

Oracle doesn't care what you do, unless you are in their target market: enterprise software.

If you are, then no amount of talking to management will trump the potential of their talk with management: "Sorry, you are using an unsupported configuration. Your 500K support contract is now void, you will no longer receive critical updates and your licence will expire at the end of the month. Good luck getting your data out before then. Oh, BTW, if you keep your database running after the licence is expired then we'll sue you"

You'll never win taking Oracle on head on like that.

OTOH, they are very vulnerable to _new_ applications that just happen to be written in Cava on a JVM-derived virtual machine.

</comment></comment></comment></comment><comment><USER32> Using the name Lava would surely get you sued. Only one char difference. The trademark holder would be all over that. NcDonalds can't sell BigNacs and get away with doing so.

</comment><comment><USER33> What about: let Java die and let something better take its place?... But it's true I live in an alternate reality.

</comment><comment><USER34> The author forgot that java is already forked and supported by many JCP members..

The project is called Harmony an dis under the Apache banner supported by such JCP members as IBM and many OHA members as well.

Given Oracle's planned moves they will end up killing java on Mobile except for Android and Java on enterprise except for the open source stacks that support Harmony's use..

Also note that the harmony project does use off-shoots of the JVM research IBM invested in as well..

</comment><comment><USER35> Too bad, Minecraft just made me respect java a little bit!</comment>


New research finds some buckyballs can hold incredibly dense volumes of hydrogen - <AUTHOR> http://www.eurekalert.org/pub_releases/2008-03/ru-tbs032008.php <comment><USER2> Cool. Fusion pellets.</comment>


Advanced TypeScript type FTW - <AUTHOR> https://blog.pulumi.com/advanced-typescript-type-ftw <comment><USER2> yes, we really like conditional typing as well. We do not use it everywhere, but for when it is needed, it is very powerful.

Just one thing that could be better outlined in the TS doc, is that conditional typing is for declaration and not for the signature of the method being implemented. It seems obvious once we know it, but can be confusing at first.</comment>