What RESTful actually means - <AUTHOR> https://codewords.recurse.com/issues/five/what-restful-actually-means <comment><USER2> REST is the definition of a buzzword. Vague. Useless. Everyone talks about it, but no one ever 'understands' it. You make your API REST not because you think it's good, but because everyone else does it. It's instant karma. Like XML was 10 years ago. Who cares if you have to make a lot of ugly confusing endpoints - at least you can call your API RESTful.

I like how Dropbox bucked the trend and went with a simple POST based API. JSON parameters in. JSON response out. No complicated urls, strange headers, verbs, hateoas, etc..

[https://www.dropbox.com/developers/documentation/http/docume...](https://www.dropbox.com/developers/documentation/http/documentation)

<comment><USER3> > Everyone talks about it, but no one ever 'understands' it.

There are people who understand it to varying degrees. Some who completely understand it and some who don't understand it at all.

So no, it's not a buzzword, it's just a concept.

PS. Dropbox's API requires a lot of hardcoding because of that very switch. Hardcoding that HATEOAS lets you avoid.

<comment><USER4> With REST we cannot truly define a degree of understanding. Such a definition would assume that multiple people know and agree on what would be the full extent of that understanding. The problem with REST is not the different _amount_ of knowledge that people possess, but the different _ideas_ that they have about REST. Which is another way to say that REST is not really a well defined protocol. (Have you seen similar vague posts titled "What IMAP4 actually means"?)

Because it is not a well defined protocol, you cannot use the same client library to access random REST APIs. You use/write one library to access Twitter's REST and another to access Facebook's REST. You could argue that you use HTTP in both cases, but that's just the underlying transport protocol - not the API "language" itself. Because of that fact I blame REST for the millions of developers hours wasted in re-implementations of hundreds and thousands versions of the same "concept".

The REST "idea" sure looks sexy when you put it next to an atrocity like SOAP, but that's one of its very few merits.

<comment><USER5> > Because it is not a well defined protocol, you cannot use the same client > library to access random REST APIs.

You misunderstand what REST is. It's not a protocol, it's an architectural style. Of course you can't build one client library to access arbitrary REST APIs – that's like complaining that you can't build an object-oriented library that can be used by any object-oriented language.

REST does, in fact, have a precise definition that is possible to understand and agree on. It's here:

[https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...](https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm)

</comment></comment></comment></comment><comment><USER6> Related:

Twilio Conference 2011: Steve Klabnik, Everything You Know About REST Is Wrong: [http://vimeo.com/30764565](http://vimeo.com/30764565)

REST APIs must be hypertext-driven: [http://roy.gbiv.com/untangled/2008/rest- apis-must-be-hyperte...](http://roy.gbiv.com/untangled/2008/rest-apis-must-be- hypertext-driven)

Hypermedia APIs - Jon Moore: [http://vimeo.com/20781278](http://vimeo.com/20781278)

Designing a RESTful Web API: [http://blog.luisrei.com/articles/rest.html](http://blog.luisrei.com/articles/rest.html)

</comment><comment><USER7> RESTful doesn't mean anything no more than REST means anything, precisely because it's NOT A PROTOCOL and THERE IS NO NORMATIVE SPEC. All this fiasco is due to a vague set of ideas that are in practice no more than JSON-RPC with a http header.

I'm sure you can find 50 developers that will disagree on your definition and that's what hurts all the REST advocates. Your definition is as valid as theirs, until there is a spec that explains precisely what REST is. There is none, there is no normative spec, period.

SOAP has a spec, RPC has a spec, GraphQL has a spec. "REST"(full) has no spec, REST is whatever you think it is.

<comment><USER8> > REST is whatever you think it is.

Nonsense. REST is what Dr. Fielding says it is, because he coined the term.

<comment> t-schill And REST as Dr. Fielding says it is is not as practical to implement as it should be. Hence the need for RESTful which just draws influence from his work.

<comment><USER8> What makes REST impractical?

And if REST isn't practical, we should use a different term to describe what we implement instead.

The meanings of words should be immutable, to avoid confusion. No, that's not how language has historically worked, but we can do better. After all, there are a lot of things we have historically done that we don't want to keep doing.

<comment><USER9> Why would speaking a human language without nuance, without any possibility of misinterpretation, be a step forward?

It's spelled ReST.

Does that better convey what it _means_ in that string of characters? Maybe for some values of human. But words are for humans, and humans are not immutable, so our words shouldn't be.

<comment><USER10> _> It's spelled ReST._

Really? It's been capitalized REST everywhere I've seen it.

Including here: [http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm)

You weren't thinking of 'reST' (reStructuredText) were you?

<comment><USER9> No, I was thinking of Representational State Transfer, which is what Fielding's paper talks about. And I was also thinking about how people say RESTful, and how that's a confusing way to say "conforms to how Roy Fielding thinks an API should behave."

What I was responding to was advocacy that _human_ language should behave the way we expect RFCs to work.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> REST isn't a protocol, it's an argument for an approach to systems architecture that minimizes coupling between components while maximizing client reuse.

I've designed and operated several REST-inspired systems over the years, and let me warn you: it's no walk in the park. Engineers that want to "get it done now" must be convinced not to huck everything up to the server as a POST. Founders have to see the business case for every new system. Other departments may have to relearn tools for interoperating with the systems. It's a whole big deal. You can't deploy a RESTful solution and avoid dealing with _people_.

For your effort, you'll receive a system with well-factored bounded contexts whose self-descriptive interfaces interoperate with standardized tooling and monitoring systems. Projects can be factored into tasks along clear domains and often incrementally delivered into production. Life-sucking productivity projects like the _secret admin website_ can be pushed off indefinitely. Problems will be simple to isolate and reproduce. You'll have the flexibility to rush out brand new client experiences on tight deadlines.

Notice how none of the problems or benefits really involve a particular technology tool or framework or language?

In my opinion, ignorance of the significant cultural factors required for a successful deployment of a RESTful system is _the_ reason why articles continue to be published about how it's vague or difficult or whatever.

<comment><USER12> There are lots and lots of open source web applications out there. I like to read code to see how things are being done. Can you point to any web application out there, with source code available to read, that is built in the way that you are describing?

</comment></comment><comment><USER13> For me personally, the two most important constraints for a legitimate ReST application are:

\- HATEOAS \- registered mime-types

In particular, the use of registered mime-types. An example:

Say we are building a restful music service similar to Spotify. Say we focus on the list of as users playlists. We can embody the currently logged in users list of playlists as a resource with a specific URL. This URL is opaque to both the client and server.

The representation of this list of playlists could be in the form of a Json hash where key is the playlist name and the value is the URL for the playlist itself.

We also could declare that the following interactions are available to any client that receives this payload from a HTTP GET request: \- Create a new playlist \- delete a playlist And therefore we can fulfil the HATEOAS requirement.

As I understand it, in order to make this restful we must register this as a custome media type as the additional actions we have defined are part of the available interactions with this media-type.

Don't confuse the content of the representation with a definition of a media- type; we could declare our custom media-type as so:

Application/vnd.spotify.com.list.playlists+Json

It is the definition of the media type that dictates that the HATEOAS links in the header with the rel type of create or delete of how clients should interpret them. It is this media-type that dictates this.

It is my understanding that pumping raw Json over http, even with HATEOAS in the headers (or even worse, with links embedded in the Json with the out of band knowledge that a client should interpret our key/value pairs as hypertext based only on the resource URL) is not in anyway restful.

</comment><comment><USER14> Attempting to define REST is the best way to troll web developers.

</comment><comment><USER15> RESTful is not a spec, as has been pointed out: it's an idea. It's much more like other large-scale design patterns than it is a protocol. Think "object oriented," or "procedural," not "http" or "tcp." There is only one correct way to implement/use a protocol, but there are many valid expressions of a pattern or idea. It's more or less accepted, I think, that the vast majority of "RESTful" implementation don't obey all the original (15 year old!) guidelines.

<comment><USER16> It is far more (fundamental) and less (design patterny) than that.

It is akin to to functional programming or declarative database queries. Neither of these are large-scale patterns.

They're both very much about a sane, easy to understand api.

</comment></comment><comment><USER17> > Stateless does not mean that servers and clients do not have state, it > simply means that they do not need to keep track of each other's state.

For this reason, I've always thought that the term "stateless" is confusing. Maybe "client state independent" (the response that the server sends back is independent of the client's state)? I don't love that term, any better ideas?

<comment><USER15> I don't think it's confusing because it says exactly what it is supposed to say. 'Stateless' is not a property of the client, or the server, but of the relationship between them, and that relationship is expressed in the protocol they use to communicate.

<comment><USER4> The relationship between client and server is not stateless in the majority of the cases. Most of the implementations rely on authentication state (cookie, session secret). Very few actually do the stateless part right.

<comment><USER18> If your authentication token times out, it's not ReST.

As simple as that.

<comment><USER19> If you're using an authentication token, it's not really REST. Because of the dire situation wrt. client certificates, the only straight-forward, "pure" REST, would be to supply Basic Auth on every request (that doesn't allow anonymous access).

I'm not really convinced that's _not_ a good idea for a TLS-only service (compared to the complexities that tokens/cookies introduce). One reason why there was a move away from Basic Auth was ofcourse that it is crazy to send plain-text login/password pairs over a plain-text transport (HTTP sans S).

And there's never been any working, cross-platform effort to improve things (AFAIK).

There's some work on Kerberos that's interesting, but again, many of these efforts have been simply co-opted by the fact that everyone used cookies (and had problems, and started encrypting them etc), and _then_ moved from HTTP to HTTPS.

When you have HTTPS, there's not that many reasons to not just have "SECRET PASSWORD" in the URL (granted that'd not be REST either, but BASIC AUTH does the same thing, just in a header).

<comment><USER18> Indeed, this is the point I wanted to get to.

If you have to do a challenge-response auth every 5 requests, or so, to get a session, then it's not really rest.

Client certificates might actually make the most sense in this case.

</comment></comment></comment></comment></comment></comment><comment><USER20> I'm reading here that a big problem with many REST APIs is that they don't go all the way with the concept. They fall short of the total, so miss out on the overall benefit.

But if there are any here who are strong advocates, I truly want to know, how do we authenticate in a REST compliment way in practice? Must we, as was pushed early on, only use HTTP basic auth, and resend credentials with each request? Or do we treat the session itself as resource, and somehow refernce it in requests for all other resources? Or are session cookies somehow exempt from the rule that _interactions_ must be stateless?

<comment><USER21> Actually, they are all valid ways when using the ReST philosophy. The idea is that with every request from the client the latest state is sent along with it (if needed). This way the state of the request can be reconstructed on the server without depending on centralized storage or a single server. The server may update the state and return it for the client to store again (some parts encrypted if needed). No need for the server to keep the state (this way it can remain stateless).

HTTP basic auth does this automatically.

Creating a resource for a session is optional but may be useful if the state to sent back and forth is too big. But this will require centralized storage.

The state may be stored inside a cookie where parts of it can be encrypted. It is also possible to specify that parts can only be updated by the server.

You may also use Local Storage and send the data across using an XMLHttpRequest or even use a HTML form (which may have limited support for the HTTP verbs).

Read my other comment for more information.

<comment><USER20> But it seems to me that ReST _does_ dictate, specifically, that there must be no need for shared state. The system _must_ work without the client having knowledge of the server and vice versa. But a cookie, as used to hold a session token which references information on the server, is very much shared state. So should be forbidden.

<comment><USER21> The state is passed back and forth. The server does not keep the state (that is why they call it stateless), the client may keep it. If something does need to be stored on the server a resource should be created. The state that is passed back and forth may then contain a reference to the resource, a resource identifier (in case of the web usually a URI is being used).

The server is stateless because it receives the latest state from the client (location, cookie and other headers) and sends an new updated state (location, set-cookie and other headers) to the client again along with an optional representation. There is no need for the server to keep the state in memory anymore. Because the server does not keep the state it does not matter which copy of the server (in case of load-balancing or fail-over etc.) handles the next request as everything needed can be derived from the state sent along with request from the client.

Keep in mind that it is best practice to be able to reproduce a representation by the use of a resource identifier, like with "pure functions" in functional programming, it should be deterministic. The content of a representation may change but not the semantics of it.

The part that is stateful is the state that is being passed back and forth between the client and the server.

Does that answer your question?

</comment></comment></comment></comment><comment><USER22> Here's a link to a rant I wrote earlier this year on the same topic

[https://medium.com/@vrashabhirde/will-the-real-restful- api-p...](https://medium.com/@vrashabhirde/will-the-real-restful-api-please- stand-up-ea612a92b9a9#.88ft4t66s)

(edited again to make it less rant-y and offensive and more useful)

</comment><comment><USER23> Can someone suggest an example of "true" REST API, complex enough (not trivial CRUD stuff like blog) to be used as a real-life example?

<comment><USER24> I look to Stripe's API as the ultimate REST example - [https://stripe.com/docs/api](https://stripe.com/docs/api).

It's very complicated and follows the pattern very closely.

<comment><USER25> Stripe's API is good, but it is far from the "ultimate REST example." What is the statistical sample set of APIs that you are comparing from?

From my experience, I would suggest something like Twilio, Github or FoxyCart as the epitome of a REST API.

</comment></comment></comment><comment><USER26> ELI5 for a non-developer?

I always thought it was just a way of sending commands or data to a sever. I created a RESTful (I think) service on a Raspberry Pi that powered on a light every time it got an alert from Salesforce. It did this by POSTing to power.py and parsing in some variables. Is that RESTful?

<comment><USER27> REST is a series of principals used to structure APIs. Think about if you had a lot more lights on your Raspberry PI. A simple way would be having a call lighting up a specific light. But then the client must track state, in terme of rembering which lights are lit. In a REST sister, you'd request the state of all the lights (typically through a GET http request), which the server would track for you. Then you'd send back the lit or unlit state of all the lights, thereby setting a new state (typically, again, through an http POST request).

<comment><USER28> I don't see anything non-RESTy about your former example (and would argue it's a BETTER protocol design).

Imagine we want to change the state of light 7 (and only light 7).

A PUT/PATCH of "ON" "OFF" (or 1 or 0 or a float for a dimmer) to [http://raspberry1.local/lights/7](http://raspberry1.local/lights/7) to change the status of light 7 is better IMO than doing a GET to [http://raspberry1.local/lights](http://raspberry1.local/lights) and then a PUTS/PATCH to that same URL to update all lights status for the purpose of just updating one light. The latter is obviously fragile in the face of multiple writers (you'll lose updates on overlapping but not colliding writes- an update to light 6 that overlaps in time with light 7 can result in the earlier of those updates being lost when there's no inherent reason for it).

<comment><USER29> It really depends on the amount of calls you'll have to make. What if you had 10,000 lights? What we tend to do is allow for partial updates with PATCH on just the lights you'd want to change.

ie

PATCH [http://bla/url/lights](http://bla/url/lights)

{ light1: ON, light351: ON, light 4672: ON }

I think that since generally documentation around RESTful API's is generally very good with in-browser demo calls, interpretation of the REST API although differs between implementors, is generally relatively similar enough.

However there are cases where REST design just won't work, or implementing the design abstracts work from the API supplier to the consumer. Where once a "runThisScript(object)" would be easy enough for a developer, now the script itself must be implemented by the developer to call the RESTful endpoints.

In cases like this, we occasionally break REST design for the convenience of developers.

<comment><USER30> Nothing about this alternative version is any more or less RESTful than the original version.

<comment><USER29> Generally HTTP REST works on the idea of resources and properties.

so: /lights /lights/light-id /lights/light-id/wattage (return wattage of light)

Doing something like:

/lights/light-id/book-janitor-to-replace which might email and update the janitor's calendar/ToDo list, isn't really following the existing API design.

<comment><USER31> What do you mean "following the existing API design"?

A good API imo would hide the janitor's calendar/ToDo list unless it was absolutely necessary for the client to access it directly. Then an argument could be made in favor of the booking janitor endpoint on a light - and the API is no less RESTful.

Edit: I don't like it when people over-emphasize resources when talking about REST. I blame this practice on Rails being many people's first introduction to REST. But Rails isn't actually RESTful per Fielding. I prefer to use the term resourceful API to describe the kind of API Rails prescribes. REST is generally in favor of custom endpoints that hide complexity from the client, even at the expense of having a clear cut decision on eg. POST vs PUT/PATCH for a given endpoint.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Have been using the ReST philosophy (or pattern?) for almost 15 years without any issues. ReST itself does not define the use of a specific technology and is not a standard by itself, it is pretty abstract. Using the URI and HTTP standards are just a way to apply it. Other technologies can be used as well, like SMTP / MIME or something developed yourself as soon as the ReST constraints can be applied. Adding the ReST constraints is what brings the advantages. It is really flexible and allows for easy composition of "layers" through "connectors". A caching proxy is an example of a "connector". If ReST could be compared to something in programming it is very similar to "monads" as used in functional programming.

Recursion can be done by the use of nested "resource identifiers" (SSI or ESI for example) inside the returned "representation". A "connector" may then decide to do another request to replace the "identifier". If the "connector" uses caching it may not even need to do another sub-request. I use this to do something like what Facebook's Relay does. As the full state is always being sent along with every request it is very easy to scale because the servers, wherever they are, always have enough context to be able to work with it. A server may even ignore what it does not understand for the next layer to handle it called "partial understanding" which is supported by XML for example. Unfortunately when using JSON most of these advantages are lost. That is why I prefer a less verbose "XML Infoset" similar to JSON while still keeping all the advantages.

</comment><comment><USER32> This is sorta helpful. But what would be illuminating and almost never gets done is the very simple description of what a real world API would look like that corresponds to the description. And there are zillions to choose from to take a crack at.

</comment><comment><USER33> If you have an interest in distributed computing "The End of Protocols" is a great read:

[http://www.cc.gatech.edu/~keith/classes/ubicomplexity/pdfs/i...](http://www.cc.gatech.edu/~keith/classes/ubicomplexity/pdfs/infra/waldo- end-of-proto.pdf)

The whole RPC vs. REST thing is not a useful distinction.

</comment><comment><USER34> my only question regarding RESTful api's is... is it really that hard to implement?

I know there's a few set of rules/principles to follow but in the end, I just see "lets make a readable and easy-to-understand API that has a nice set of plural "subjects" with the basic HTTP request verbs all nicely applied.

I ask this because I noticed while applying for jobs, that some people hiring simply want someone who can write a REST API but I just didn't see it as a big deal when you're hiring a web developer as long as he has the experience and good mentality for creating organized code.

</comment><comment><USER35> Also there is this 5 year old book "REST in Practice" which defines several levels of RESTfulness

</comment><comment><USER36> I ask candidates to explain this when I interview them. I read that first paragraph and was upset/unsurprised.

<comment><USER37> What do you expect them to respond? It's not very well defined.

I would probably say...

""" REST, like many great religious philosophies, combines with one's life experience to mean something different for every pair of eyes that looks at it. For me, it's something which has URLs for resources of the form

        /<class_name>(/<instance_id>(/<custom_method>)?)?

and default HTTP methods of GET / POST / DELETE to read / modify / remove instances. Finally, while I realize this is a bit too implementation detail-y than most definitions, my mind is not really at rest unless an HTTP API respond with JSON and reference other instances in some standardized way.

You will notice the repetition of sets of 3, and that's because 3 is my favorite number. I also really like the Stripe API's way of specifying arrows to related content to "unfold" references in the JSON response. That really puts my mind at rest when I see it, so that's RESTful, as well.

To get a little more real, though, REST is totally the old hotness and verging on not even being that hot. All the cool kids now know to use GraphQL, and if you aren't at least planning to transition to it, I'm not really interested in working here unless you pay me a lot of money. """

How'd I do?

<comment><USER38> Well, strictly speaking if your having to explain the structure of your URLs then it's not really fully REST (because of HATEOS) and I don't think there is any requirement for a RESTful interface to return JSON.

But having said that I've got the point where I don't really care - if I can interact with an API from curl without too much difficulty I don't care if the API is fully REST or not.

<comment><USER37> I'm deeply offended that you called my URL structure un-REST-ful and challenge you to come up with an API spec that's more REST-ful than mine.

</comment></comment></comment></comment><comment><USER39> So what do you call a system that uses more than two HTTP methods (e.g. uses PUT and DELETE as well as GET and POST), and has marginally-more-human- readable URLs, but doesn't send self-descriptive representations, doesn't use hypermedia, doesn't Transfer REpresentational State, and probably also isn't stateless?

I mean, statistically speaking, if you have such a system, my bet is that you call that system RESTful. Furthermore, if you have such a system, you vastly outnumber the people building systems that obey Fielding's constraints. So in practice, you win the argument about what "RESTful" means.

Can we please stop legitimizing Rails's whimsical aesthetic choices by pretending that they have something to do with an academically-justified architecture, and just accept that they're just another way of ripping your denim and then safety-pinning it closed, by which you demonstrate that you're not a square and you don't write Java.

<comment><USER40> > _Can we please stop legitimizing Rails 's whimsical aesthetic choices by > pretending that they have something to do with an academically-justified > architecture, and just accept that they're just another way of ripping your > denim and then safety-pinning it closed, by which you demonstrate that > you're not a square and you don't write Java._

Please don't do this here. Snark like this is good for starting technical flamewars but it invariably lowers the quality of the discussion.

<comment><USER41> Even though you're right this line almost made it all worth it in terms of comedic value: "...accept that they're just another way of ripping your denim and then safety-pinning it closed, by which you demonstrate that you're not a square and you don't write Java."</comment></comment></comment>


Google Caught Funding Slew of Right-Wing Front Groups - <AUTHOR> http://www.progressive.org/google-caught-funding-slew-of-right-wing-front-groups <comment><USER2> I guess the title is linkbait for progressives. Google disclosed this information, so it's hard to see how that translates to "caught". And CATO and Heritage make no bones about being libertarian and conservative, respectively. They're hardly "front groups".</comment>


How to make the non-intuitive neo-Darwinian synthesis more intuitive - <AUTHOR> http://cogsciresearch.blogspot.com/2013/01/is-neo-darwinian-synthesis-intuitive.html <comment><USER2> But, the author has not explained why you get such elegant and complex results as a result of removing the constraints of time and space.

Evolution selects traits which will spread throughout the population most easily. This does not imply that they are "better", more complex, or elegent. (Think of all the terrible memes that have a hold right now for example). Adding time alone does not improve the outcome.

I think the author needs to look a bit more into emergence. See Kauffman: [http://www.edge.org/3rd_culture/kauffman06/kauffman06_index....](http://www.edge.org/3rd_culture/kauffman06/kauffman06_index.html)</comment>


Tours Offered at Amazon Fulfillment Centers - <AUTHOR> https://www.aboutamazon.com/amazon-fulfillment-center-tours <comment><AUTHOR> Could be interesting to see the robotics. Also reminds me of a South Park episode.</comment>


CabooseConf (Rails) - <AUTHOR> http://rubyjudo.com/2008/2/1/cabooseconf <comment><USER2> I'll gladly catch a train to Portland for a cheap rails conference that doesn't suck....

</comment><comment><USER3> I was going to launch pre-Railsconf and maybe recruit there, but this gives me an extra week or two of leeway... and hopefully filters out the corporate types, so I'm sold!

</comment><comment><USER4> Thank god for this. Railsconf '07 was awful.</comment>


Crushing the Impostor Syndrome - <AUTHOR> http://www.cyclonelife.net/2013/07/crushing-the-impostor-syndrome/ <comment><USER3> I can relate to this. I wonder if forums like HN exacerbate it -- here, _someone_ is always an expert on whatever you're talking about, just by the sheer volume of folks who come here. So it sometimes seems like everyone is a published expert with a sweet funded startup using Haskell and Go and algorithms I can't comprehend, fending off offers from Google and Facebook.

It's easy to forget that there are a lot of programmers diddling with enterprise java and php on a day to day basis, not doing anything particularly mind-blowing, just dutifully closing their tickets.

<comment><USER4> This. And we also do it to ourselves when looking for work, exacerbating the problem and pushing onto future IT personnel. Just look at the job descriptions for most IT jobs out there and you'll see that IT personnel are expected to know way too much, when really you just need the fundamentals (everything else can be learned just-in-time). I've written a much longer answer detailing a specific job description that helps flare up my imposter syndrome: [http://typicalrunt.me/2013/07/29/a-response-to-crushing- the-...](http://typicalrunt.me/2013/07/29/a-response-to-crushing-the-imposter- syndrome/)

</comment></comment><comment><USER5> This doesn't come up in the article, but everyone who has talked to me about their imposter syndrome has been a woman. All of quotes selected by the (female) author are also from women. I've found it really frustrating how much learned self-doubt some of the most talented and intelligent people I know (who happen to be women) seem to struggle with. I think this shows how important successful female role models are for young women, especially in male-dominated fields like business and programming. edit: fixed typos

<comment><USER3> Just spitballing here, but in my experience guys tend to not open up about their imposter syndrome, perhaps because it shows weakness.

<comment><USER6> That could be true. I know I have a pretty heavy case of imposter syndrome, but in times of my own egomania I like to think that it's actually just the other side of the Dunning-Kruger effect. As long as it isn't debilitatingly severe, imposter syndrome seems more like the trademark of a humble man (or woman). What's wrong with that?

<comment><USER7> Humility is great, but when people call something a "syndrome" (a word usually associated with disorders/diseases), they usually mean that the thing is interfering with your life - humility taken too far, to a degree that is making you feel worse and causing problems for you.

Impostor syndrome can mean that you have difficulty taking pride in your work (since all you can see are the problems with it), which makes it difficult to share your knowledge - which isn't good for other people who might want to know about it and learn from it, and isn't good for your reputation and career growth.

Impostor syndrome can also mean that it's hard for you to ask questions (and admit that you don't know something!), since you're worried that you don't know as much as you should, which makes your work harder.

Not taking pride in your work and not asking questions also means that you're not really being the best role model for people looking up to you - <USER2> coworkers, people who work for you, volunteers who help with your project, etc.

(This is based on what I learned from the impostor syndrome presentation described at [http://adainitiative.org/2013/06/kicking-impostor- syndrome-i...](http://adainitiative.org/2013/06/kicking-impostor-syndrome-in- the-head-lessons-from-adacamp-dc-and-sf/) .)

</comment></comment></comment></comment><comment><USER7> For anyone who suspects they might have a bit of impostor syndrome, here are more resources for figuring out how to identify it and deal with it: [http://adainitiative.org/2013/06/kicking-impostor- syndrome-i...](http://adainitiative.org/2013/06/kicking-impostor-syndrome-in- the-head-lessons-from-adacamp-dc-and-sf/) (a video and transcript of a talk and an exercise). Here are also the slides: [http://www.slideshare.net/dreamwidth/kicking-impostor- syndro...](http://www.slideshare.net/dreamwidth/kicking-impostor-syndrome-in- the-head)

I went to a presentation of this talk at OSCON last week, and there was a big audience of both men and women of various ages and backgrounds. I'm pretty convinced that educating people about impostor syndrome is important to a happier, more diverse, and more productive tech community; it's holding too many of us back.

</comment><comment><USER8> I feel my most satisfied when I pull off things that impress me. Not others - sometimes others get easily impressed. If I go on too long without doing anything that I can pat myself on the back with then I start feeling like an imposter... just buying time before someone figures out that I'm a fake.

</comment><comment><USER9> Imposter syndrome is our natural social/emotional protection against 'knowitall' syndrome where you speak and act confidently when you are unqualified and mislead people. The ability to speak and act confidently is a learned social skill, normally you are supposed to learn it by peers validating/respecting you/you respecting yourself. But the process can be shortcut by imitation and 'faking it till you make it'(e.g. The type of confidence sales people tend to have doesn't run as deep imo)

</comment><comment><USER10> I think a lot of happiness in life depends on having realistic expectations. Sometimes you need to look around and realistically assess your co-workers. Are they all great? Are they all great all the time? Do they have some flaws? There aren't many perfect people and one shouldn't hold themselves to that standard. Tough to do.

</comment><comment><USER11> I tend to bounce back and forth between "Impostor syndrome" and "Dunning–Kruger effect". I guess that makes me about average?

</comment><comment><USER12> How much money is Iowa State University blowing on this blog themed advertising scheme?

<comment><USER12> [http://whois.net/whois/cyclonelife.net](http://whois.net/whois/cyclonelife.net)

</comment></comment><comment><USER13> It's also a common meme to believe in "10X programmers", and it's things like that that makes me the most insecure. I am content with not being the best at what I do for a living (in the future - I'm a student), I might even be content with being very average at what I do. But I don't want to be average if that means to be a "1X programmer" who's paycheck and productivity is for the most part subsidized by the 10X programmers, either by them being on my team or them being halfway across the world as contributors to libraries and what have you.

Well, we're all standing on the shoulders of giants, so that last part might be framed very pessimistically. But I just don't want to be programmer that either brings a comparatively little to the table or even a net negative of contribution on bad days, who _has_ to have some mythical 10X programmer in my vicinity (on, say, my team) in order for me to get anything remotely useful done.

It's only partly about self-esteem: if I don't have a talent for this gig, I want to find out about that so that I can get out gracefully. So it's not just a question of thinking positive and getting better self-esteem, it's also a question that has practical implications.

<comment><USER14> I work for an organisation who's business model depends on users completing a very long and complex legal form.

The form is paper-based, because it requires a number of signatures to make it legally binding. They brought in a consultancy to move the whole thing online. They've been at it for a year and a half. I started wondering what it was that's so difficult.

The consultancy created a form in which fields, guidance and rules were hard- coded. Part of what took them 18+ months is that the client kept making changes to form guidance.

I got myself a printed version of the form and used it to create a form- builder, which simply generates HTML. A non-technical business admin can change field sequences, guidance, and business rules using a simple UI, and publish those in real time. That took just 3 days.

When I demonstrated my proof of concept I got those 10x comments. Guess what. I'm a festering pile of shit as a programmer. But I've been doing this for 20 years, and have solved this little problem many times in those 20 years. I didn't write much code. I just copied and pasted stuff I had lying around, renamed some entities and methods, and put it onto a server.

It really is just experience.

<comment><USER15> I think that having the context to recognize a problem and solve it at a meta level means, almost by definition, that you aren't a "festering pile of shit as a programmer".

Programming isn't just about writing great code, it's about solving problems. Sure, one problem to solve is having code be extensible/maintainable, but it isn't the only one.

I don't care what shiny new code is written with the latest framework; if it doesn't solve a business problem, it's bad code.

</comment></comment></comment><comment><USER16> Maybe I'm an exception then, because I can't relate at all to this. I've got enough interesting thoughts inside my head that takes up most of my concentration, so I would not have time to care about what others do and don't.</comment>


(Deliberate) practice makes perfect: how to become an expert in anything - <AUTHOR> https://medium.com/swlh/deliberate-practice-makes-perfect-how-to-become-an-expert-in-anything-ec30e0c1314e <comment><USER2> >Why regular practice isn't enough Typically, repeated practice takes us up to a medium level of success. After an initial spike, progress stalls, plateaus — then grinds to a halt.

>Because when you reach an average level of competence, your ability stops being a work-in-progress and starts being a reflex.

I've seen this time and time again. Whether it be at starting a new workplace, or playing some sport or video game. If you have ever played and online competitive game, I'm sure you will have seen people with _multiple_ thousand hours, who are still only in the top 40th percentile (or even lower). They start this new game, or new job or new activity, go through a learning process and then just... stop. From there on the brain is on "autopilot" mode, and progress becomes very slow or even grinds to a complete halt.

Getting to an OK level is easy, but surpassing that requires a conscious, continuous and uncomfortable amount of effort.

</comment><comment><USER2> I like this comment:

      Talent x effort = Skill

      Skill x effort = Achievement

So essentially:

      Talent * (effort)^2 = Achievement</comment>


Have any developers regretted switching from OS X to Linux? - <AUTHOR> For the last ~12 years I've been on OS X. Before that I was primarily Slackware user. I switched to OS X when I started doing a lot of A/V work (at the time working with SDL dependencies was kind of a mess).
My Air is dying and I'm considering purchasing one of the newer Skylake-based 4K laptops to run Arch, rather than shell out $3k for a $1200 notebook. (It's a value thing, not a cost thing. I'll happily pay $3k for $3k worth of laptop)
I dev primarily in C, JS/Node, Golang, Python, Ruby, and have started working with Elxir and Swift recently (I'm fine using a hosting CI server to build Swift projects). I also do a lot of audio production, consume most of my media through my laptop, and need to be able to interface with CNC/Laser Cutters/3D printers.
Has anyone who does some or all of these things switched to a modern release of Linux? If so, what was your experience? <comment><USER2> Developing C, JS/Node, Go, Python, and Ruby on Linux rocks. I liked it way better than using OS X, but then again, all of the apps I used were cross- platform. Is there anything on OS X-only that you think you'd miss? For example, you should definitely investigate any RDBMS GUI that you use on OS X, because there's nothing great in that area for Linux.

Audio production is... another matter. Linux certainly has hardware weaknesses, even in areas that have been massively improved (like GPU drivers). I've also done kernel upgrades that randomly broke drivers and had to revert. So honestly the audio/CNC/laser cutter/3D printer thing is much more iffy.

Consuming media through the laptop is another sticking point. I had tons of bizarre issues with Chrome/Firefox and streaming video sites. It was just a mess.

I'd be very wary of Arch, as well. If this is your primary work computer, I strongly suggest a distro with a well-funded corporate backer. Arch is also going to give you cutting-edge updates, but sometimes (theoretically) at the expense of breaking things.

Have you considered a Hackintosh? And what's keeping you off of Windows? Since Vagrant/Docker, developing on Windows doesn't require huge sacrifices, and driver/media support on Windows is better than any other OS.

<comment><USER3> Really good RDBMS GUI for Linux (and other platforms) [https://www.jetbrains.com/dbe/](https://www.jetbrains.com/dbe/)

<comment><USER2> I honestly can't thank you enough for pointing this out to me. I love JetBrains products, and I had no idea this existed!!

</comment></comment></comment><comment><USER4> about half year ago, I purchased a lenovo carbon x1. I run ubuntu on it.

for development, linux is the easiest. building stuff is often just make and make install. convenient package manager...

there are two things I hate though.

linux doesn't support high dpi displays well. the default text is very small. you can scale the ui, but it doesn't always look good.

second, no trackpad experience on other platforms can match that of macbook. I never feel the need for a mouse when using mac notebooks, but when using a linux or a windows notebook, I need a mouse connected.

<comment><USER5> FWIW I run Linux Mint on a Macbook Air, and it supports the (admittedly quite nice) touchpad well. Obviously a little different than your particular issue, but I thought I'd comment for anyone reading.

<comment><USER4> what about the three finger move gesture?

</comment></comment></comment><comment><USER6> I've missed the screenshot tools, preview and keystrokes I've committed to muscle memory.</comment>


Distributed Named Pipes - <AUTHOR> http://dnpip.es <comment><USER2> This is an excellent idea... but I'm a little put off by the reference implementation using DC/OS and Kafka... Its a little bit 'heavy' for a reference implementation, at least that's my personal preferences.

Id like to see a more 'low tech' version, or in the very least, a plan to transition from a 'heavy' reference implementation to a 'lighter' one once one became available since having a concise reference implementation makes porting and compatibility significantly easier.

<comment><USER3> Yes.

> To try it out yourself, you first need a to install a DC/OS cluster and then > Apache Kafka...

When I see that, I know the cost of satisfying my curiosity is going to be a lot higher than I'm willing to pay right now.

<comment><AUTHOR> Fair point, I suppose. Is [https://dcos.io/docs/1.8/administration/installing/local/](https://dcos.io/docs/1.8/administration/installing/local/) an option?

</comment></comment></comment><comment><USER4> The name doesn't really work in this project's favor.

UNIX pipes are stream interfaces, whereas this looks to be message based - that's a fundamental difference.

Named pipes are uniquely identified in a well-defined local namespace, i.e the filesystem, whereas this seems to be an abstraction on top of Kafka with service discovery TBD.

This confused me while reading up on the project.

<comment><USER5> How is it a fundamental difference? Unix streams are character messages, so this is basically a superset of that functionality.

(I don't know much about Unix streams, so correct me if I'm wrong.)

<comment><USER6> Generally when a protocol is referred to as message-based it's because there's some framing around the payload. This can make it impractical as compared to a streaming protocol that just passes data back in forth. In some real-time cases, you can't tolerate the latency of waiting to bundle multiple items in a single payload but you also can't tolerate the overhead of framing many small messages.

</comment></comment></comment><comment><USER7> The most interesting thing I got from this was the DC/OS link, I hadn't heard of it before but I think I'll look at it to see how it might fit with our future direction with/instead of Kubernetes. [https://dcos.io/](https://dcos.io/)

</comment><comment><USER8> So... a message queue?

<comment><USER9> I'm just as confused. What does this have to do with named pipes?

<comment><USER10> [http://beej.us/guide/bgipc/output/html/singlepage/bgipc.html...](http://beej.us/guide/bgipc/output/html/singlepage/bgipc.html#mq)

"A message queue works kind of like a FIFO but supports some additional functionality."

<comment><USER9> So it's a bare-bones message queue? What's the advantage then? Performance?

</comment></comment></comment></comment><comment><USER11> Apologies, but what does this provide that Kafka doesn't already?

<comment><USER12> It uses the file paradigm just like local named pipes. That makes this tech accessible to pretty much every UNIX command.

<comment><USER13> Not really. Each message has to be an atomic item, not a stream of bytes, since there can be multiple readers consuming a single queue.

The interface specification has problems. "A pull does not remove a message from a dnpipes, it merely delivers its content to the consumer." So if the same consumer pulls the same dnpipe again, does it get the same message? Do messages ever get removed from dnpipes without a reset? Unclear.

Does pull block, support async completions, or just return an error when no data is available?

Reset, rather than sending an EOF which passes through the queue, implies that shutdown is either drastic or requires external coordination to empty the queue and stop the sending end before the reset.

<comment><AUTHOR> > ... if the same consumer pulls the same dnpipe again, does it get the same > message

No. Each message is delivered at most once. But good point, need to make that clearer!

> Do messages ever get removed from dnpipes without a reset.

No. Again, something I need to clarify as it seems.

> Does pull block, support async completions, or just return an error when no > data is available?

It blocks.

> Reset, rather than sending an EOF which passes through the queue, implies > that shutdown is either drastic or requires external coordination to empty > the queue and stop the sending end before the reset.

I don't follow. Reset empties the underlying queue.

In general, since the consumers start to consume not from the beginning of time (as in Kafka's `--from-beginning`) but wherever they happen to be (that is, in Kafka terminology from `latest` index) this shouldn't be a problem.

I tried to model as close as possible and as it makes sense after the semantics of (local) named pipes. I might have fudged up here but I'm not 100% clear on where :)

<comment><USER13> _> Do messages ever get removed from dnpipes without a reset._

 _No. Again, something I need to clarify as it seems._

So what happens after the system has been running for a while? Why doesn't the dnpipe system fill up with old messages that will never be read again? If new subscribers don't see them, and old subscribers have read them, why are they not removed? It would seem that once every subscriber who subscribed before a message was sent has received that message, the message is dead and can be removed. Why keep the history? Did you really mean that?

Also, what happens if one of many subscribers stops making PULL requests? Maybe it's blocked on something, or hung. Do the queues start to build up? Does PUSH eventually block?

 _> Reset, rather than sending an EOF which passes through the queue, implies that shutdown is either drastic or requires external coordination to empty the queue and stop the sending end before the reset._

 _I don 't follow. Reset empties the underlying queue._

On most queuing systems, when a publisher wants to shut down, they close the channel's sending end or send and EOF message. When all subscribers have read up to the EOF, they close their receiving end. The last messages get processed, and then the subscribers stop. If the only shutdown mechanism is a reset, that can lose messages not yet received. That's OK if the intent is just "kill everything and terminate", but not if you need a clean shutdown.

(ROS, the Robot Operating System, has a publish/subscribe system something like this. It's a soft real time system, so old data is discarded and you never want to block a publisher. They chose to lose messages if a subscriber isn't reading often enough. That's appropriate to a robotics use case. It probably wouldn't be for a containerized web backend. See [1].)

[1] [https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_patt...](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern#Message_Delivery_Issues)

<comment><USER11> Exactly my thought when reading his reply!</comment></comment></comment></comment></comment></comment>


Binary Ninja – A new kind of reversing platform - <AUTHOR> http://binary.ninja <comment><USER2> One of the developers here, been planning on doing some coordinated posts about it, just been super busy at DEF CON this week. Happy to answer questions though.

If you do happen to be at DEF CON we're actually having a meet up this evening: [https://twitter.com/vector_35/status/762050462195396608](https://twitter.com/vector_35/status/762050462195396608)

<comment><USER3> does the binja team at the CTF have any relation with your tool?

<comment><USER2> Nope, just an unfortunate name collision. We've been using binary ninja as the name of the tool for many years now, but it was a private tool that nobody knew we had it for the first few years for CTFs (this is the python version we open sourced before we started rewriting it) so they just happened to start using a similar team name some time after that.

The domain name time stamps should show that if it matters, though I don't think it really does.

</comment></comment></comment><comment><USER4> Okay. But aside from the really nice UX/UI, what does this do that Radare2 doesn't?

No, I'm not trying to be snarky, I genuinely don't know.

<comment><USER5> It's actually usable.

<comment><USER4> Good answer. Okay, what does it do that Radare doesn't?

<comment><USER6> I don't know what Radare does, but after I read your comment I installed Radare2 (because binja didn't let me save my file). I didn't get anywhere because Radare2 looks like it has a super steep learning curve, whereas with binja I just right-clicked the jump that looked like it'd do what I want and selected "Patch -> Never jump".

I'm not sure why you're dismissing usability, but it's a very big feature in a tool, one of the most important ones.

<comment><USER4> It's important, but the market share of Vim is roughly inverse porportional to how important it is.

Anyways, yeah, Radare isn't super usable. I'd guess I only understand 10% of it. And Radare2 is in active development, and wasn't totally ready for prime time, which is what I thought the usability comment was about.

</comment></comment></comment></comment></comment><comment><USER7> Been using this for quite some time - psifertex and crew have really done an incredible job in a pretty short period of time. Highly recommend checking it out, especially if you're sick of the shittiness of IDA. Only thing it's missing is some solid decompilers.

</comment><comment><USER8> Sorry to seem a bit daft, but I'm looking for a definition of 'reversing platform' and I'm not getting much. What is this for and what does it do? Who would use it?

On the other hand, Binary Ninja is the first result, so in some ways, you've got the SEO right :)

<comment><USER9> "reversing" in this sense is shorthand for "reverse engineering" or the analysis and reconstruction of the code for a executable binary at the assembly language level without the benefit of the original source code or debug symbols. The most common legitimate use is for analyzing malware and viruses. The best known product in this field is IDA Pro. (It would have been nice for the site to provide a comparison between the two, since such a comparison is inevitable anyway.)

</comment></comment><comment><USER10> Poking around the demo this feels really polished, which is a welcome change from most tools in this space, as they tend to be awkward at best. I look forward to future features.

</comment><comment><USER11> I just installed this and had a quick play.

Basic feature support:

disassembly, renaming, code graph, strings, function/imports list, x-ref, hex editor, undo

Some questions:

\- Why do you copy IDA and have a 32bit only demo? I can't actually evaluate this properly as everything I care about reversing these days is x64

\- Doesn't seem to be any python/API plugin support? I hope you are thinking about how you will support plugins from the start, and not tack it on later (usually this results in hell for dev and users - see IDA's shitty plugin architecture)

\- In the non-callgraph disassembly mode, it's difficult to follow. I think there is an overload of colour/styles

TLDR; Nice interface, clean gui, but lacking many features of IDA. The features it does have seem to work well though. I will be keeping an eye on this in future.

</comment><comment><USER12> Nice looking, but it's just IDA w/ Undo, and less features.

There has to be a shift in use case design more than making it prettier.

<comment><USER5> Give them a break man, it's the first release...

<comment><USER12> Don't take it the wrong way. It looks like a nice start. I just wish for better reversing tooling, and am merely giving a critique that if this was to replace IDA for me, it'd have to provide something that IDA does not.

<comment><USER2> There's plenty of things IDA does that we don't do, but the list of things we do they don't is growing.

To start with, we have undo, which is a simple feature but it underlies some design decisions that are going to show up in other features in the near future as well.

Because we have the ability to separate user interactions from our internal analysis we can not only undo, but also better support collaborative editing and upgrading of older saved databases.

In terms of features we already have, we have a static data flow implementation that allows you to query register values at addresses which greatly simplifies a lot of analysis plugins. Here's an example:

[http://arm.ninja/2016/03/08/intro-to-binary-ninja- api/](http://arm.ninja/2016/03/08/intro-to-binary-ninja-api/)

(The domain name is a coincidence, Q was just a beta tester, not officially affiliated with us)

Notice how much more robust and simpler the final implementation of that plugin using our data flow is:

[https://github.com/Vector35/binaryninja- api/blob/dev/python/...](https://github.com/Vector35/binaryninja- api/blob/dev/python/examples/arm-syscall.py)

<comment><USER13> I see that you have faithfully replicated at least some of IDA's insane graph view glitches.

Do you have the one where a line goes to one side by more than a screen's width, goes down a tad, and then goes back sideways to nearly where it started?

</comment></comment></comment></comment></comment><comment><USER6> Does "no saving of databases" include "no saving of binaries"? I patched a binary in the view to test but can't save it.

<comment><USER14> Maybe patch binary ninja to allow it? ;)

<comment><USER6> I can't patch stuff unless Binary Ninja works, and I can't get it to work unless I can patch stuff! :(

I'm afraid I'm not knowledgeable enough to do it by hand. I can make a jump always fail by setting the instructions to NOPs, but I can't recalculate offsets and things required to turn a jne into a jmp...

</comment></comment></comment><comment><USER15> I see the demo is 32-bit x86 only but what is the full version does it do ARM as well as x86?

edit: never mind found it in the FAQ, x86, ARM, MIPS, 6502

<comment><USER2> PowerPC is close to being done (also, the armv8 support is quite solid but the v7 needs work and thumb isn't integrated but is mostly complete).

A few of our early users are also working on some other architecture plugins so I think MSP430 or AVR might exist soon.

</comment></comment><comment><USER16> $399? ouch.

<comment><USER17> Their main competitor is IDA Pro, which goes for $1129 for its "standard" edition. There is a version of IDA Pro that's only $589, but it supports only 32-bit code.

<comment><USER18> It is very easy to make an argument that IDA Pro is so fantastically underpriced that it has killed the market for these kinds of tools by setting a bad price point.

I'm sure there are tons of random people on HN that would love to learn more about RE by tinkering with tools like this, or maybe even that have $50 worth of work to throw at it. But in the real world, most of the market for IDA Pro is made by consultants and in-house security teams, all of whom realize something far closer to $100,000 in value from IDA, annually, than $3999.

Meanwhile, if you want to sell a reversing tool that integrates with IDA --- something like BinNavi or BinDiff --- you have to cope with IDA's $3999 price point. Whatever you sell will inevitably have to be cheaper than that. Result: most of the product talent in this space goes to appliances that sell for $50,000 a pop and only to companies that will buy 6+ boxes in a pilot.

Binary Ninja is cheap. But it's also a labor of love.

<comment><USER19> Trying to understand as someone who's not a security professional:

Is IDA like Visual Studio or XCode - you basically need this to do your work - or is it more like Sublime Text or Text Mate or Github - boosts productivity but many people get by without it?

<comment><USER18> It's more like Visual Studio than Sublime Text.

</comment></comment></comment></comment></comment><comment><USER20> Is the GUI Electron-based?

<comment><USER21> Seems to be QT.

<comment><USER2> Yup! QT. Electron might be fast enough for graph view, I don't know, we'd have to test it. The good news is that the core is completely separable from the interface so we could re-architect the GUI if needed.</comment></comment></comment>


How abusive bosses and Slack led software engineers to unionize - <AUTHOR> https://jacobinmag.com/2018/04/lanetix-tech-workers-unionization-campaign-firing/ <comment><USER2> So, you want high engineering salaries, and the inability to get fired?

I'm not strongly for / against unions either way, but something here doesn't seem like it's compatible. Is it completely crazy that a company doesn't want their high paid employees to be hard to fire when they perform their jobs in a way they don't like?

From the story, it doesn't sound like fundamental rights were being violated. People's wages weren't being stolen, their healthcare wasn't being shut off.

The employee starting the whole thing could've been combative, uncooperative, etc. Who knows what it was -- those things are totally within the rights of a company to fire someone over in CA. And using outside messaging clients on company equipment, so is that. So what you're advocating for is to be allowed to do things that are honestly, privileges, and within the rights of a company to object to, but not face any consequences?

I would also pose the following larger question: Silicon Valley / this environment for investment and technology incubation exists because companies are allowed to decide who they want to employ or not, what ideas they want to try or not. Would you have found employment in this sector, if companies were forced to hire and fire using union rules?

And how would working under a union work? Would you initiate a grievance process for every gripe? Would companies have to build up a case about your poor coding quality to be able to fire you?

I don't see it working.

I apologize for somewhat conservative views in this area, but my thought is, you live in one of the highest paid areas, with the chance to hit it big as an employee of a company like this, you accept the risk that it won't work out.

If there were some golden company that paid well, couldn't fire people, and worked on everything you liked, well, wouldn't we all be there?

<comment><USER3> There's a difference between what's legal, what should be legal, and what you can successfully bargain for. If employee wages were being stolen, that's a matter for police and lawyers. A union exists mostly to help employees represent their side of the latter two cases, in a way that's as organised as a company.

The article describes a situation where employees were blocked from taking holiday time by management, and where they collectively bargained to fix that problem. That kind of thing is not the same thing as "the inability to get fired", and I think there's a much stronger case that it's a net positive for society.

</comment></comment><comment><USER4> The big takeaway I got from this is, be wary of any organisation that attempts to isolate workers from each other and prevent communication. The old divide and conquer. People talk about people who cut off their significant other, maybe people need to be more aware of this tactic on a wider scale in other organisational contexts.

</comment><comment><USER5> I wonder how that company fared after they fired all their engineers. I can't imagine that went well.

</comment><comment><USER6> It's an interesting story and food for thought. I'd recommend reading (or at least skimming the article) and thinking about whether any elements in it remind you of events in your own workplace.

The conflict between management and workers is an old one, but many key elements are unchanging. Unions may not be the right answer, but we have as much right as anyone to be treated with respect, and it's worth thinking about what the right answer _is_ going to look like.

(Conversely, with my manager hat on, it's worth thinking about how best to _avoid_ the issues Lanetix seemed so eager to start.)

</comment><comment><USER7> And this is why HR firms exist; the management in this tale navigated the concerns of their employees in a manner befitting a thoughtless bully. None of the negative outcomes needed to happen.

</comment><comment><USER8> Sounds like they were unhappy working there and did not like the CEO or their management. Kind of interesting they are suing in an effort to go BACK to work there.

</comment><comment><USER9> Nothing to make you realize how much you need to unionize like seeing how the boss will screw you over when you try. I hope this is the beginning of a wave of workers organizing at their workplaces. They can't fire us all.

<comment> King-Aaron > They can't fire us all

For every one employee who thinks this, there's ten ready to fill that role.</comment></comment>


Show HN: Visual Compare of GitHub repos (weekend project) - <AUTHOR> https://www.visualcomparator.com/

<comment><USER2> Looking really cool.. Although it's not fair to compare sf2 to rails (which ruling the ruby world.......)

</comment><comment><USER3> Nice. Is it possible to add other parameters to compare?

<comment><AUTHOR> Yep. We just set few params as a POC. Let us know what kind of params do you care of.</comment></comment>


Aereo Loses In Supreme Court, Deemed Illegal - <AUTHOR> http://techcrunch.com/2014/06/25/aereo-loses-in-supreme-court-deemed-illegal/

<comment><USER2> This seems to be the nut graf of the decision:

"This Court recognizes one particular difference between Aereo's system and the cable systems at issue in Fortnightly and Teleprompter: The systems in those cases transmitted constantly, whereas Aereo's system remains inert until a subscriber indicates that she wants to watch a program. In other cases involving different kinds of service or technology providers, a user's involvement in the operation of the provider's equipment and selection of the content transmitted may well bear on whether the provider performs within the meaning of the Act. But given Aereo's overwhelming likeness to the cable companies targeted by the 1976 amendments, this sole technological difference between Aereo and traditional cable companies does not make a critical difference here."

So, if I understand this correctly, the Court is rejecting Aero's argument that it provides private performances because it gives users the ability to control the rented antennaes, and only transmits what the individual user requests.

I'm a little baffled by how this differs from how people use DVRs. To me, it seems like the Court is hung up on how similar the end result is to the cable providers', even though the means are different.

<comment><USER3> > To me, it seems like the Court is hung up on how similar the end result is > to the cable providers', even though the means are different.

More specifically, the Court is hung up on how Aereo uses technology to circumvent the intent of the law. The ruling is basically saying, "Don't bother trying to follow the law as it's written if you threaten the status quo".

</comment></comment><comment><USER4> A dupe of [https://news.ycombinator.com/item?id=7943964](https://news.ycombinator.com/item?id=7943964).

</comment><comment><USER5> Once solution would be to move the antennas to user premise and make it more peer to peer in nature.

<comment><USER6> Yes, there actually already exist hardware solutions that let you do what Aereo does, except you don't have to pay a service fee.

I really hope they do this. I commented on this on the other thread: [https://news.ycombinator.com/item?id=7944241](https://news.ycombinator.com/item?id=7944241)

</comment></comment><comment><USER7> obviously.</comment>


Can You Rewire a Batter's Brain with Video Games? - <AUTHOR> http://online.wsj.com/articles/baseballs-science-experiment-1411135882 <comment><USER2> Soon most athletic training will be virtual, the number of virtual reps someone can take far outpaces the number on can physically take, moreover you don't overtrain or get injured

[http://www.nytimes.com/2010/04/03/technology/03game.html?_r=...](http://www.nytimes.com/2010/04/03/technology/03game.html?_r=0)

[http://www.wired.com/2010/01/ff_gamechanger/all/](http://www.wired.com/2010/01/ff_gamechanger/all/)

</comment><comment><USER3> For those who missed this last year, it's actually possible to store passwords in your brain in such a way that you can authenticate, but can't recall the password [0].

[0] [http://nautil.us/issue/6/secret-codes/cant-remember-your- pas...](http://nautil.us/issue/6/secret-codes/cant-remember-your-password)</comment>


Linux 5.5 to Offer Mainline Support for SGI's Octane MIPS Workstations - <AUTHOR> https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-MIPS-SGI-Octane <comment><USER2> Been wanting one of these machines for years, but they are sooo pricey it is insane. Mainline Linux support will be good, but I tbh I would be running IRIX as intended.

<comment><USER3> That is an interesting problem. In the 00's they were cheap and plentiful. Buying old SGI hardware to play with was pretty affordable. Now people want thousands. Same with old x86 hardware.

<comment><USER4> Why are these machines so expensive? Is there some legacy software that cannot be ported?

<comment><USER5> Probably just retro collecting craze driving prices up.

e.g. 10 years ago people were dumping CRT monitors, now a decent Sony Trinitron starts at 150-200 €

<comment><USER2> That is more true of old x86 hardware and older micro-computers (Amigas, Ataris etc).

The SGI machines are difficult to get hold of in the UK to begin with plus they are as other said short supply. There is one Octane in the country and it is the machine only (even though the monitor and keyboard are pictured) and it is going for about £800 on ebay.

If it was everything I would have said "that probably the best deal I am going to get" and went for it.

</comment></comment></comment></comment></comment><comment><USER6> [https://www.openbsd.org/sgi.html](https://www.openbsd.org/sgi.html)

"The OpenBSD/sgi port was discontinued after the 6.5 release."

That said, it was a very mature port and ran on many models, in 64-bit mode.

The code remains in -current for now.. the last release, 6.5 is a complete modern (was released in 2019) Unix operating system, which is more than can be said for running IRIX or Linux on these machines. I'm not even _aware_ of any binary distros of Linux for these. And good luck building your own kernel and userland.

<comment><USER7> I missed that when it happened, too bad. OpenBSD's sgi hardware support is much better than NetBSD's (although that

I guess the reason is that they used an Origin 350 for builds, but the disk controller driver had a bug causing lockups and FS corruption which never got fixed.

[https://marc.info/?l=openbsd- cvs&m=156941089510768&w=2](https://marc.info/?l=openbsd- cvs&m=156941089510768&w=2)

I also remember Miod Vallat doing a lot of the work on sgi, but he left the project a few years ago.

</comment></comment><comment><USER8> The Indy was a really important machine in my journey and I occasionally think I should pick one up for nostalgic use... but... meh, Irix is frozen (there is no OpenIRIX soldiering on...) and if I ran say FreeBSD on it, it'd just be a really slow machine that doesn't have enough RAM to build x, y or z. At least, that's how I talk myself out of turning my house into a tech museum!

<comment><USER9> Later IRIX .28 and above has an active community.

I feel the same. Indy amd O2 were amazing computers. I got rid of all my SGI gear. Every so often I feel a pang of regret...

</comment></comment><comment><USER10> It seems to be my understanding that Linux will allow supporting any hardware or software API as long as at least a few people care about it. It doesn't matter how old or impractical it is.

This is not a criticism, but I would like to deeply understand, what does Linux leadership want it to be? An OS that just runs on anything for the sake of it?

It already seems true that Linux aspires to be much more than what UNIX is. It can be a dumping ground of sorts for your ideas and research projects. As long as the code does something useful enough without corrupting the entire system, it seems to be fair game. That is kind of freeing and it would stand to benefit the project to be communicated more directly. These are my observations.

<comment><USER11> It's definitely not a dumping ground, try get a new feature merged into Linux and see how easy it is.

The inclusive attitude is exceptional for drivers and new architecture support. The kernel is intended to be portable, the more architectures supported the more mature the abstractions become. So as long as there's existing hardware capable of running the kernel for the new architecture, you probably won't meet much resistance landing support, provided it's not a disaster.

<comment><USER10> This part seems pretty special:

> the more architectures supported the more mature the abstractions become.

<comment><USER12> It's become trendy to say that supporting more things means only new work and a big waste of time. The "validating the abstraction" thing is overlooked.

The OpenBSD guys also used to write about this for why they support obsolete hardware and compiling itself on said hardware. That it surfaces bugs.

</comment></comment></comment></comment><comment><USER13> Why just Octane? Indy, O2, and Indigos were way more common. Is it just that there are no surviving X drivers for the other platforms?

<comment><USER9> O2 has a specialized graphics sub-system. Copper?

Anyway, it is a shared memory system, and under IRIX, that was done dynamically. The same chips were used in their NT visual workstations. Those did not manage the graphics memory dynamically, but were capable in every other way.

At the time, one could push 500mb plus images around like nothing. Was a big deal.

SGI did Linux drivers, and the SGI / Microsoft Farenheit project got in the way. Those never left SGI for legal reasons. Had that happened, perhaps Linux for an O2 would make sense.

I am not sure that system has ever seen a low level document release.

<comment><USER14> I believe the O2's chipset was actually called CRM.

The 1st gen Visual Workstations had a different chipset called 'Cobalt', but also had a Unified Memory Architecture.

<comment><USER9> That is what I was remembering. The two shared the same graphics core.

Cobalt. I knew Copper was not quite right. That is Amiga.

Anyway, at the time, PC busses were slow, and one could get a fair amount of RAM on either side of it and sort of do what that system did easy.

The plan was to get that graphics system into Linux proper, and legal got in the way. All we ended up with was a frame buffer and no real docs for the graphics chipset that I ever knew of.

Too bad. We may have seen some very differentiated PC innovation a bit earlier. If one wanted to do things like real time sub pixel accurate compositing, or mapping video onto dynamically changing surfaces, etc... anything requiring either/or large image data, high throughput between gfx, CPU and RAM, the performance was exemplary.

A lot of that was true on a few hundred Mhz O2 as well as the 1ghz Visual Workstations.

I spent a fair amount of time using both. Pretty sweet for the time period.

</comment></comment></comment></comment><comment><USER15> I recall using these at university for heavy duty GIS raster processing. IRIX was my first *nix experience.

<comment><USER16> I'm really eager to know how long ago and what kind of GIS software you used.

<comment><USER17> While ArcInfo was certainly supported on Irix I'd venture a guess and say Erdas Imagine for "heavy lifting" raster. Remote Sensing was such a fun class.

<comment><USER16> Agreed. Holy cow did I have fun in my remote sensing classes. I'll still remember learning about false color composites from landsat ETM+ data. The first time vegetation just popped out and I was hooked.

My guess is on Erdas Imagine too.

That or some more programmatic stuff like an OGR/GDAL pipeline.

</comment></comment></comment></comment><comment><USER18> Is there a clever way of hooking SSDs to the SCSI ports of these old computers?

<comment><USER19> Already done: [https://www.redrocktech.com/products/scsi- drives](https://www.redrocktech.com/products/scsi-drives)

There are also Fibre Channel adapters for these if you have the XIO-PCI card cage. Can boot from it with some special magic IIRC, but a local SCSI drive is fine for most things.

<comment><USER20> How much are the adapters? I don't really see prices on that site.

<comment><USER19> Sorry the FC adapters are original SGI gear, you would have to hunt for it.

<comment><USER21> Actually IRIX works with old Adaptec PCI FC cards, but to get it running you need to recompile the kernel with some arcane, undocumented parameters. Back then when I was a regular of comp.sys.sgi.* newsgroups, Alexis Cousein gave me the trick and saved my day when my official SGI card died.

<comment><USER19> Now that's a name I haven't heard in a long time...

It might have actually been Adaptec PCI in an SGI XIO-PCI card cage, memory is failing me. Definitely some dark magic required on Irix and on the FC switch and storage target side.

<comment><USER21> Yes, that's right. I had an XIO FC board in my O2000 that died, and I had spare Adaptec FC PCI cards for PCs. I had previously noticed that the SGI PCI FC cards for O2s or O200s were actually the same as the Adaptec, physically, but with an SGI ROM.

So after my XIO FC board died, I added an Adaptec board to my O2K to get my RAID array back online (the whole company was out of work because of that failure).

However though the card appeared in "hinv", it didn't work... After I asked for help on the newsgroups (the system was out of maintenance...) Alexis sent me a private email with the necessary invocation of the kernel rebuild command, and it worked like a charm from there.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> SGI always had the coolest looking computers

</comment><comment><USER23> Definitely cool for geek points but can't be terribly power efficient. Wonder how a NUC installed inside one of the drive bays would compare?

</comment><comment><USER24> Pretty tame announcement overall.

Little ominous though how heavily it's reliant on linus being available. I hope the business continuity planning is up to spec</comment>


Ask HN: Looking for a marketing-focused co-founder - <AUTHOR> I'm the founder of this site: http://www.snapplans.com. (It is up for demo purposes but not finished). I'm looking for a marketing-driven co-founder. If this is something that might interest you please contact me (my name is Barry) at firstname.lastname@example.com. <comment><USER3> From a quick glance (sorry, I don't register for facebook apps) it seems to me you just need people using it in the same location.

The most sensible marketing idea to me is using it in your town. Get your friends to test it out, make plans on it, demo it anywhere you can. Find all the local people/groups in your area (meetup.com, facebook groups, craigslist, online dating sites, whatever else comes to mind?)

You need a critical mass in a given location for it to work (I hope you live somewhere crowded... not on a rural farm!). I say pick your own city because you may have an easier time connecting with people locally rather than cold emails/calls. Now is that time to spend any and all goodwill getting people to try it out.

</comment><comment><USER4> Clickable:

<http://www.snapplans.com>

Edit: Added: _Fantastic_ design coupled with _crystal clear_ and flawless communication/copy on the home page. Are you _really_ sure you need a marketing co-founder? ;-)

<comment><AUTHOR> Thanks for the clickable link and especially for the kind words. I definitely need some help figuring out how to get the site off the ground.

</comment></comment><comment><USER5> I didn't really understand what it was from the homepage. Is it for me to organise things with my friends, or is it like Meetup.com? I think you should also make it more clear it's USA only (The zip codes).

</comment><comment><USER6> ...nice use of Vimeo's footer.

<comment><AUTHOR> I wasn't aware of it, I assume it's a coincidence and will have a conversation with my designer about it for sure.

<comment><USER6> It's the exact same image. Anyone at YC would notice.

..but if the design is just a rough mockup, I guess it wouldn't matter.

<comment><AUTHOR> You're totally right and I'm glad you brought my attention to it. I don't use vimeo myself and my designers were of course only supposed to use images they had rights to.

</comment></comment></comment></comment><comment><USER7> You should apply for Y Combinator, this is a slick product with a well articulated message. I strongly doubt you need a marketing co-founder - <USER2> need another hacker, and for you to learn more marketing stuff :)

<comment><USER5> Why would he need another hacker? Seriously, I think it's annoying to assume in every situation that they should screw the 'business guy' and go for another hacker!

He doesn't know how to market it, thus that's his problem, getting the word out. It would be counter intuitive to spend all his time learning to market (that in itself is silly, it would take a long time, and he may not even be able to do it.)</comment></comment>


Elon Musk never sought approval for a single Tesla tweet, U.S. SEC tells judge - <AUTHOR> https://www.reuters.com/article/us-tesla-musk-sec/elon-musk-never-sought-approval-for-a-single-tesla-tweet-u-s-sec-tells-judge-idUSKCN1R001J <comment><USER2> What is really sad about the state of affairs is that SEC is suing Musk out of spite (seemingly) and not bothered by a President whose tweets are changing fortunes of multiple corporations. For reference SEC's mission statement: "The mission of the U.S. Securities and Exchange Commission is to protect investors, maintain fair, orderly, and efficient markets, and facilitate capital formation."

<comment><USER3> Right. Does anyone have any idea why the SEC has such a huge justice-hunger for Musk? Musk definitely gets a lot of government contracts and money, and is very connected to defence, and lobbying. Why is someone that useful / influential becoming a target of such intense focus and interest? Is it a personal grudge at the SEC (why?) or from above? Is it a way to laterally apply pressure on Musk regarding SpaceX?

<comment><USER4> My guess is some of the short sellers have friends who work at the SEC.

That and Musk runs his company like a child, which allows it to be nimble, but also means every action doesn't get as much scrutiny as they expect.

<comment><USER5> Or, rather than postulating some shadowy conspiracy theory, we can guess that the SEC is a law enforcement agency, and Musk has repeatedly (and in plain sight) violated the law.

</comment></comment></comment></comment><comment><USER6> I don't think anyone expected Musk to follow that directive. His comments after the initial rulling signaled he didn't really care for the SEC telling him what to do, followed by a tweet about "memes" that IMO was to just troll anyone watching his Twitter account.

<comment><USER7> The court almost certainly expects him to follow that directive. Provided that it is persuaded he didn't, he could be in some nasty trouble.

In fairness, no reasonable person would _predict_ that Musk would follow it. I imagine that played a role in the SEC's decision to request it. (What trap is better than one the victim agrees to enter of their own accord, in public?) Musk, not being a terribly reasonable person in this area, probably assumed it wouldn't be an issue for him. If so, that assumption may bite him.

</comment></comment><comment><USER8> The SEC complaint can be found here:

[https://www.documentcloud.org/documents/5775155-Reply-to- Res...](https://www.documentcloud.org/documents/5775155-Reply-to-Response-to- Motion.html)

</comment><comment><USER9> From the point of view of the worldwide public, suing over twitter posts looks ridiculously funny.

So better that than something else. That will train Musk a bit for later.

</comment><comment><USER10> I'm having a hard time understanding this. Whats is the point of being CEO if you need approval to speak? Anyone investing in Tesla these days are basically investing in Musk. If they dont like the way he runs the business they can sell, or they can vote him out.

<comment><USER11> The tweet approval is a requirement of the settlement Musk signed with the SEC for his previous instance of securities fraud.

CEOs aren't kings, they have laws to follow. Musk could have avoided all of this by simply not engaging in the behavior that earned him this forced oversight.

</comment></comment><comment><USER12> SEC is asking for a First Amendment smackdown.

</comment><comment><USER13> Regulate until everyone worth regulating goes elsewhere.</comment>


Samsung ripped off my hobby project and published it under a different license - <AUTHOR> I wrote a tiny JVM a while ago and it has been licensed by a few companies for their internal use, but then Samsung ripped it off, republished it on github under a different license (against my license's terms) and even were nice enough to taunt me with "uJVM extensively uses sample code provided by uJ. Developers of uJVM would like to express their gratitude for invaluable info provided by Dmitry Grinberg."  Their code is a copy of mine with a few renames ("uJ"->"uJVM"). Especially the code of the jvm core, the heap code, etc. They added some comments, but in some places those are wrong since they did not understand how the code worked. What do to?<p>https://github.com/Samsung/uJVM http://dmitry.gr/?r=05.Projects&proj=12.%20uJ%20-%20a%20micro%20JVM <comment><USER2> Have you contacted Samsung about this issue? Any response?

Do you have a copyright, Trademark, Patent on this code?

Please consult with a Copyright/IP lawyer as soon as you can. A simple letter from a lawyer may result in action from Samsung.

Copyright lawsuits are not fun and can take years and lots of money. Do what you can now for as cheap as you can.

<comment><AUTHOR> I have not yet contacted them.

Code includes a license that is incompatible with Apache (the license they are distributing under)

I just found out today when someone emailed me with a link. I license my tiny jvm out to companies, and one client who was about to sign a contract for a license emailed me with a link to this asking why pay me when there is a similar project out for free, so not only did they deprive me of income, they are handing my non-free code out for free!

Do you have an IP lawyer to recommend?

<comment><USER3> Before discussing lawyers and how much they're going to cost... why don't you just contact the developers first to get their side of the story and their suggested resolution?

You're using really emotive language like "ripped off" and "taunt" and assigning malice to this without knowing the whole picture.

To give them the benefit of the doubt, a developer likely made a mistake in understanding or checking your license. The mention of you being the author is probably their (incorrect) attempt to follow your license and not an attempt to taunt you.

It's unlikely there was some conspiracy at the upper levels of Samsung to steal your code.

<comment><AUTHOR> wouldn't contacting them give them a chance to destroy evidence that would have helped a legal case?

<comment><USER4> You can clone their github repo first.

<comment><USER2> ^Yes! Gather the evidence, then contact Samsung and advise them you're an individual with a product that they stole the IP. If you call (1-800-726-7864) tell them you're recording it too as they probably are. if you email, chat etc.. Collect the digital trail of evidence.

</comment></comment></comment></comment></comment></comment><comment><USER5> They just pushed a commit which attempts to give you some credit[0]

      > Note that using this **project for commercial purposes
      or change of licensing terms must be agreed upon with**
      [uJ](http://dmitry.gr/?r=05.Projects&proj=12.%20uJ%20-%20a%20micro%20JVM)
      developer **Dmitry Grinberg**.

And they've added your licence back into a few header files.

       * 2. uJ cannot be used in a commercial product/service without first obtaining
       * permission from me (dmitrygr@<redacted>).

[0]: [https://github.com/Samsung/uJVM/commit/6f705aa2b2e46ca5e43b2...](https://github.com/Samsung/uJVM/commit/6f705aa2b2e46ca5e43b2c617b454ade69e73725)

<comment><USER6> yep, I've pinged them in post at habr, you can see their comments there [https://habr.com/ru/post/459358/](https://habr.com/ru/post/459358/)

</comment></comment><comment><USER7> Classic Samsung ^_^ We worked at a place where they basically pushed us for POCs until they had enough to say "No, thanks, we don't need" and a few months later, tadaaa, Samsung had the feature.

(tbh, our company was partly to blame since they actually sent source code..)

</comment><comment><USER8> It looks like that Samsung have now just removed your code entirely. Now though you may have lost the leverage you had before, as you still had control over their code, as they originally kept your license intact...

</comment><comment><USER9> IF they don't cooperate ASAP, might as well hit them as hard as poss on social media; twitter/youtube/blogs, see if you get interest from sites like The Register.

</comment><comment><AUTHOR> code has been removed, DMCA takedown notices sent to github for forks with a note saying that they can change the license to comply with mine, or remove code as they wish.

thanks all for adice!

</comment><comment><USER10> Find a lawyer, stat.</comment>


Creative Commons movie to be released - <AUTHOR> https://www.kickstarter.com/projects/265932231/tex-montana-will-survive-worldwide-release <comment><AUTHOR> I posted this here for two reasons. I really liked 'Battery' and I like the idea of funding movies and giving them away for free. They need to make a living, and we need accessible art.</comment>


Tell HN: Received this email: Google will turn off old Groups for Gsuite users - <AUTHOR> Dear G Suite Administrator,
We want to let you know about upcoming changes to how users in your organization .com use Google Groups as outlined below:
On September 15, 2020, new Groups will become the default experience for all G Suite users within your organization. The roll out to all G Suite domains will happen over two days. When this transition occurs for your .com, you will experience the following:

    The option to turn off new Groups, as the default experience for your organization, will be removed from the Admin Console.
    All of your users will be automatically moved to the new Groups experience; each having the option of returning to old Groups by clicking on Settings > Return to classic Google Groups.
 The old Groups experience will be turned off completely later in the year (no sooner than October 15). We will be sending you a reminder email three weeks prior to this date.
Once old Groups is turned off completely, there will be no option to use the old version. Users who were previously using old Groups will see new Groups as the only experience available to them. The option to return to old Groups will be removed from their user interfaces. What do I need to know?
We launched new Groups in May 2020, to provide an experience that matches Gmail and other Google services. We've added many features since then, and recently announced the launch of Collaborative Inbox and shared labels. What do I need to do?
// 2000 char limit
We're here to help
If you have additional questions about the roll-out or need other assistance, please contact Google support. When you call or submit your support case, reference issue number 164343382.
Thanks for choosing G Suite.
—The G Suite Team <comment><AUTHOR> The bit in the middle reads:

To prepare your old Groups users for the transition, we suggest you do the following:

        Become familiar with the features of new Groups that were introduced this year.
        Compare the features in old Groups that are also in new Groups, found here.

        Note: A list of features from old Groups that will no longer be supported in new Groups can be found here.

While new Groups is rolling out during the week of September 15, we suggest you do the following:

        In the Admin console, notice when the setting that allows you to turn off new Groups has disappeared. This indicates that the transition is complete for your organization.
        Go to groups.google.com as a G Suite user. Notice that new Groups is the default experience.
        Assist your users who are not ready to experience new Groups as their default experience to return to old Groups. Individual users will have the option to use old Groups by clicking Settings > Return to classic Google Groups.

\--</comment>


We Filed 100 Support Tickets to Learn How to Send Better Customer Service Emails - <AUTHOR> http://blog.statuspage.io/customer-service-email <comment><USER2> Though I have no use for the information in this article, I found it well written and interesting. I like it when folks do little research projects and present their findings.</comment>


This is why different Wikipedia banners result in different average gifts - <AUTHOR> http://saperduper.org/post/293243288/wikipedia-donators-anchoring-heuristic It was on HN yesterday. "Optimizing Wikipedia's Fundraising Banner Ads" (http://blog.wikimedia.org/2009/12/11/annual-fundraiser-checking-banner-results) asked readers to post their thoughts on the difference of average gifts donated by wikipedia users, when shown different banners. I wrote a blog post about the "anchoring heuristic", which explains the phenomenon. <comment><USER2> From a very quick scim of the original blog Wikimedia blog post it looks like the total for #18 was higher (with the same number of impressions). What this suggests to me is that the lower amount shown on the banner made people feel there donation would count even if it wasn't very much. If more of these people donated one would expect the average to go down and the total to go up, and that appears to be what happened.

<comment><USER2> Obviously I skimmed the article far too quickly. Here's the relevant bit:

        Compare the numbers of gifts for the two banners:

        #18: 832 gifts, $15073.47 total
        #22: 301 gifts, $9572.83 total

        Not close right?  But look at the average gift sizes:

        #18:  $15.84 for Paypal, $21.87 for credit card
        #22:  $27.92 for Paypal, $36.58 for credit card

So I was totally wrong in saying that #18 did better overall.

</comment></comment><comment><USER3> The total amount (not the average amount) is what counts to wikimedia. From the original blog post (less suggested -> more donated):

      #17 suggests $30,   totals $22,000
      #18 suggests $1.95, totals $11,000 (same views)

</comment><comment><USER4> So, Wikipedia should be showing just large donations? ;)

I wonder what would happen if they changed it to just a $1000 donation all the time?

<comment><USER5> It would be cool for them to create a genetic algorithm that trawled through a primordial soup of pitches and talking points, mixing various appeals, quotes, images, and quantities to see what would make the most money.

<comment><USER6> Why not take it to the next level and do a whole campaign like that ? Even ... a whole company ? Called [name to be found by market study], doing [TBF by customer survey] using [TBF by best practices review]. Or by an evolutionary algo :)

<comment><USER5> It all depends on your 'soup' you start with. Online advertising is a perfect example of punctuated equilibrium: big ideas that get gradually refined, until the highest return on investment comes from creating another big idea.</comment></comment></comment></comment>


Botnets exploit Linux owners' ignorance - <AUTHOR> http://www.v3.co.uk/v3/news/2262681/botnets-exploit-linux-owners

<comment><USER2> "This suggests that one reason there is so much spam from Linux could be that many companies that have implemented their own mail servers, and are using open-source software to keep costs down, have not realised that leaving port 25 open to the internet also leaves them open to abuse."

So I closed my port 25. This fixed other problems as well. Since then all my customers stopped complaining via email.</comment>


BadBIOS - <AUTHOR> https://www.schneier.com/blog/archives/2013/11/badbios.html <comment><USER2> Has Dragos thought of getting a sound engineer to test out this hypothesis?</comment>


First Adobe Air App Released: Review Please - <AUTHOR> http://www.adobe.com/cfusion/marketplace/index.cfm?event=marketplace.offering&offeringid=10960

<comment><USER2> Not a big fan of the transparent background. Otherwise it's pretty cool.</comment>


This column will change your life: Helsinki Bus Station Theory - <AUTHOR> http://www.theguardian.com/lifeandstyle/2013/feb/23/change-life-helsinki-bus-station-theory <comment><USER2> My experience with the Helsinki Bus Station is of wandering around the main level looking for the bus to Porvoo. I finally gave up, and asked for help. Turns out there's another floor lower down for the long distance buses.

There's probably a deep metaphor there. If I give a graduation speech I'll see if I can figure it out. :)</comment>


Warning Everything Is Going Deep: 'The Age of Surveillance Capitalism' - <AUTHOR> https://www.nytimes.com/2019/01/29/opinion/artificial-intelligence-surveillance.html <comment><USER2> This is an important, carefully researched book, one which everyone who is working with the Internet should read. The portrait of today's reality (and our future reality) is disquieting. [https://www.amazon.com/Age-Surveillance- Capitalism-Future-Fr...](https://www.amazon.com/Age-Surveillance-Capitalism- Future- Frontier/dp/1610395697/ref=sr_1_1?ie=UTF8&qid=1548865386&sr=8-1&keywords=surveillance+capitalism)</comment>