Hacker Newsnew | comments | show | ask | jobs | submit | vsl's comments login

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


10-15 years ago, there weren't that many other options.


That you misremember it or are too young to know better doesn't mean that it "is simply untrue". It's not, it was valuable for many years. It's your revisionist history that is simply untrue.


It's not revisionist, I'm 40 years old and have been consuming and participating in OSS since before SF existed. It was painful to use, even in the context of the times. Granted, there wasn't really any alternatives in the first few years of its existence.


> Also, is rent control even a good idea?

Let me put it this way: the rents dropped sharply when rent regulation finally ended in my country. After 15 years of doomsayer horror stories from the left how unregulated rents would make the poor homeless, it turned out, within a year, that the exact opposite was happening.


> clearly a violation of the GPL.

It’s not clear, this really is an interesting case. From the description in the comments here, it seems that the GPL code from Linux, together with the code to interface with vmkernel is published, complying with GPL for that part.

My guess is that VMware considers vmkernel to be the operating system (which it is, albeit a minimalistic one, just the barebones hypervisor) and regard it as GPL code from Linux linking with the glue layer and the vmkernel system library. Which, if it provides some generic interface that the glue uses, arguably is.

And that - GPL code linking with proprietary system library - is an explicitly permitted exception in GPL: http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryExcept...

I am just guessing here, but seen like this, VMware’s position makes sense. I would be surprised if they all-out violated GPL, Linksys-style, to be honest, because some competent FLOSS folks work(ed) there.


Correlation does not imply causation.


Sounds like it’s more like "Happy to answer _some_ questions”...



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