Hacker News new | comments | show | ask | jobs | submit | vsl's comments login

Not what the parent said, true, but you can test for this easily: launch the app, see if it terminates with exit code 173 (receipt check fail) in the first few seconds if fed SHA-2 receipt but not the old SHA-1 one. Won't catch all (apps may validate later during runtime), will catch enough to give you some idea about the scope.

Nope, this really is well known. It doesn't happen to everyone, but it happens to lots of Czechs and Poles in Bavaria. To the point of causing diplomatic incidents on occasions.


That so? I'm Czech and Bavarian police is famous here, for years, for targeting Czech cars and bullying the passengers (stops without probable cause, extensive searches under false pretenses, picking all CZ, and only CZ, cars from traffic, the list goes on). "Respectful" is not a word we associate with German cops here.


No, not really. Military planes were shot down, yes, but those operated at much lower altitudes. It's damn hard to shoot down an aircraft flying at 10k feet, you need something like BUK to even be able to reach that high. That's why these fly levels are generally consider safe even over (low-tech) conflict areas; this isn't limited to UK.

More readily available AA weapontry is only good against low-flying targets and it was thought at the time that the "rebels" did not have high-end military equipment from Russia. That's an intelligence failure, granted, but not irresponsibility by the airline.


Sorry, but that's nonsense. Cycles don't just magically appear, you write them.

So writing refcounting code simply means being aware of this when designing the more complicated data structures in your code to use weak backreferences.

File objects are not secretly stashed in complicated graphs to prevent their destruction and you very much can rely on their behavior. GC passes to clean up cycles is something you got confused about: that's what GC does (because unrooted cycles are very much an issue there too!), not refcounting where you always have to break the cycles yourself, manually, preferably when designing the data structures.


> Cycles don't just magically appear, you write them.

That's like saying memory leaks doesn't magically appear, you write them. In real code, ref cycles are everywhere and it is not trivial to know beforehand what code will generate cycles. And don't give the spiel about how that's only something that affects bad programmers.


All modern Objective-C codebases and a high percentage of large C++ codebases use refcounting without a cycle collector. Some of them have memory leaks, and there are some quite ugly cases like [1], but most of them have it under control. So it's not like relying on pure refcounting is impractical in the real world; it's just a bit more difficult to deal with than full GC.

[1] http://albertodebortoli.github.io/blog/2013/08/03/objective-...


That's rich. GTK+ doesn't pretend to be seriously cross-platform. Qt does but looks horrible on anything but KDE. It tries to mimic native UI but enters the uncanny valley and is immediately noticeable as a fake. Particularly horrid on OS X.

Don't lecture us on a technical choice you don't understand.


It doesn't. Bitcode is arch specific and unportable. It allows some instruction-set level optimizations, but not changing e.g. endianness (exactly what x64 and arm differ in) or type sizes.


ARM cores, although technically bi-endian, are in practice little-endian.

I play writing LLVM backends, and its entirely viable to even do things like rewrite float80 and other assumptions that a front-end has made for a particular target.


But what about things like non-aligned memory access (allowed on x86, not allowed on ARM)? Porting code across architectures can't be as easy as just swapping LLVM backends, when not even recompiling the code is sufficient.


Modern ARMs are just fine with unaligned access.

There will be ISAs sufficiently different that you cannot make bitcode generated when targetting one not be massaged to fit another, but they are not mainstream. The mainstream are all increasingly similar 64-bit targets.


Did you consider the possibility that it's a technical limit that they didn't even anticipate ever hitting in real life, because Slack is for small teams?

Let's be fair here: the 10k visible messages limit means that Slack is basically unusable when you hit the user limit, as this post also says (messages archived within minutes of appearing). The pricing is clearly insane with this amount of users too.


The impossible-to-miss headline says "small teams". I interpret the more detailed description in that context: no arbitrary limit on small team members. No sane person would argue that 500+ is small team.

The limit in place seems like a technical limitation to me: Slack is for teams, so they figured the number is well above any real-life use and probably applies to paid accounts as well.


> The impossible-to-miss headline says "small teams".

Actually when you go to slack.com the first thing you see is:

"Slack is a platform for team communication:..."


"Slack is free to use for as long as you want and with an unlimited number of people."

With 2 textboxes for me to sign up for the service. Nothing to suggest that slack is for "small teams" only.

> The limit in place seems like a technical limitation to me:

I don't think you'll get any argument from me - there are only a finite number of CPU cycles, RAM, bandwidth, and hard drive space. But - they should have designed to be a scalable service where all they have to do is spin up some VMs or dedicated systems to increase captivity. Yes - this costs money, but when you offer a free unlimited service - I feel like that's the cost of doing business.

> no arbitrary limit on small team members. No sane person would argue that 500+ is small team.

They need to clearly define what small team means in their terms of service. The carriers were slapped for the "unlimited is not really unlimited"

This is what I found in their TOS:

"The total number of users is limited to the maximum number permitted for your account."

Which is what exactly? What is the limit for free vs paid?


They seem to be more robust, but boost::future::then() has weird design that makes it all but useless for real-life use. They return the same kind of future that std::async() does, i.e. its destructor blocks until the future is ready. In other words, you can't write "fire and forget" code:

    void run_and_report()
       .then([=]{ report_results() });
    } // blocks here until the then() block executes



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact