Scientists discover what powers celestial phenomenon STEVE - <AUTHOR> https://phys.org/news/2019-04-scientists-powers-celestial-phenomenon-steve.html <comment><USER2> The only sentence in the entire article that is actually about STEVE, doesn't really explain how it's different from a regular aurora.

</comment><comment><USER3> Possibly the greatest headline in the history of astronomy.

</comment><comment><USER4> Is this a new phenomina or has it occured before?

<comment><USER5> The article spends a fair amount of time answering just that question.

<comment><USER6> The question's answer is approached but not quite reached with vague words about sensitive cameras. The article does not explicitly say that the phenomenon even is or isn't visible to the naked eye. The wikipedia article [1] suggests that the phenomenon was 'discovered' in 2016. But that leaves a little room for the possibility that it was occasionally noticed before then but not rigorously observed with photographs, witnessed notes, and the like, to document the sightings.

[1] [https://en.wikipedia.org/wiki/Steve_(atmospheric_phenomenon)](https://en.wikipedia.org/wiki/Steve_\(atmospheric_phenomenon\))

<comment><USER5> "The phenomenon is not rare, but nobody had looked into it in detail prior to that."

Hmm, you're right. What you are reading between the lines is _apparently_ correct. Both the article and the wikipedia entry seem to actively avoid stating things in definite terms on that detail.

The first article I read about it said that the "discoverers" knew about it for some time, and it wasn't until they tried googling it that they realized it didn't have a name.

My sister, who by coincidence lives just outside Calgary (where Steve was "discovered") tells me that she's known about it since she was a child and just assumed it was part of the Northern Lights. But... that's anecdotal and doesn't make up for the recent articles focusing on the newer discovery as to its cause.

It is naked-eye visible as long as your light pollution is such that you can see Aurorae when they happen.

The other part that was recently discovered is that it can be seen as far central as the equator. Can _that_ be seen by the naked eye? I think that might not be stated so clearly either.

I have also not heard if the south presents the same or similar phenomenon.</comment></comment></comment></comment>


Detailed Breakdown of a Clojure Web App - <AUTHOR> http://www.flyingmachinestudios.com/programming/dissecting-gratefulplace/

<comment><USER2> I have a couple of suggestions.

1\. If you return a handler function from a Compojure route, the handler is evaluated with the request. So:

        (GET "/" request (posts/all request))

Is the same as:

        (GET "/" [] posts/all)

So there's no need for a separate "route" macro.

However, passing the full request map is discouraged, because the more information you give a function, the more things can theoretically affect it. Functions should be limited in what they know and what they can do, and this is one of the principles Compojure is designed around.

2\. Some of the macros you've written for Korma could be written as functions instead. For example:

        (defn paginate [query page per-page]
          (-> query (limit per-page) (offset (dec page))))

        (post/all (where conditions) (paginate page per-page))

<comment><AUTHOR> Thank you! And thank you for making such great libraries available.

For #1, I definitely started by not passing the full request map but I ended up finding it cumbersome. On the other hand, my code doesn't really need the full request map. I'll have another go at it and see how I can improve things - thanks for the guidance. It feels like a process of over-contraction, then over-expansion. Hopefully I'll find a happy medium.

For #2 - thank you! I was trying to work toward something like but couldn't quite get there, so this is great.

<comment><USER2> Could you give me an example of a route that was particularly messy if you didn't pass the full request map? Maybe I can suggest a better option (or at least admit defeat :)

<comment><AUTHOR> You know, I actually can't think of any. I just ended up writing things the way I did because I anticipated I would want the full request map, but that assumption hasn't born out. Passing params might be a good way to go. I need to go back and change this!

</comment></comment></comment></comment><comment><USER3> This is a pretty interesting post, but I'm seeing a common thread in most "experience reports" regarding making a webapp in Clojure.

They're all built with with the presumption that the person doing the frontend work (HTML, CSS, JS) will also be doing the backend (Clojure, database) coding.

This is almost never the case in my line of work.

Hiccup violates this principle by embedding the html _in my Clojure_ and Enlive couples markup with data tightly in ways that horrify me.

The only approach I've seen that could work for more serious projects is using stencil because then the map of data you pass to the template-side is a 'contract' of sorts, but they can work with the data you pass however it works for them.

That's somewhat regrettable as I prefer Jinja-style templating to mustache, but Stencil (mustache) is the only viable alternative I've found.

I cannot possibly be the only person with a keen interest in Clojure who hasn't abandoned division of labor.

<comment><USER4> Based on my experience, Hiccup is more productive than just about anything else _if_ the frontend person is the backend person or otherwise comfortable with Clojure. The ability to easily and cleanly define and combine abstractions in the presentation layer has been big productivity boost for me as a solo developer.

As a concrete example, a small hobby project I did resulted in a fairly comprehensive library of Bootstrap helpers with very little effort:

* <https://github.com/asmala/giddyup>

I don't have much experience with Enlive but I find the approach is intriguing. On paper it seems perfect for clean separation of markup and logic, but you're right that careless use of the library leads to tight coupling due to the selector naming. I wonder if it would be possible to circumvent this issue using custom HTML attributes or even pseudo-CFML custom tags to indicate logical units in HTML?

<comment> cgrand-net Enlive's author here. I prefer to think of templates as a mapping between data and presentation. When the HTML provided by the designers changes drastically you only need to update selectors in your templates and be done with it. The same is true of the data you pass to templates: when the schema change you have to change the template. A template is both a contract on some properties of the input HTML provided by the designer and on the input data provided by the logic layer.

<comment><USER4> Gotcha. How would you handle minor HTML changes, e.g. something like this:

      joe

      joe

Updating the selector in the template is easy enough but seems a bit tedious if the design team decides to go for italics next week. Another option would be adding another CSS class or a data attribute to indicate which element should wrap username.

How do you usually handle such scenarios?

<comment> cgrand-net By doing such a change they violates their contract. Can't you negotiate an alternative change? Eg the strong around the span or using styles instead of strong or move the username class to the strong tag?

Anyway if you really want to program defensively against such changes, roll your own replacement to content fn which would replace the cornets not of the current node but of all its terminal descendants.

I'd like to know more about your workflow.

<comment><USER4> My example above was possibly too simplistic. I'm not using Enlive at the moment but am merely trying to gauge what kinds of contracts would allow the developers and designers work together most efficiently. I can imagine a fairly big difference between, for example, the following two contracts:

a) "Don't touch the markup without an explicit agreement between the two of us."

b) "Please make sure you have an element with a data-content- for='user.username' somewhere in the HTML."

<comment> cgrand-net More often than not it's a variation of b) not involving custom attrs (a matter of taste). It's the same kind of contracts you have to set up if you are also doing some heavy JS anyway.

Sometimes the design is forced upon the team (eg corporate intranet) and then one has to resort to ugly and brittle selectors but still I prefer that to slicing and dicing the design to add loops and conditionals – especially when the intranet's corporate branding change every 9 months :-/

(Thanks for rewording your reply)

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I have used Enlive and I still prefer traditional erb style templates. I actually use Slim(slim > haml) or Haml, but they are just syntactic sugar.

Enlive, on one hand, allows designers to work on html which doesn't need any data binding, and then process the plain html. On the other hand, it's tightly coupled with the markup. A designer can't be sure that changing a class name or restructuring the markup won't break the templates.

Rolling your own validations might be fun, or it isn't something I want to do when I am working on a project. I might have rolled out validations from last project which I can re-use, but I still prefer AR or WTForm validation over rolling my own(takes time, and if I am in a hurry, ends up not being generic enough to use in another project). Same goes for pagination. Need pagination? Here,

        # Add kaminari https://github.com/amatsuda/kaminari

        class UsersController
          def index
            @users = User.order(:name).page params[:page]
          end
        end

        # index.html.slim
        = paginate @users

Done.

Clojure is a pleasant, expressive and innovative language, but as the blog post pointed out, the ecosystem isn't vibrant enough yet.

<comment><USER4> Coming from Rails, I tend to agree that the Clojure ecosystem is still less mature, but not by as much as I initially thought.

Missing Rails I18n, SimpleForm, or validations? Clojure has you covered:

* <https://github.com/ptaoussanis/tower>

* <https://github.com/asmala/clj-simple-form>

* <http://clojurevalidations.info/>

Need more specialized libraries? Take a look at ClojureWerkz:

* <http://clojurewerkz.org/>

Having tried hard to understand the rather labyrinthine source of the original SimpleForm library, I was astonished by how easy Clojure made writing a similar library, clj-simple-form. The key contributing factors were Clojure's emphasis on simple data structures and powerful functions as opposed to classes, and the ability to pass around functions just like any other objects. For a lot of projects, I find ease of extensibility to be more important than ready libraries.

<comment><USER6> Clojure does make difficult things easy. And it's getting better and better with the rapid evolution of new libraries and middleware.

Given one of the core differences in approach, composibility for Clojure and 'convention over configuration' for RoR - I don't think there will ever be a monolithic RoR equivalent in Clojure. Instead the micro-frameworks that are emerging are finding their niches, and are being designed from the ground up to work with other micro-frameworks. Working in tandem these compositions of micro-frameworks are quickly getting mature and I'm sure will be in the same league as RoR soon enough.

What I like about this is it allows you to handle Clojure a micro-framework or middleware at a time. It's easier to digest this way, at least for me: Ring -> Compojure -> Hiccup - Enlive/Comb/Fleet [x] -> Korma -> Friend, followed by Domina, Enfocus and others on the ClojureScript side.

[x]: marks where I am.

<comment><USER6> I forgot to add to [x]: noir, lein-cljsbuild and clojurescript one; and to the ClojureScript side: jayq, fetch, waltz and crate.</comment></comment></comment></comment>


Mary Meeker's 2013 Internet trends: all the slides plus highlights - <AUTHOR> http://qz.com/88980/mary-meekers-2013-internet-trends-all-the-slides-plus-highlights/

<comment><USER2> "Most Enabled Entrepreneurs Ever?"

Most definitely. At the same time I wonder if alpha personalities were more enabled before regulation and competition were everywhere.

Anyway, I'd like to hear the talk on this portion. The slides are okay but its an interesting discussion and nothing was really said about the implications (except for some examples of people who, because of passion + being enabled, were extremely successful).</comment>


Ask HN: Crowdsourcing your health - <AUTHOR>

In BusinessWeek, they mentioned a company called ExpertConsensus which for a $20k+ fee collects your medical data, organizes a panel of experts, and advises your primary physician on alternative (I guess better?) treatments.
As tech savy people, would you be comfortable (in the distant future) using a cut-rate start-up version of such a service?
I'm thinking that as the price of medical tests drop (23andMe, etc.), the potential for a service to create a cheap network of retired/low-wage/part-time doctors would increase.  Ultimately though is this an instance where people have a very firm image of price ( as mentioned in Don't Roll the Dice ) and if you price too low, you'll lose consumer confidence? <comment><AUTHOR> clickable (not paywalled): [http://www.businessweek.com/magazine/content/10_38/b41950224...](http://www.businessweek.com/magazine/content/10_38/b4195022450592.htm)</comment>


iFixit App Pulled from Apple's Store - <AUTHOR> http://ifixit.org/blog/7401/ifixit-app-pulled/ <comment><USER2> The hypocrisy at the end of the article is astounding: "Right now, we're not planning on it. [rebuilding their app]. Our APIs make it easy for anyone else to build one, though. (Our old app is open source if you'd like an example to build upon. Just respect our license and don't put ads in it.)"

They blatantly violated the agreement for obtaining the pre-release hardware, and then expect people to honor their own license terms?

IMHO, they are extremely lucky the worst thing that happened was their developer account getting pulled.

[Edited for clarity after feedback]

<comment><USER3> It would be hypocrisy if they re-created a copycat apple tv and sold it or distributed it with ads. They didn't do anything like that.

Also, they likely violate EULAs (the A is for agreement) for non-pre-release hardware all the time. Not that big a difference.

<comment><USER4> Why isn't it hypocrisy to expect others to respect license agreements yet blatantly violate them themselves for publicity? Yes, the terms aren't the same, but, so?

<comment><USER3> I would compare the apple hardware agreement they violated to software agreements which forbid analysis, reverse engineering, or even benchmarking (there's some notable enterprisey software which forbids conducting benchmarks and sharing the results).

I would not condone redistributing copies of software or significant portions thereof in a way which violates the license, whether it be a copyleft license or a commercial license. If apple distributed gerber files for the PCB of the new hardware device, or original CAD schematics it uses to manufacture parts, under some license, I'd also want the terms of the distribution of that to be respected.

But this is something of a different nature. It's taking hardware apart and seeing what's inside and sharing that researched information rather freely on the internet. This is not a copy of source code or hardware schematic. This is learned information. It's not vandalism - there is no expectation that any dev kits be returned, each recipient can use theirs exclusively. This is something everyone everywhere should always have the right to do. And iFixit does, more or less.

What sucks is that Apple can retaliate by exerting their complete and arbitrary control over what software millions of people are permitted to run on their own devices. That's really messed up. This is just one more great example, in case you don't understand yet.

<comment><USER5> It's not about them reviewing the device. It's about them reviewing the device and publish it before the product actually hits the market.

Apple didn't have problem with them tearing down other Apple devices.

And iFixit got the device because the sign the agreement not to publish the information before it hit the market.

It's not about reverse engineering knowledge. It's about breaking the agreement, which is what iFixit is asking others not to do when using their API.

</comment></comment></comment></comment></comment><comment><USER6> I support iFixit in their quest to get useful information about hardware to the masses. If you own a device, why shouldn't you be able to disassemble and repair it yourself? And why shouldn't we be able to know what's inside that device?

But releasing a teardown of the new Apple TV (and breaking NDA while doing so) is not doing that since, critically, _the device is not available for purchase yet_. I feel like this move is hiding behind "technology wants to be free and open" while actually making a grab for clicks and views.

You're not a martyr for the cause of freedom in this case. Nobody was attacking you. Apple was holding the sword and you fell on it. Had you just waited until the device was released, it would be a different story.

iFixit are making it really hard to be on their side.

<comment><USER7> Yeah, I hope this doesn't damage whatever relationship iFixit may have with Apple, or in any other way inhibit the flow of information and resources for consumers to understand and fix their own devices.

<comment><USER8> I highly doubt they've ever had a relationship with Apple. I don't think they've ever gotten a prerelease iPhone - they just send someone to Australia where they launch first and do the teardown before they go on sale 12 hours later in the US.

</comment></comment></comment><comment><USER9> > The developer unit we disassembled was sent to us by Apple. Evidently, they > didn't intend for us to take it apart.

They won an Apple TV in a prerelease developer lottery, rather than being sent a demo unit by Apple like they do with the press.

> Unfortunately, iFixit's app was tied to that same account, so Apple pulled > the app as well.

This doesn't seem like a coincidence: _because_ they are iOS developers, they were able to receive an Apple TV unit.

<comment><USER10> Yes, I believe the Apple TV dev units had an accompanying NDA. (I registered, but didn't get lucky; I can't recall the exact terms)

<comment><USER11> Apple made it quite clear that the whole thing was under NDA and you were not to talk about it under any circumstances. This was mentioned repeatedly throughout the process.

I'm no fan of Apple's App Store policies, but this one is entirely iFixit's fault.

<comment><USER12> > I'm no fan of Apple's App Store policies, but this one is entirely iFixit's > fault.

Not necessarily. It's not clear that Apple's rules were reasonable. If the dev unit is identical to the production ones then an NDA is unreasonable unless it was only under NDA until an embargo.

<comment><USER13> If you think the NDA is unreasonable, don't agree to it and don't take possession of the hardware.

If you do accept it and violate it, be prepared for consequences.

<comment><USER14> How about take possession and then ignore? The world isn't isn't so black and white.

<comment><USER15> Well, that's what they did. It's called lying (or in legalese, violation of contract) and the repercussions are that their relationship with Apple is damaged.

This might well be the last pre-release thing they ever receive from Apple. So, sure, things aren't black and white, but they didn't exactly leave room for Apple to respond positively, especially given Apple's rather well known positions on leaked information.

<comment><USER14> I love how a bunch of nerds get super upset over iFixit doing a teardown on prerelease hardware (lying, violation of contract (shrink wrap at that)). So much easier than getting upset about things that matter. I'd say it ranks about as high as jaywalking.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> The tone I get from this post is that they knew there would be consequences to their actions and that they are apologizing that there users ended up being impacted. There is nothing in here saying "Apply totally screwed us, bring down the evil overlords."

I think this was really well written and had exactly the right tone. Please read past the first paragraph if you want to criticize.

<comment><USER17> What I take from this post is that they were ready to move away from their own mobile app anyway (like almost every other publisher who built an app over the past 5 years), and figured this would be an interesting and fun (and attention-generating) way to do so.

We can't see it in the App Store anymore, but how many downloads did the iFixit mobile app have? How many active users? What did it do that a mobile website did not? As they admit, not really anything.

But they're in good company there. There are a lot of content publisher apps still limping along in the App Store, despite delivering little value to their publishers.

Generally speaking, content apps lost and connecting apps won. Everyone just reads their content in their social network or aggregator now. NY Times has to inject their content into Facebook to grab mobile mindshare, even though they have had their own NY Times mobile app for years.

</comment></comment><comment><USER18> Another victory for the mobile-web over a native app that didn't need to exist.

<comment><USER19> It also neatly solved iFixit's problem of having an app out there that they had abandoned and was giving users a defective experience. Pulling your own app from the store will make someone angry at you. Having Apple pull it is about ideal.

They could spend $100 for a new apple id, fix up the code enough to pass muster, and get it back in the store if they wanted, but like they say in the post, the mobile web is fine for what their app did and they don't want to spend any money on the app.

Tangential, it would be nice if Apple left a tombstone for vanished apps. If I read somewhere to get the iFixit app, I'd go to the store now and download an app named "iFixit!" which is apparently some random collection of manuals.

<comment><USER20> > They could spend $100 for a new apple id...

That's $100/year, every year, right? Apple hasn't yet made their iDeveloper (or whatever) fees non-recurring, right?

<comment><USER21> Free apps remain in the store even after your developer membership has expired.

<comment><USER20> Are you _sure_? JWZ reports otherwise: [https://www.jwz.org/blog/2012/06/dali- clock-back-in-the-app-...](https://www.jwz.org/blog/2012/06/dali-clock-back- in-the-app-store/) (check 'graph 3)

Did that policy change in the intervening time? If it did, would you provide a reliable citation? :)

<comment><USER21> 10 months ago I accidentally let my membership lapse, and I am pretty sure that only the paid apps were pulled. If I am not paying attention in January maybe I will test it again to confirm this winter.

</comment></comment></comment></comment></comment></comment><comment><USER22> I would say the title is misleading. Their developer account was cancelled because they violated the NDA. Apple didn't "pull the app", the app becoming unavailable is just a side effect of the dev account being cancelled.

iFixit could get the app back in the store in a few days by signing up for a new dev account. But they don't want to do that because, as they say, the app is buggy and they want to focus on the mobile site anyway.

So, the title is clickbait. Apple didn't censor the iFixit app. But no one would read an article titled "Apple terminates developer account after contract violation".

</comment><comment><USER23> iFixit, I love what you do, so please don't compromise your integrity by breaking license agreements that companies try to get you into. You have the power to refuse those agreements and post them for the world to see. If you find yourself breaking them, please don't post blog posts with witty remarks and ask that people abide by your own licenses.

Your mission is so important. You have gone so far in holding companies accountable for e-waste and sustainability of their products. Please don't screw it up with stupid mistakes like this.

</comment><comment><USER24> I like how they played it off by playing up their mobile site, and then reminding us that their API is available to anyone who would make an app.

</comment><comment><USER25> iFixit is surprised their actions have consequences. I mean really you tore apart a developer unit so you can get page hits and now want to complain?

<comment><USER26> This post didn't sound surprised or like a complaint to me. I think they new very well what they were getting into and handled it quite well.

<comment><USER10> I would agree. It didn't have the crying and crisis and conspiracy tone that usually accompanies these posts. They knew what they were doing, and the tone was "it was totally worth it". Kudos to them for putting their grown-up pants on.

<comment><USER11> I don't know that I'd call it "putting their grown-up pants on" to receive free hardware in exchange for an agreement not to talk about that hardware, then publish a teardown of that hardware anyway. Keeping your promises counts for something too.

<comment><USER10> No, I'd agree that's a bit ethically questionable. I guess I'm so used to developers acting like entitled children that when someone doesn't take that approach, it's a breath of fresh air (though in a way it's kinda like an honest politician, it's a bit sad when what should be the baseline becomes extraordinary)

<comment><USER11> Maybe you're thinking of something else, but in my experience when people talk about developers "acting like entitled children" it's because those developers got screwed over by Apple for no good reason, exhausted every internal avenue for redress, and decided to take their grievance public. (Been there, done that.)

At least it's a breath of fresh air to see Apple smacking somebody down for an actual, legitimate violation, instead of the usual imagined nonsense they do.

<comment><USER10> I'm not speaking of Apple specifically; I'm referring to examples where someone blatantly knew of the risk they were taking (think violating NDA, using copyrighted content, or basing their business entirely on someone else's content) and then crying conspiracy when the rug was pulled out from underneath them. (the app store situation you described obviously being a different kind of situation)

<comment><USER11> Gotcha, and I agree with your assessment on those. I've seen a lot of pro- Apple arguments characterizing developers with IMO legitimate gripes as "whiny" and that's immediately what I thought of here, but glad to be wrong in this case.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> [Off topic, curious bit in the original teardown:]

 _" We noticed a distinct lack of cables connecting the power supply to the logic board. We're theorizing the power is either transmitted by magic, or through the heat sink screw posts."_

</comment><comment><USER28> I love this story. iFixit knowingly violates a messed up TOS, and the only outcome that happens is their app is taken down, which results in free press.

Even if you call the TOS an NDA (which iFixit didn't post, which is kind of annoying), you do have to wonder, what did Apple expect to happen? iFixit has been publishing teardowns and helping people repair Apple products for close to a decade.

</comment><comment><USER29> If you have a mobile web-app, make sure users can use it while offline!

</comment><comment><USER30> Wow. This is how you write an announcement delivering bad news with class. They are unapologetic for exercising their right to tinker, but feel no need to whine about Apple's response.

<comment><USER31> I would have to disagree. They broke an NDA by tearing down and publishing the internals of a device not available for public purchase. I don't they they had a legal 'right to tinker' with the developer unit they received. It'd be a lot different if they bought an already released device from a store and did the same thing. With that being said, their response just sounds like they're trying to save face after screwing up.

<comment><USER30> You convinced me. This isn't like taking apart your car.

</comment></comment></comment><comment><USER32> Related to App Store removals: [http://www.theguardian.com/technology/2015/sep/30/apple- remo...](http://www.theguardian.com/technology/2015/sep/30/apple-removing- drone-strikes-app)

<comment><USER33> > Related to App Store removals: > [http://www.theguardian.com/technology/2015/sep/30/apple- > remo...](http://www.theguardian.com/technology/2015/sep/30/apple-removing- > drone-strikes-app)

That seems completely unrelated, but it also seems a whole lot shittier.

Why would Apple remove an app for reporting casualties of US Drone strikes? It's basically a very specialized news app.

<comment><USER34> The reason is right there in the article - excessively crude or objectionable content.

If a porn website released their own video player as an app, you could call it a "very specialized web browser", but it would still obviously violate the app store ToS.

<comment><USER11> That is the stated reason but it doesn't make any sense. There are games in the app store where you actually _pilot a drone and blow people up_ and Apple has let them be. Are we to believe that graphically simulating drone strikes is not crude or objectionable, while textually reporting on real drone strikes is?

<comment><USER34> You can believe what you want. Personally, I believe that either nobody has bothered to report the apps that are still up, or Apple doesn't give a shit about games because those are in their own bucket.

<comment><USER35> I think what it boils down to is that Apple shouldn't be deciding if newsworth facts are too obscene to be published. Should news apps be removed if they report on murders?

<comment><USER34> There's a huge difference between a news app that happens to cover murders and a "murder news" app that only covers that specific subset. The app in question is clearly much closer to the latter.

<comment><USER20> So, software that only provides reports on firearm-related-homicides in a neighborhood is a "murder news" app and should be banned?

<comment><USER34> I've been deliberately avoiding talking about what should be banned. I would expect Apple to remove such an app from their store once they found out about it, yes.

<comment><USER20> > I've been deliberately avoiding talking about what should be banned.

Given that Apple's de-listing rationale is arbitrary and capricious, restricting one's comments to attempts to predict what Apple might ban provides zero value to any conversation.

<comment><USER34> If you wanted to call their app removal criteria arbitrary or capricious, you sure picked some bad examples.

Their offensiveness meter seems pretty obvious to me. The only thing I'd really worry about is "apps that duplicate OS features" since you really can't predict that without insider knowledge.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER36> It's sad to see that some companies so brazenly abuse their customer's trust, and there are no consequences for them.

Users trust Apple to protect them from malicious and perhaps from low-quality apps, and instead Apple abuses their power to try to silence those distributing information they don't like.

<comment><USER37> Except iFixIt signed an NDA contract to not disclose these information and in exchange, they get a free developer kit after $1 fee.

iFixit admitted they broke the NDA and they did so, to get clicks for their sites. iFixIt broke the trust, not Apple.

<comment><USER38> No, iFixit engaged in corporate behavior with a corporation - no trust ventured, none lost. Maybe there was harm - a lawsuit can settle that.

But Apple broke the trust of their users - by deleting a perfectly valid app in retaliation for a third party doing something unrelated. Any user wanting to see how to fix something is harmed by Apple's actions. Maybe iFixit provoked them, but Apple pulled the trigger.

<comment> yoz-y What would you suggest Apple should do? They can't let this blatant stomping over a perfectly reasonable NDA agreement pass. The other option they had would be to sue iFixit to oblivion which would have way bigger impact on the users.

<comment><USER38> Well, they could disappear an App that many people used, or ... anything else really. What they went with was pretty customer-hostile. It illustrates the problem with a closed eco-system. Two other parties have a fight and you end up stuck in the middle.

I don't know that they want to point this out, even if they think they're in the right.

</comment></comment></comment></comment></comment><comment><USER39> That's why I will never develop for iOS and never own their devices, unless forced to.

<comment><USER40> Does Google not have any sort of terms of service for prerelease hardware?

<comment><USER39> I can install any apk without asking Google.

<comment><USER40> So Google wouldn't pull your apps, they'd just sue you?</comment></comment></comment></comment>


Gawker Founder Suspects a Common Financer Behind Lawsuits - <AUTHOR> http://www.nytimes.com/2016/05/24/business/dealbook/gawker-founder-suspects-a-common-financer-behind-lawsuits.html <comment><USER2> Subject this article to scrutiny:

1\. Why am I hearing this?

2\. Why am I hearing this now?

I hear an agenda being pushed, at great effort, with the assistance of that great impartial arbiter of Truth, the NYTimes. Someone is attempting the "death by 10,000 paper cuts" method of PR warfare. No substance. Just speculation.

Not that the NYTimes is any worse than other news outlets in this regard. It's just a reminder to be skeptical.</comment>


You Only Live Twice - <AUTHOR> http://www.overcomingbias.com/2008/12/you-only-live-twice.html

<comment><USER2> Reasons why cryonics is dumb:

\- First off, there's a close to zero chance of a successful revival. Pretty much all of the major problems with thawing (like, let's rebuild your severely damaged brain) are pushed off onto future generations to solve. Not to mention curing whatever killed you in the first place. But let's pretend the future is magic, and this can work...

\- Who pays for this? And no, I'm not talking about the freezing. The article presumes we can just use life insurance to pay for cryonics (and not say, to support your presently alive loved ones). But who pays for your future miraculous revival? Even in the super advanced future, presumably a complex procedure like reconstructing a human brain won't exactly be a cheap one. Not to mention all the medical care you'd need for recovery (and don't forget about all those people who just froze their heads, they'll need whole new bodies!). Why exactly are the people of the future so eager to resurrect all these frozen corpses of people with no living family or friends to support them? Is the future such a utopia that not only have we solved overpopulation, but we're desperately looking to bring back long frozen bodies with severe medical problems?

\- The part that really strikes me as idealistic and naive about the article though, is the idea that death is "not part of the plan". And I thought we were being unrealistic about the future when they could rebuild your brain. So now everyone lives forever? That doesn't seem very sustainable. Not to mention the fact that it is the very finiteness of life that makes it valuable in the first place.

Conclusion: The present is yours to do with what you like, and the future may or may not ever get here. Invest in today.

<comment><USER3> Lets see...

Value of my life (at least to myself): infinity,

Probability of revival: >0

Expected value = (probability of revival) * (value of my life) = infinity.

So... low odds are not a good excuse to not go for cryonics.

Next, who pays: The person being frozen. Its like a trust fund. Toss in a large one time sum and live off the interest. The interest on 120K at 4% annual compound interest (after inflation) is ~500 dollars/yr which should be enough to maintain what is basically a big freezer for a long time and note that that 4% is a _very_ conservative figure and accumulating 120K is not a big deal for those in the upper middle class and above which is still a lot of people.

What he means by "death is not part of the plan" is that at least they are trying to live longer, even if the chances of success are slim.

Conclusion: Cryonics has the potential to be a valuable investment.

<comment><USER4> _Value of my life (at least to myself): infinity,_

I seriously doubt this. There are numerous activities -- smoking, eating delicious food, having risky sex, crossing the street -- that people routinely do despite the incremental risk of mortality. I've read that when you divide the extra money by the increased death risk (e.g. a $10K lump sum payment for a 1% chance of dying, as you'd get if, for example, you switch to higher-risk duties in a mining or lumber job), the average person values his own life at between $1 million and $10 million.

If you do spend all of your time on maximizing your probability of survival -- making money for medical care, reading medical journals in your free time, not doing anything that's really fun and slightly fatal -- I'd believe you. Otherwise, you suffer from cognitive dissonance.

<comment><USER5> That evaluation is taking into account the fact that death is inevitable within 120 years or so regardless of what you do. If you expected to live for 1000 years or more, you'd presumably value your life higher.

<comment><USER4> It's still a finite number, and unless the marginal utility of life goes up over time, it should be less than eight times the original number. So let's say $5 to $50 million. Still not infinite.

</comment></comment></comment></comment></comment><comment><USER6> _Not signing up for cryonics - what does that say? That you've lost hope in the future. That you've lost your will to live. That you've stopped believing that human life, and your own life, is something of value._

No, it's because I value my life so much that I don't believe in cryonics. If it is your belief that it is possible to live N number of lives, your current life loses some of its meaning. Maybe you don't strive for so much, because there's probably more time later. Maybe you don't try as hard because if you fail, you might get a do-over. Maybe you don't shoot for the whole "regret nothing" thing with as much tenacity.

<comment><USER7> By that logic, would you rather die in 5 years than in 50?

<comment><USER6> Uhhh.. neither? Measuring it changes the outcome. Knowing when I'm going to die is as bad as believing I won't.

<comment><USER8> You already know with high probability when you're gonna die. If anything, living indefinitely (or giving yourself a chance thereof) takes you farther from knowing when you're gonna die.

</comment></comment></comment></comment><comment><USER9> I think cryonics is about as useful as all those old tombs in Egypt. We could probably clone some of those body's and reviving people from cryonics might be an interesting experiment for our decedents but in both cases much of that dead person will have been lost. And trading resources in this life so that some shadow of me might show up in the future is not worth much time. So yea it's the best hope we have now, like it was their best hope back then, but all they are talking about is imperfect copies.

</comment><comment><USER10> OK, so maybe I read too many fantasy and sci-fi novels, but I'm less interested in the problems of coming back from the dead. What really interests me is the related problem of how to kill someone securely.

Take, for a prosaic example, vampires. Shooting a vampire will almost certainly NOT kill them -- sources differ but they might not die, might die but revive immediately, might die but revive the next night, etc. So how to kill a vampire definitively?

I think, based on the union of all the vampire lore I've heard, you have to:

* stake him

* stuff his mouth with holy wafers

* cut off his head

* burn the body (both parts, presumably, but better to keep them separate)

* bury the ashes on hallowed ground

* ... at high noon

* drop a nuclear bomb on top of the church

THERE. One vampire, securely disposed of.

I'm sorry if this digression into the fantastic was a waste of time for you. We now return you to your regularly scheduled intellectual discussion of cryogenics.

</comment><comment><USER11> Maybe, I'm wrong, but I often get the impression that the person who writes this blog is in need of a good grief counselor, but may be too smart for most of them to help.

<comment><USER12> My grief is not the problem. This world is the problem.

<comment><USER11> If this world is the problem, you need to redefine the word problem.

<comment><USER13> No, you just need to change the bleeping world.

<comment><USER11> Maybe. Maybe death isn't such a bad thing. We only dislike it due to our grief response, but outside of that it performs lots of useful functions.

Also, I'm still highly skeptical cryonics will ever be reversible to the point where I can truly be brought back. My body may be reanimated, maybe, but without my memories, it's not much different than birthing a fully formed adult.

I'm not opposed to cryonics in general, but the author said he thought it should be done by the state to everyone unidentified, which I find ludicrous.

</comment></comment></comment></comment></comment><comment><USER14> That's a pretty hopeless point of view. Why not assume that in the future they'll harness the universe's full computational capabilities and emulate every single being that has ever lived? If cryonics is possible, the simulation scenario is just as possible, since it uses the exact same assumptions. Plus, it is a lot cheaper to believe in:)

<comment><USER4> _Why not assume that in the future they'll harness the universe's full computational capabilities and emulate every single being that has ever lived?_

Because if you assume it will happen, you have to assume that the mostly likely explanation for your existence is that it _did_ happen.

<comment><USER14> That's a bad reason to assume the opposite. If Eliezer's assumptions are valid, then the scenario I outline is just as valid. You can't have one without the other.

</comment></comment></comment><comment><USER15> I'm not convinced that medical science is so far behind determining life. Once a person is pronounced dead, I'm convinced they're brain dead. So it's useless to preserve someone when nearly all of their information on the state of their mind has been lost.

<comment><USER16> You're right to be skeptical, but I encourage you to investigate further, since this is a common but erroneous belief: that even a few minutes without oxygen causes irreparable brain damage. In fact, it's the autoimmune response upon _revival_ that causes the damage to the brain, not the hypoxia. And cold prevents the damage; some types of brain surgery require zero blood pressure, and are performed at low temperature (potentially for hours) without harm to the brain.

<comment><USER15> I probably spoke to fast. I could see it being somewhat feasible if the cryonics facility was immediately informed that the patient was dying, and the patient was frozen within hours of clinical death. My main concern is the success of freezing a brain dead person. I also was mainly referring earlier to the loss of information in the brain, not the actual physical brain damage.<http://en.wikipedia.org/wiki/Information_theoretical_death>. So if the family refuses or delays to inform the organization, I'm skeptical about whether the information in the brain can be preserved. And there have been bitter legal battles fought over cryonics. [http://www.depressedmetabolism.com/is-that-what-love-is- the-...](http://www.depressedmetabolism.com/is-that-what-love-is-the-hostile- wife-phenomenon-in-cryonics/)

</comment></comment></comment><comment><USER17> Does the idea of quantum immortality suggest that you would be revived? In that case I guess you're already living in a universe where you WILL freeze yourself (or in one where the singularity gets here soon.)

</comment><comment><USER18> Reasons why cryonics is dumb:

Life is suffering (Buddha, n B.C.) Death is void. Nothing > suffering.

But there's a wall of pain/fear/effort/risk with suicide that keeps people inside life. Once you're dead, you're forced past the wall and it's a simple choice:

more suffering or no suffering?

Immortality by not dieing isn't quite the same option - avoiding old age suffering or going to old age suffering? Easy, being alive and rejuvenated wins.

</comment><comment><USER19> I find it interesting that there's a not-small class of atheists who, believing they face the horror of annihilation, are driven to believe in things that are just as irrational as traditional religion-- mind uploading, cryonics, singularity, etc.

I don't know if there's an existence after death, though I think there probably is one, and I consider myself lucky to believe this, for if I'm wrong, I'll never know. What's horrible about annihilation/nonexistence isn't any experience of it-- there is none, by definition-- but the rather hideous shadow the prospect, were it true, would cast over life.

<comment><USER14> Yeah, I don't get the "horror" of annihilation. If I won't care once I'm gone, why should I care now?

<comment><USER19> Because a human life is so incredibly short that decline and death are rapidly impending, and it's difficult not to think about them constantly. Perhaps I'm unusual, but I think about death-- my death, not just the abstraction-- several times per day. And I'm not a depressed or morbid person, so I think this is pretty normal.

It would suck if the final act of existence were painful decline, followed by eternal oblivion. It could well be the case, but I'm glad that if it is, I'll never know about it.

<comment><USER14> Well, that's just a matter of psychology then, not any kind of logical should. I think about death too, but it doesn't seem to bother me like it does others since I don't see a logical reason behind the dread. Sure, the psychological side still gets to me when I stare death in the face, but otherwise not so much.

A logical should would be something like if I were to die I would spend an eternity in ceaseless boredom. That would be a reason to avoid death. Otherwise it is just a false anticipation, like jumping off a high rock when you know it is perfectly safe. I try to eliminate that from my life if I can, which is the rational course of action. I think this is the psychological basis of thrill seeking.

If you look at your own decision making process, you'll see that this procedure is how you also shape your psychological reactions. Say you really dreaded a certain event, such as moving out of your parents house. Then, when the time came, you found you could handle yourself alright. With that knowledge in the back of your mind, you no longer dread similar situations as much. I'm just making this process explicit in how I think about life.

</comment></comment></comment></comment><comment><USER20> "If you want to securely erase a hard drive, it's not as easy as writing it over with zeroes. Sure, an "erased" hard drive like this won't boot up your computer if you just plug it in again. But if the drive falls into the hands of a specialist with a scanning tunneling microscope, they can tell the difference between "this was a 0, overwritten by a 0" and "this was a 1, overwritten by a 0".

There are programs advertised to "securely erase" hard drives using many overwrites of 0s, 1s, and random data. But if you want to keep the secret on your hard drive secure against all possible future technologies that might ever be developed, then cover it with thermite and set it on fire. It's the only way to be sure."

There have been no cases of anyone ever restoring a zeroed hard drive. It's utter bullshit. Especially these days with our precision aligned platters and insane densities.</comment>


Amazon's Stressed Out Culture Is Burning Out Employees - <AUTHOR> http://www.minyanville.com/sectors/technology/articles/AMZN-AAPL-WMT-GOOG-MSFT-Amazon/10/10/2013/id/52177 <comment><USER2> For what it's worth, as someone who did two internships there, the whole "Amazonians hate their job" thing is way overrated. With the exception of pager duty, most of the legitimate complaints employees used to make have long been addressed. I've interned at other big tech companies too, and Amazon stands out in my mind as having some of the highest morale.

Here's another interesting data point: both of my teams at Amazon are still pretty much 100% intact after 3-4 years – whereas my team at Google, to take one example, have almost all left the company since 2011.

<comment><USER3> Ex-amazonian here, It really depends on the team. There's 2 types of crappy places to be at Amazon: the really important legacy system, or the we need to catch up with the competition product.

In the first case, there's no opportunity for really improving things, it's usually a small team which can really hamper your advancement, and it breaks constantly. You'll work a 40 hour week, but will get paged all the time and have lots of little emergencies.

The second is sexier, and a good opportunity to move up the ladder, but you'll be working 60-80 hour weeks, loads of crunch time, and suffer due to constantly shifting management as the team explodes in growth.

All that being said, there are a lot of good opportunities, especially for younger engineers. Provided you have a decent performance review, mobility is pretty easy, so if you're stuck on a shitty team, that can change after a year+. You'll want to find a team with a manager who's been around amazon for a little while. You're supposed to tell your current manager first that you're looking around at other opportunities, but in practice this is rarely done before all but securing a new position. I recommend the Rowhouse coffee shop for talking with potential future managers. It's usually pretty clear after 2 and has lots of little rooms and well shaded windows.

If you end up stuck on a shit team, without being able to move around, start looking around Seattle. Twitter, Google, Hulu and Facebook are all hiring here, and they all usually pay better, in addition to having better perks. It's quite something to interview at Google's offices and see the difference in culture. If you've just gotten a promotion, or shipped a major product, that's an ideal time to start talking with other potential employers.

<comment><USER4> Doesn't Amazon make you sign an 18-month non-compete? How could someone jump to Google?

</comment></comment></comment><comment><USER5> Anecdotally speaking, I went to a party which had a few Amazon employees in attendance. After a few drinks, two of them let on to the group that they were quitting their jobs because they were sick of Amazon - and high fives were shared all around, including among the folks that weren't leaving. Doesn't seem like a happy group.

</comment><comment><USER6> Before Bezos settled on the name Amazon, he wanted to call it Relentless. In fact, the domain [http://www.relentless.com](http://www.relentless.com) still leads to Amazon. That fact seems indicative of his leadership style, in light of this article.

<comment><USER7> The company's lore is that it was originally called Cadabra.com (as in abracadabra). But then people were confusing it with cadaver, so it was changed to Amazon.

</comment></comment><comment><USER8> This is a poor article. The article begins by claiming a "stressed out" culture is resulting in the factually low employee retention rate, but then goes on cite as evidence things like: no free cafeteria, average pay, and emails that report up the management chain, and that the CEO has a weird laugh. Of all the "evidence" listed, only the team darwinism and searing insults would contribute to a stressful environment. The rest are just random factoids of average employers.

I don't know if Amazon is stressful to work for, because I've never worked there and haven't talked to any friends about it in detail, and this article did not help at all to shed any light on that.

</comment><comment><USER9> Is there anything wrong with the CEO forwarding an email, adding just a question mark? It is shorthand for "Can you please tell me what is going on here and how it can be taken care of?". It isn't like if he typed out a whole sentence, it would cause the person who panics at a "?" to somehow not panic. They'll probably just read too much into the sentence and panic even more.

<comment><USER10> As someone who was on a team that got these "?" emails quite a bit, it isn't the email that was the problem. It was the culture that you will drop whatever you are doing to answer this one very specific question that was the problem.

Now my team had a very good manager who knew the system and pipeline. So if he was 95% sure he knew the answer, we never got the email. If he didn't, he would forward it onto the oncall. And the oncall might forward it onto someone else if they were busy with a Sev1/2 issue.

But it was expected that you would drop what you were doing and answer. I've seen devs get up during the middle of lunch and go back to the office to answer a Bezos question.

</comment></comment><comment><USER11> Ahh, this explains why I, a web developer in the middle of the Canadian Prairies keeps getting hit up by Amazon's recruiters. Quite possibly they've poisoned their local talent pools so much they have to pull in naive people from out of market.

Glad I saw this article - now I don't need to fret about whether I should respond to the email. Just the very fact this article was written signals enormous alarm bells for anyone considering moving to work at Amazon.

<comment><USER12> You are very naive if simple blog spam articles like these influence you that much.

<comment><USER11> Actually, it's pretty naive of you to assume that this is the ONLY article that I might have read documenting Amazon's work culture. Moving across the country to work for a foreign company isn't the type of decision to be made lightly.

Amazon has a terrible reputation, as evidenced by this article as well as a simple google search for "amazon work culture". And that reputation is costing them talent.

That's all I was getting at...

</comment></comment></comment><comment><USER13> I work as an SDE I at Amazon. This article is pretty ridiculous.

1) I don't see anything wrong with the question mark emails. Amazon places huge emphasis on customer service, and Jeff rightfully wants to know why is this particular customer unhappy.

2) No perks. Yeah, good free food would be nice. But I'm cooking my own launches most of the time anyway.

3) My salary (as an SDE I, college grad) is almost exactly the same a good friend of mine (also a college grad) got at Google in California (his was 10% more to cover the CA income tax).

4) Not sure about the stacking program, never heard about it. I'm certainly not stressed that I have to be better than my peers so that I don't get fired.

5,6) 3 out of 6 points in the article center around Bezos. Your chances of running into any of those 3 issues are next to nil. Amazon != Bezos.

</comment><comment><USER14> So out of curiosity, which major tech companies operate on a stack ranking system? It seems that Microsoft has gotten the most flack for it in the past, but it seems that many other companies also have it. Here's what I've heard, from different employees at different companies:

* Amazon - top 20%/70%/bottom 10% buckets

* Facebook - definite bucketed review system every six months

* Google - unsure if bucketed, but performance review every three months and again at end of the year.

* Yahoo - definite bucketed review system every three months and again at end of the year.

If anyone knows the performance review systems at any other company, please definitely feel free to call them out in the replies.

<comment><USER15> Google's performance reviews are every 6 months. No bucketing.

Well, you get to know if you are "needs improvement", "meets expectations", or "exceeds expectations", and you can pretend those are buckets if you try hard enough.

<comment><USER16> Does it lead to employees/groups competing with each other to keep their job? I've experienced that at one of my gigs and it just kills my morale. I have a habit of helping co-workers. Then, I notice that I don't always get any acknowledgement in front of mgmt. At the end of the year, the people doing perf reviews don't seem to always know what role I had in some of the successes. At a previous employer where this stack ranking stuff was not prevalent, my coworkers were very generous with their sharing of credit (as was I). As time goes on, I feel I am being a naive person and have no one to blame but myself.

<comment><USER17> I think this is a key comment. It's not so much that the concept of a stack ranking system is bad in a vacuum. But nothing happens in a vacuum, and individuals will nececcesarily adapt their behaviour according to that which will keep them safe. In a nutshell, the effect of a stack ranking system is to discourage collaboration and hurt camaraderie.

</comment></comment></comment></comment><comment><USER18> The original article on which this article is based[1] has an interesting chart of median employee tenure for various companies. Amazon is at the bottom, with the median employee leaving after only one year. Google is not much better, with a median employee staying 1.1 years. In contrast, Microsoft employees stay 4 years and IBM employees 6.4 years.

[1] [http://www.businessweek.com/articles/2013-10-10/jeff- bezos-a...](http://www.businessweek.com/articles/2013-10-10/jeff-bezos-and- the-age-of-amazon-excerpt-from-the-everything-store-by-brad-stone)

<comment><USER19> The chart has the useful footnote that it, "does not account for overall growth in workforce" which penalizes companies with quickly growing headcounts. I'd also guess Amazon's warehouse staff has more churn that a technology company and they are a large portion of the overall workforce there.

<comment><USER20> We have a fair number of ex-Amazonians at work and they all complain about the work culture there, so I do believe it may well be that bad.

<comment><USER19> I have very little insight into the matter. Just noting some limitations and biases in the data presented. Former employees are probably biased sources of data, too.

Anyway, I've heard it's a tough place to work, but some people thrive on it... nothing beyond what's in the Businessweek article.

<comment><USER5> A very middlebrow dismissal of OP. :|

</comment></comment></comment></comment></comment><comment><USER21> Someone here mentioned Amazon's core value on frugality:

"We try not to spend money on things that don't matter to customers. Frugality breeds resourcefulness, self-sufficiency, and invention. There are no extra points for headcount, budget size, or fixed expense."

But isn't making the employees happy directly and indirectly influencing the product and service the customer is getting at? I understand the business Amazon is in is of low-margin profit. But still, high employee turnovers may cost more than the extra-money the company can spend on making the employees happy. Not to mention the employees productivity can increase when they are happier, so the ratio of (productivity/salary) still increases even though salary increases. May be now Amazon can have less number of employees, but each doing more productive work because they are happy.

</comment><comment><USER22> Dear God, is it that bad? Sounds awful.

Does Bezos seriously forward any complaints received at firstname.lastname@example.com to the right person? I'll bet that _is_ panic-inducing.

<comment><USER23> The mentioned book "The Everything Store" gives hundreds of examples of this corporate culture, culminating in the quote:

>"If you're not good, Jeff will chew you up and spit you out," notes one former employee. "And if you're good, he will jump on your back and ride you into the ground."

It's a good read on how _not_ to lead a company, and I'm reasonably sure Amazon will fail once Bezos dies - the success seems tobe based on Bezos' enormous drive.

I would never work there.

<comment><USER24> "It's a good read on how not to lead a company"

But they are very successful. People say the same thing about Jobs, and again, they are very successful. People that say, "this is no way to lead a company" have to have counterexamples of equally successful companies that aren't run this way.

<comment><USER25> The Roman Empire was very successful, maybe that's the best way to lead too? Of course that's ridiculous. If you have a big house, a big salary, and you're miserable, are you successful? Amazon has a nice stock price, good technology, and (allegedly) broken employees, is it successful?

<comment><USER24> so you don't have a counterexample?

</comment></comment></comment></comment></comment><comment><USER26> Engineer currently working at Amazon here, and I agree with most of what's in the article. Obviously, there will be different opinions on Amazon depending on what team you work for. I can speak in detail for my team in particular, and the biggest complaint that employees reported in the annual survey is the high operational load, which cuts deeply into your personal life for a week once in a few months. In a nutshell, you have to cancel all activities during your oncall week and you will most likely get awoken almost every night of the week. Random stuff happens (host failures, overload and random internet weather/congestion) and there's a certain stress that hangs over your head as you are the primary person for keeping the service up and running at all times. Although...I do have to say operational load has gotten better over the past year as we've made it a goal of ours to reduce the number of pages we get.

Most of my friends who don't work in tech think that Amazon must be a great place to work for since it is a pretty successful tech giant and they think all tech giants give amazing perks and benefits to their employees (probably due to the standards set by places like Google and Microsoft). But this frugality to their employees is one of the main keys to Amazon's success. Amazon's goal is to make the customer happy, and they will be frugal on expenses that don't contribute to that goal. I mean, why would the customers care whether employees get free lunches everyday? This type of thinking is much different than a place like Google's where the obsession is towards making the employees happy, which in turn makes more productive employees.

As for stack ranking employees, it depends on the team you work for. My team in particular does stack rank people. Basically if you get ranked in the bottom 10% bucket for two years in a row, then you're fired. Yeah I know this system sucks sometimes as an employee but it does do the job of keeping people on their toes and making sure the quality of the people on the team is high. I personally tend to not like to work with people who coast at work and produce results at a slow pace, so I have no complaints about the stack ranking.

The pay is actually quite decent for a new grad. You might get slightly less in absolute pay from a place like Google or Facebook, but this is offseted by the lower cost of living in Seattle and also the no state income tax in Washington. But the pay on average for mid-level and senior engineers do lag significantly behind that of other tech giants. Again, this goes hand-in-hand with Amazon's concept of frugality and lower costs for the customer.

I would agree that Amazon is not always a fun place to work for due to high pressure to produce results and also the pager duty. If you want to have good work/life balance, then Amazon is not the place for you. Some of my co-workers originally from Microsoft who have gotten used to the comfortable lifestyle there are finding this out the hard way. Those who enjoy the relatively fast- paced work environment and the great potential for individual growth are the ones that are most successful and stay at Amazon the longest, while I've seen others who have more or less burned out by 2-3 years and have left the company.

In all, now is a great time to join Amazon as it's experiencing unprecedented growth and more buildings are being constructed now just to have enough office space for everybody. If you were to think about working for Amazon though, I would recommend some teams in AWS as the projects there are more technologically interesting and the hiring bar (and in turn quality of your peers) is higher than most other teams at Amazon.

</comment><comment><USER27> Side note: ?refresh=1

Reloaded the page in the middle of reading it. Why?</comment>


Where's all my CPU and memory gone? The answer: Slack - <AUTHOR> https://email@example.com/wheres-all-my-cpu-and-memory-gone-the-answer-slack-9e5c39207cab <comment><USER3> Want to make an app that people use in the background? Music player? Chat app? Backup? Antivirus?

Then for gods sake make it lean. Set a resource budget and stick to it. Don't assume your product is a special snowflake that your users will want to waste resources on.

The easiest way is usually to just use a native toolchain and UI. Your users don't care how easy it is to find js devs.

<comment><USER4> > Your users don't care how easy it is to find js devs.

Their user do absolutely care about UI/UX. If you're going to implement it native without all the "free" things you get from the web stack, and its popularity, the UI is most likely going to suffer.

<comment><USER5> I don't know about other platforms but on MacOS native apps are way better designed (looks and usability) than the electron crap that is available. So I'm curious, what makes you say JS devs are better at designing apps than native devs who know how native apps work?

</comment></comment></comment><comment><USER6> I tried to use Slack multiple times and it is the same - laggy, slow experience that caused me to completely leave it. I would assume more from a tool praised by devs, to be honest. The whole experience was for me super negative, and it seems that Slack is mostly re-wrapped IRC, thus getting overwhelming support from IT guys in large corporations.

My laptop is only i3 with 6 GB Ram and some integrated graphics card, but I would assume this is enough to run a chat app, if the machine can flawlessly run Flash games and never cause an issue when I develop apps...

<comment><USER7> Things are getting out of control. Some of my non-technical friends are already moving into 16 GB of RAM on their new laptop purchases. For surfing the web and watching movies...

The worst thing is not just memory consumption, but sluggish UIs. Everything is turtle slow. I notice a significant lag when typing on their machines no matter how much RAM or CPU you have.

I run a WM (XMonad), Firefox (vimperator), a terminal (urxvt) and Emacs, with no actual desktop environment (but all services, including firejailed applications). Without opening Firefox, I'm comfortably below 200 MB of RAM. And Firefox is not a memory hog either, if setup and used with care.

Even more, before starting X, I'm around 128 MB of RAM, yet I can do most stuff inside a text-mode Emacs.

An additional benefit is robustness. With fewer components things hardly break, and when they do you can easily fix them. Especially if you use a Nix- style package manager and system configuration.

Not a setup for everyone, I know, but an average HN reader will have no problem putting it together. If friendlier GUIs are still your preference, I believe some lightweight Linux desktops are worth a shot. Last time I tried Xfce, it was simple and lightweight. Even my old dad was able to adjust to it quickly.

<comment><USER8> it's the weird memory logic of HN biting again:

"Memory is cheap, development time is expensive"

and:

"What do you need more than 16G of ram for?"

These two things are not compatible, but every time a story comes up about new laptops (macbooks being a prime example) everyone jumps on the guy who asks for more than 16G of ram while routinely excluding things (like browsers) that just chew memory.

<comment><USER9> It is almost like hn is made up of different people with different opinions.

</comment></comment></comment></comment><comment><USER10> Slack is a heaping pile of shit.

I understand it lets you conduct text chat.. and basically works for that.

But I don't understand the fawning.

It's a massive resource hog. People have inadvertently DoSed my browser by pasting a message rate that any native application like irc or jabber would yawn at.

<comment><USER11> Windows 10.

My browsers are consuming ~4GB of memory right now. The Slack app is taking up 130MB, currently signed in to two teams.

To be fair, Outlook, which manages 3+GB of Email, is only taking 60MB, so old school does win out.

<comment><USER12> Slack starts a V8 instance for every team you sign into. It is absurd on my W10 machine.

Running it on Edge is significantly better on battery life and it feels snappier.

</comment></comment></comment><comment><USER13> I now run Slack in Safari on my Macbook Pro.

In Activity Monitor on macOS there is an "Average Energy Impact" metric. I noticed that Slack had a value of 34. The next highest was Chrome at 23, and that's with 200+ tabs open across multiple accounts and windows.

Safari runs with a tab per Slack team, and it's Avg Energy Impact is 1.

<comment><USER14> I also gave up running the Slack Mac app, and now use it exclusively on a browser/iOS.

One issue I haven't figured out in Safari specifically is that it suspends tabs, which is why its so low on energy impact. A few min away from the Slack tab in Safari means that I'll disconnect and appear offline.

<comment><USER13> I haven't run into that issue. Maybe background notifications prevent the tabs from being suspended?

</comment></comment></comment><comment><USER15> Amazing that people are OK with this, or the misbehavior of Electron in general. Bring back IRC indeed...

<comment><USER8> I love IRC, I even run my own IRC network, but IRC in 2017 is indeed woefully dated.

To my mind we need something which is a little bit more mobile friendly- with support for replaying history etc;

IRC "could do this" with bouncers and such, in fact I do this myself, but it's not very clean- and if you see it from a protocol perspective it's all hacks on hacks.

A clean "IRC for 2017" style protocol would probably wind up looking a lot like matrix, so I'd rather we rally behind that.

<comment><USER16> My team uses matrix, it's loads better than Slack.

</comment></comment></comment><comment><USER17> So, I cannot reproduce his findings. My system (same setup, Slack native app on macOS) is consuming 1.6% CPU, about 0.6 GB memory, and has avg. energy impact of 3.22 with current being 0.0.

The memory is high, but a lot less than Chrome and nothing near what the author is seeing.

Only differences I can see:

\- I'm signed into two accounts while the author is signed into 11.

\- The author is CEO of a competing messaging platform.

More experiments might be needed here.

<comment><USER18> The authors company isn't a Slack competitor, it's a real-time data platform. Otherwise I imagine they wouldn't be using Slack for their internal messaging.

<comment><USER17> From the page:

> Matthew O' Riordan is CEO and Co-founder of Ably. Ably is a platform that > makes it easy for developers to add realtime messaging... to their > applications.

Slack is realtime messaging. Ably is realtime messaging. They are competitors - the only question is how direct.

<comment><USER19> Slack is chat, its messages are sent and read by humans. Ably is a developer API, its messages are sent and read by machines.

Slack has a shiny user interface and a bunch of nice enterprise features. It's something you'd have everyone in your company sitting on their machine all day.

Ably is something nobody will ever see. It's an API that underlies other people's applications. Hell, Slack could run on top of Ably.

They're absolutely not competing. You're either misreading or deliberately misleading.

</comment></comment></comment></comment><comment><USER20> There's also weird bugs/features. Have an animated emoji in the currently active channel. Just one. Put Slack in the background - it's still using 10%-15% of a 2016 MBP CPU. WTF.

<comment><USER21> I noticed this a while back too. Switch to a private chat that only contains text when you tab out of a team and it doesn't hog. I think the "don't draw in inactive windows/tabs" feature implemented in most browsers is missing.

<comment><USER22> Even without the optimisation - I recall seeing animated gifs on older hardware without a huge cost. What is it doing? It's like when Google Play Music takes 20% of my 4-thread 1-2GHz i5. I'm pretty sure I listened to MP3s on a Pentium 166 without it pegging the CPU completely.

(And Google Play on Android... on a Nexus 5, I'll sometimes wait 5+ seconds for the playlist to open after clicking the icon.)

<comment><USER23> > I'm pretty sure I listened to MP3s on a Pentium 166 without it pegging the > CPU completely.

I can collaborate that. I remember upgrading from a 486 to a Pentium 166 and being excited that I could finally play 44khz stereo MP3s at full quality and not be constantly skipping. I could even browse the web at 56k at the same time!

</comment></comment></comment></comment><comment><USER24> The Slack desktop client implements multiple teams basically the same way Chrome implements multiple tabs. And we all know the rule of thumb: you can create one Chrome tab per gigabyte of memory.

<comment><USER25> It's remarkable how bloated browsers have become. I remember having multiple Netscape 3.x windows open back in the mid-90s, on a 486 with 32 megabytes of RAM.

<comment><USER26> Sure, but browsers today are incredibly complex runtime environments that support all kinds of apps. That inevitably results in bloat.

<comment><USER25> Agreed, but not orders of magnitude more complex. It's not just browsers... all software suffers from this bloat.

</comment></comment></comment></comment><comment><USER27> Yeah but the authors of the Slack app didn't have to learn anything but Javascript and HTML. What else could be more important than that?

<comment><USER28> Yes, developers are more important than users.

</comment></comment><comment><USER29> Previously I ran the Slack desktop app on Windows/Mac/Android and for IRC Hexchat on Windows, Textual on macOS and nothing on Android (I couldn't find a good IRC client). A ZNC instance on the server was keeping these IRC clients in sync.

Using Slack over IRC would have been interesting but then I would lose the rich inline previews of links/media on Windows because Hexchat doesn't have these and I don't know any other standalone IRC client for Windows which has this feature.

Then I switches to IRCCloud and now I use it for both Slack and IRC:

\- Better synced state across clients compared to ZNC

\- The Chrome tab needs ~600 MB RAM which is less than Slack + extra IRC client

\- Unified chat UI across Windows, Mac AND Android :)

\- inline previews like Slack

Running my own ZNC instance on a server was not a big hassle but its buffer replays where annoying and depending on the settings it would DOS my IRC clients for several minutes because they where busy processing the incoming buffer backlog.

</comment><comment><USER30> Haven't seen it posted here yet but wee-slack [0] works wonders if you're not afraid of using weechat.

I'm looking at an average CPU usage of 2% and memory usage of ~30MB for three IRC networks and three different Slack teams.

[0] [https://github.com/wee-slack/wee-slack](https://github.com/wee-slack/wee- slack)

<comment><USER31> As someone who works in encoding video at resolutions greater than 8k all day, the only way I can work with Slack is by making use of wee-slack. Every other option is either not complete enough to use, or too expensive on CPU/GPU to justify.

</comment></comment><comment><USER32> I remember reading somewhere that the source of problem is gifs. They are kept in memory and always running, even if off screen. If this is true, the solution should be pretty easy?

</comment><comment><USER33> I had this realization some time ago: almost everything I do on my desktop runs in Chromium wrappers: Chrome (duh), Spotify, Slack, WhatsApp, Signal

<comment><USER34> It's almost as if you could make a whole OS out of Chrome. Someone should look into that. ;)

<comment><USER35> If only there was a way to write apps that could share an instance of Chromium, and access native resources the way they can with Electron. Oh wait: [https://developer.chrome.com/apps/migration](https://developer.chrome.com/apps/migration)

</comment></comment></comment><comment><USER36> Javacript "apps" on desktop using too much CPU and memory?!?

Say it ain't so!

<comment><USER37> There's nothing inherently evil about JS in this context that isn't true about Python or Ruby -- it's just that JS's default UI toolkit is horribly bloated.

<comment><USER38> Perhaps shoehorning a half-baked web scriping language into native app development isn't such a good idea.

Not all ideas are created equal

</comment></comment></comment><comment><USER39> "Note: I am running a Slack desktop client on OS X with eleven (11) accounts."

Admittedly, Slack is a lot of resource usage for what is something like a glorified IRC client, but this is not the average Slack user.

<comment><USER40> That's not that outlandish. Many open source projects are using Slack, in addition to commercial projects. I've even seen some unique uses of it (like Airpair used it to bring together mentors and clients). Of course, I only use the Slack app for my main job, and any side projects/open source I use the browser for :-)

</comment></comment><comment><USER41> People will complain all day about Slack, but somehow still use it.

If we are so concerned, why aren't we all moving to Matrix?

<comment><USER42> Because most Matrix clients are equally ridiculous, and the Matrix protocol is even worse.

<comment><USER43> _sigh_ \- if you are going to badmouth Matrix, please at least disclose that you are doing so from the perspective of working on an alternative standard (IRCv3).

That said, agreed that Riot/Desktop suffers similar problems to Slack thanks to being an Electron app. Pure Qt clients like nheko and quaternion have a lot more promise on the desktop.

In terms of the protocol: yup, the baseline Matrix protocol is plain and simple HTTPS+JSON. Patches welcome from anyone who finds this enough of a problem to provide alternative efficient transports :)

[disclosure; i work on matrix, although grew up on IRC, and respect the IRCv3 project, despite behaviour like this.]

<comment><USER42> I'm not an official member of the IRCv3 project, and can't speak for them - <USER2> only engage in discussions in the IRCv3 WG which affect the client I am working on.

That said, Matrix is a great concept, but, as mentioned, the currently implemented clients and protocol (with HTTP polling with JSON) are very inefficient.

With Quarternion as client, and a raw socket or websocket based protocol using Protobuf or Flatbuffers for serialization Matrix could actually become the fastest and most efficient open chat system.

You have to realize that I'm seeing this as someone who uses clients on 7 year old devices on throttled 2G in daily use, to ensure that they work well enough under any conditions. (And while some IRC clients do work there, any Matrix client is completely unusable under those conditions).

</comment></comment></comment></comment><comment><USER44> Isn't Slack just another example of what happens when developers want a "cross platform solution" instead of writing a native app?

<comment><USER45> No, Slack is what happens developers think that HTML/Javascript is a good platform for applications and that shipping a full-blown browser constitutes a native app. Qt is a good cross platform solution if you want cross-platform.

Although, I wonder if Slack is constantly sending and receiving status reports. I'd like to be able to set it to check every 5 min (or even 1 min) and see if that helped things. I don't need to be notified immediately; if they needed that they would call me.

</comment></comment><comment><USER46> There is a Slack client for Emacs: [https://github.com/yuya373/emacs- slack](https://github.com/yuya373/emacs-slack)

<comment><USER47> Slack also has an IRC bridge which you could use with erc or rcirc.

<comment><USER48> [https://www.codeux.com/textual/](https://www.codeux.com/textual/) :)

</comment></comment></comment><comment><USER49> I'm so glad he advocated for IRC. If we can get IRC to have inline images and chat history, we are good to go.

<comment><USER50> LimeChat on the Mac supports both of those features. I'm sure there are other clients that do as well.

And for history, there are plenty of history bots that have web searchable archives of IRC channels.

<comment><USER19> Weechat with Glowing Bear does too but it needs to be set up.

</comment></comment></comment><comment><USER51> Energy impact isn't a percentage. It doesn't have any units. I understand that the author is trying to prove a point -- and those points are valid, but it's not that Slack is consuming 63% of your energy. It's an arbitrary measure. [0]

> So, in conclusion, on 10.10 and 10.11, the formula used to compute "Energy > Impact" is machine model-specific, and includes the following factors: CPU > usage, wakeup frequency, quality of service class usage, and disk, GPU, and > network activity.

[0]: [https://blog.mozilla.org/nnethercote/2015/08/26/what-does- th...](https://blog.mozilla.org/nnethercote/2015/08/26/what-does-the-os-x- activity-monitors-energy-impact-actually-measure/)

</comment><comment><USER52> If only browser developers would agree on some standard to "Add web app to desktop". Something similar like Prism extension on Firefox was back in the day, except all apps would run on single browser instance. That should solve "electron problem".

<comment><USER53> Chrome and other Blink based browsers are doing this on Android already, PWAs can be installed to the device and are treated like a native app. (Except that they still use the web's more restrictive permissions model)

</comment></comment><comment><USER54> Can somebody tell me why a chat application should use 5% of a CPU and over 100MB per account?

<comment><USER55> Well, to be fair, it is much more than just a "chat application". It's now voice, screen sharing, etc.

They've built a lot of features with chat being at the core.

<comment><USER56> But why should any of those features consume system resources when they're not being actively used?

</comment></comment></comment><comment><USER57> At this valuation I would start shooting for writing native clients at this point. They even have an iOS client that has done half of the work for them at this point on OSX.

</comment><comment><USER58> Most people are upset with slack due to memory usage. I get that a chat app shouldn't use so much ram. But then there was a time even a browser wouldn't. This is how software has always grown. Windows XP minimum ram 64M, windows 7 wants minimum 1G. But we are all fine with it because the hardware has also grown. So to those who have a problem with slacks memory usage ask yourself: why are you using a machine with less than 32G of ram?

<comment><USER59> Comparing an OS and a chat client, really? Very wide conflation.

I'm fine with things using _a bit more_ resources, but not three or four orders of magnitute compared to 10-15 years ago.

It's all about quick time to market, various Electron-based "desktop app" maintaners have openly admitted it right here in HN (though not in this thread). Any technical disagreements were killed off with (1) we won't hire developers who are specialists in desktop development due to costs and (2) our app doesn't use that much resources, everybody has strong machines nowadays anyway.

</comment></comment><comment><USER60> Cgroups: limit memory, limit CPU, and voila - it works! Slack is one of the resource hogs that will take all that you'll give it.

<comment><USER61> could you post some examples of limiting slack with cgroups?

<comment><USER62> See "How do I use cgroups ?" in the kernel docs: [https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.t...](https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt)

You can do it simply by mounting the cgroup fs and writing numbers to files.

<comment><USER63> Seems like there should be a better solution than making every slack user read that document.

<comment><USER37> Sure, but sometimes we have to wrestle with shitty software. There's a scanning tool we use that unrestrained will consume all system resources, lock up all the useful software, and occasionally crash severs.

Set up a cgroup with a quota and problem solved.

</comment></comment></comment></comment></comment><comment><USER64> The answer: Electron and this new breed of lazy "developers" who can't be bothered to actually make decent native apps.

<comment><USER65> I know right. Real "developers" only write in assembly with a completely separate codebase for each target platform. No code review or source control either, because they're not lazy.

Actual issues aside (yes slack takes up way too much memory and it's due to the platform they chose which is hugely bloaty but will undoubtedly get smaller/faster over time just as everything does) why would you choose to attack the developers for building a tool that millions of people use with great success? They're not lazy. They used the best tools available to them to deliver their product and they're reaching the limits of said tools. Now they have to address those limits. This is exactly how software is supposed to work.

<comment><USER64> I choose to attack those developers because they're taking an easy path knowing that it will end up in a bad product, yet they still do it.

At the end of the day I don't care which technology is used as long as the end product is good, however a chat client that uses 1,5GB of memory is the total opposite of good. Come on, it's a f'ing chat client - a solved problem and existing implementations (look at any IRC client) take like 100MB's max. I would have no problems with Electron if they somehow managed to get the resource usage similar to a native app.

<comment><USER66> If its a "solved problem" then why aren't users flocking to IRC over Slack?

The answer is likely multifaceted, but part of it is undoubtedly the usability of the client - which may be resource intensive, but that was likely a trade off for speed/ease of development.

<comment><USER67> NIH Syndrome. You can't make a walled garden out of IRC.

<comment><USER50> Why can't you? You just don't connect your IRC server to any other server.

<comment><USER67> True, so maybe they're also hoping for patents or other ancillary NIH benefit.

</comment></comment></comment></comment></comment></comment></comment><comment><USER68> I wonder what I'm doing differently (or if it's my hardware) because I don't notice it consuming much, and it pales compared to resource hogs I run in my day-to-day. Maybe they develop on Macs and runs better on them?

Here's my specs if anyone is curious: 3 yr old MBP 2.3 GHz i7 16 GB RAM

</comment><comment><USER69> Turning off animations in the preferences (it's under "Accessibility") has done _wonders_ to the energy impact / CPU usage of the Mac Slack client. Much more tolerable now.

I am _more_ than happy to not see animated party parrots in exchange for less CPU.

</comment><comment><USER70> Maybe use Slack in browser?

<comment><USER60> Tried that, doesn't help a whole lot (the desktop app is a glorified Webkit wrapper).

<comment><USER71> But it's chromium serving local content. That is somewhat of a difference.

I run Slack only in Safari. It works significantly better than the desktop app.

<comment><USER60> I don't think serving local content would explain why the desktop app insists on munching through all the available RAM (on a single team, no less!), something else must be going on. But that's actually a pretty good suggestion - I'll try the web version, thanks.

</comment></comment></comment></comment><comment><USER72> Why don't you guys use rambox? It basically loads slack's web interface in the client. And it supports a plethora of instant messaging services. Never had any issue with performance.

<comment><USER73> I had never heard of this. Interesting. It looks as though this is built on Electron too.

</comment></comment><comment><USER74> > I love Slack and have no plans to stop using it to communicate with my team > at Ably.

As long as your willing to tolerate it don't expect anything to change. If people stopped using slack then the bean counters would sit up and take notice. If slack died it might even serve as a warning to others.

It's easy to blame slack, but everyone that continues to use this and other bloated apps are also part of the problem.

</comment><comment><USER75> On my desktop, Slack's footprint looks pretty similar to Atom's, hardly shocking given they're both Electron apps. Its 4 pids aren't using much CPU (less than 1% each), and about 800MB of RAM combined. Sure, that's kind of ridiculous for what it's doing, but it's about 1/20th of my total resources or less...

</comment><comment><USER76> The latest version of slack BETA solves the CPU issues on OSX. I have been using it and its _so much better_.

<comment><USER77> I'm on Slack beta as well. I have nine Slack groups, with some of them having thousands of users. It's still a CPU hog.

</comment></comment><comment><USER78> Sounds ridiculous that a chat app can consume that much.

Could we maybe use a terminal client? Seen this : [https://github.com/evanyeung/terminal- slack](https://github.com/evanyeung/terminal-slack) but I cannot build it. Anyone else tried it?

<comment><USER55> How would this work when a team member attempts to screen share or video/audio call?

<comment><USER78> That rarely/never happens to me. I use it for chat 95% of the time, the other 5% might be someone posting a gist or quoting some code. So for my use, a terminal client is more than enough.

</comment></comment></comment><comment><USER79> What's it _doing_ in there? Refreshing the screen on every frame, like a video game?

</comment><comment><USER80> I always try to run a web version of this stuff. Web music player, web Slack, etc. Don't need more garbage on my machine, and since it's essentially a bundle of Chrome, it's good enough to just use it in the browser - where it belongs.

</comment><comment><USER81> Yea, I usually browse in Firefox and keep the Slack desktop app open, but when I'm on battery for more than a few minutes I'll kill both and switch to Safari with the Slack web app opened in a tab. That practically doubles my battery life.

</comment><comment><USER82> I am getting really fed up with Slack and other CEF/Electron apps. Between Slack, Spotify, Atom, Adobe CC, and Firefox (the one program that isn't running on Chromium), I have no RAM left.

Why does Spotify use 1 GB of RAM, and 1 GB of swap?

</comment><comment><USER83> Gee I wonder why he wrote this article

> Co-founder of Ably: Simply better realtime messaging.

oh...

<comment><USER84> I had that feeling too when the article was that light.

<comment><USER53> If you check out the site, it's not actually a competitor to Slack at all.

Slack is for one human to message another human, not for one application to message another application.

</comment></comment></comment><comment><USER85> electron vs native app...

</comment><comment> vladimir-y Slack client for Mac OS to be exactly. Browser version works just fine, don't use any client app.

</comment><comment><USER86> i had to give up on using slack for multiple teams because of this

</comment><comment><USER87> Guess they are pretty slack in terms of resource usages.

</comment><comment><USER88> ehh, the author is a co-founder of Ably, a real time messaging platform, which competes with Slack in some areas.

<comment><USER89> I'm a happy user of Ably, and I can't think of a single place where it competes with Slack. Can you point out where they are competing?

</comment></comment><comment><USER90> On a related note: I would like to know if there is a project/fork that brings the oldschool threaded model for a browser. Is there one?

A single app with one purpose should all run in-process and use threads to schedule work.

</comment><comment><USER91> Slack might have 1.5 GB mapped between all of its processes but probably most of the processes many of the same pages, so it's a bit misleading to say Slack uses up 1.5 GB of "real" memory.

<comment><USER92> Exactly this. The "Memory" tab in activity monitor is next to useless. It doesn't give you any idea how much of that memory is shared, exclusive to the processes, paged out, etc. Each of those processes is using some fraction of the amount displayed in the 'Memory' column.

</comment></comment><comment><USER93> I would pay money for a Slack client that doesn't bog down my machine. Has anyone reverse-engineered the protocol?

Of course Apple deserves equal blame for selling machines with limited RAM.

<comment><USER41> What about not paying money and supporting alternatives? Such as Matrix?

[http://matrix.org/](http://matrix.org/)

<comment><USER93> Does Matrix let me see Slack channels for existing projects? If Matrix can replace Slack, I'd consider using it for new projects. But if not, that just means running both apps.

I, and many people I work with, already have Slack running for other projects. Often projects where I didn't get to choose the system.

<comment><USER43> one of the big things in matrix is the existence of bridges as a first class citizen. matrix-appservice-slack exists today (and riot.im hosts an instance of it; you can get at it via Manage Integrations in Riot). The catch is that right now it needs to have outgoing/incoming webhooks provisioned on the Slack channel being bridged. We are working on fixing this with a puppeting bridge though - and there are a few other projects like matrix-puppet-slack which also aim to do this already. [https://matrix.org/blog/2017/03/11/how-do-i- bridge-thee-let-...](https://matrix.org/blog/2017/03/11/how-do-i-bridge-thee- let-me-count-the-ways/) has the gory details.

</comment></comment></comment></comment><comment> pablo-massa We have digital assistants that can match photos by time+location+people and create complex results, why OSes don't have (natively) elaborated and user friendly alerts/solutions when apps do detrimental stuff like that?

We can blame Slack in this conversation but I think an equally interesting discussion resides on the OS side, who can avoid not only Slack to be so detrimental.

I think UX sometimes get too much attention on the flashy/entertainment side and performance/speed is overlooked (look the state of websites).</comment>


Don't US Kids Deserve the Right to Be Forgotten? - <AUTHOR> http://anewdomain.net/2015/08/03/dont-us-kids-deserve-right-forgotten-infographic/

<comment><AUTHOR> The idea of a "Right to be Forgotten" in practice always seems to me like claiming a right to make other people loose their memory (even if electronic). That is at best problematic.

However, as this infographic shows, kids now are affecting their futures in ways they can't possibly understand.

Any thoughts on a solution?</comment>