Schneier on Security: Is Antivirus Dead? - <AUTHOR> http://www.schneier.com/blog/archives/2009/11/is_antivirus_de.html <comment><USER2> "On the other hand, an antivirus program with up-to-date signatures will protect you from a lot of threats. It'll protect you against viruses, against spyware, against Trojans -- against all sorts of malware. It'll run in the background, automatically, and you won't notice any performance degradation at all"

Now, this may be a bit off-topic, but does anyone know about which software he's talking ? I personally find that most of the virus scanners try desperately to let you know how effective they are, constantly notifying what they have done to help you, to validate their existence.

On the other hand, you have the more minimalistic virus scanners, like ClamAV, but I really can't tell if they're effective or not. I fear they are not.

Anyone has recommendations for a good virus scanner that doesn't suck ? Perhaps pg can make this a request for startups, please ? It's about time this whole industry stopped sucking. :)

<comment><USER3> Norton. No wait, hear me out. As many here know, Norton has always been a pig of an antivirus. In 2007 and 2008, it was really, _really_ bad. It went from just slowing computers down to making them unusable. In the face of consumer backlash - even non-technical users were boycotting it - they made Norton Antivirus 2009. It uses ~10MB of RAM, and is now one of the faster scanners out there. It still gets Advanced/Advanced+ ratings from AV Comparatives, and updates signatures about every 5 minutes. Plus it has a "gaming" mode which puts even less stress on your system.

<comment><USER4> Does it really update signatures every 5 minutes?

Seems a bit excessive.

<comment><USER3> Yeah, but it makes people feel better :)

</comment></comment></comment></comment><comment><USER5> I spent 2 years working tech support for a large cable ISP. We offered a free antivirus/firewall package. In my experience, the AV software was more likely to break your PC than an actual virus, and we'd often get calls where people were infested with malware the AV package didn't stop.

AV software gives you a false sense of security, imo.

</comment><comment><USER6> Tools like time machine and vmware snapshots can make viruses less disastrous than before. You can rollback instead of re-imaging or worrying about removing all the malware.

<comment><USER7> Only if you're aware that the virus is running, and it doesn't do something disastrous in the meantime (eg, sniff your keystrokes while you enter a bank account number or log into the hospital records system).

</comment></comment><comment><USER8> Will you really not notice any performance degradation from anti virus? Really?

<comment><USER9> It is SO horrible. It's like if you stuck 30 pound weights on one hand of a sprinter.

<comment><USER10> I use ClamX AV. I have it set to do scans of new Downloads and scans late at night. I have no problems at all.

</comment></comment></comment><comment><USER11> I think the detection of virus signatures is a failing strategy. I have seen computers that I _know_ are infected and scanning with multiple products leaves some of the bugs undetected. That said, it would be pretty stupid to run Windows today without a scanner. AVG and (believe it or not) Microsoft's Essential Security are good and free. The two major problems with virus scanners is that they bog the machine down. (AVG is starting to do this). The other problem, and I see this from all brands, they can detect a virus but cannot remove it. This is a serious problem today because it then requires an expensive tech visit to manually remove a virus.

</comment><comment><USER12> The bit about users accessing services on any old computer becoming the norm is the bit which scares me. The idea of entering a password in a random computer with who know what key-logging malware installed scares me.

Two-factor can only go so far, as it only limits the window of opportunity to between log in and log out.

While I, and most technical people, guard our computers carefully and wouldn't use a computer owned by someone else for anything but anonymous web browsing, the average user is quite happy to use some terminal in an internet cafe.

</comment><comment><USER13> """ Examine a typical antivirus package and you'll see it knows about 75,000+ viruses that might infect your machine. Compare that to the legitimate 30 or so apps that I've installed on my machine, and you can see it's rather dumb to try to track 75,000 pieces of Badness when even a simpleton could track 30 pieces of Goodness. In fact, if I were to simply track the 30 pieces of Goodness on my machine, and allow nothing else to run, I would have simultaneously solved the following problems:

        * Spyware
        * Viruses
        * Remote Control Trojans
        * Exploits that involve executing pre-installed code that you don't use regularly

Thanks to all the marketing hype around disclosing and announcing vulnerabilities, there are (according to some industry analysts) between 200 and 700 new pieces of Badness hitting the Internet every month. Not only is "Enumerating Badness" a dumb idea, it's gotten dumber during the few minutes of your time you've bequeathed me by reading this article. """

\- [http://www.ranum.com/security/computer_security/editorials/d...](http://www.ranum.com/security/computer_security/editorials/dumb/)

<comment><USER14> There are a lot more than "30 or so" pieces of goodness. Applications (directly user-invoked executables) aren't the only vectors for malware and viruses. A quick scan of my Windows 7 installation - just the Windows directory - turns up about 17600 EXEs, DLLs and SYS files, which isn't an exhaustive list of potential module types. Any of those are subject to change on a monthly basis as updates get installed.

And this doesn't even start counting applications, and their update and patch mechanisms.

<comment><USER15> And you can't even say "Any 'good' application is only going to do certain sorts of actions. We'll scan those and if the application does something else, stop it". UAC in Windows 7 and Vista went a long way to making this better, at least if you're opening yourself to malware you usually have to click "I know this is doing something which could be dangerous", and 7 went a step farther by making it far more un-obtrusive so that users are less likely to auto-click it.

Its still a losing battle though. Run [http://technet.microsoft.com/en- us/sysinternals/bb896645.asp...](http://technet.microsoft.com/en- us/sysinternals/bb896645.aspx) for a few minutes, and look at how many actions are being taken, just when your computer is supposedly idle. Trying to whitelist each and every one of those would be massive overhead.

I've found (personally, this isn't for everyone) is to run with as minimal AV as possible (Right now, SSE), and if I notice anything out of the ordinary run an offline virus scan. I usually do this with Bart-PE, although I've been working on another method for it. Expecting an infected OS to report that it is infected isn't the best idea, it is too easy to fake the results. Doing a scan of the system while the OS is not running tends to be more reliable and remove any problems a lot easier. I'm currently working on a system which will PXE boot once a month, do a virus scan or two (with different, fully updated scanners), defrag, checkdisk and do a general cleanup.

<comment><USER16> >Any 'good' application is only going to do certain sorts of actions Like delete files, read files, contact websites, read keyb, send email?

There might also be naughty reasons to do these things

<comment><USER15> If you define them that way, yes. If instead you define them as:

Delete files in the application's working directory, read files from the application's working directory or public areas, contact websites, read keyboard _when this application is the focus_ , send email.

It isn't nearly as dangerous. Sure, you've still got the computer contacting webistes and sending email, but that isn't a terribly large risk. There is still a need for blacklisting that sort of activity. As far as reading sensitive information, however, as long as working directories are categorized well, and used by any applications dealing with anything sensitive, it isn't a problem.

</comment></comment></comment></comment></comment><comment><USER17> Can any one suggest a good white-listing software?

I see he recommends Malwarebytes' Anti-Malware: <http://www.malwarebytes.org/mbam.php>

However this looks like more of a scanner than a white-listing software. The other two he recommends look to be commercial only?

Any suggestions? Looking for Windows 7 64 bit capability. Thanks

</comment><comment><USER18> I posted the original with Schneier's and Ranum's pieces ([http://searchsecurity.techtarget.com/magazinePrintFriendly/0...](http://searchsecurity.techtarget.com/magazinePrintFriendly/0,296905,sid14_gci1373562,00.html)) at about the same time this was posted - <http://news.ycombinator.com/item?id=932940>

</comment><comment><USER19> i went sans AV software when i installed windows 7. we are a long way from the days of windows 98.</comment>


WRT120N fprintf Stack Overflow - <AUTHOR> http://www.devttys0.com/2014/02/wrt120n-fprintf-stack-overflow/ <comment><USER2> You'll have to forgive me for the awful presentation format and pacing, but here's a fun trick for bypassing the auth system on the Asus WL-700gE circa 2007:

[http://www.toaster-of-doom.com/~brandon/no_crawl/router/](http://www.toaster- of-doom.com/~brandon/no_crawl/router/)

Spoiler alert: it makes the WRT120N look like Fort Knox. These companies have come a long way over the years.

<comment><USER3> I clicked the link expecting not to understand what was happening.. but wow.. thats insane

<comment><USER4> same here - I thought it was gonna have like 10 bash shells open with some crazy buffer flow

</comment></comment></comment><comment><USER5> Use OpenWRT people. Modern kernel. Good security. Can be configured with devops tools like Ansible (assuming you have the flash to load Python).

[https://openwrt.org](https://openwrt.org)

<comment><USER6> how safe is it to install OpenWRT? What are the chances of me bricking my router if I have no clue what I'm doing?

My model is sort of listed in their supported hardware section (it's the Japanese version of the Buffalo WZR-600DPH2, though the "2" at the end is missing in their database).

</comment></comment><comment><USER7> Note this is technically a stack buffer overflow, not a stack overflow.

</comment><comment><USER8> This is why I only buy routers that are known to be compatible with open source firmwares like Tomato, DD-WRT, or OpenWRT. I have never trusted OEM firmware, not only for security but they tend to be really buggy.

</comment><comment><USER9> I'm far from an expert security pentester but I know my basics... and I'm always amazed at how simple these exploits are. Guys, come on, it's 2014, if you're writing C and using strcat/strcpy/sprintf/fprintf/etcetc with non- sanitized input, you're pretty much asking for it.

Even a rookie would spot such mistake and exploit it, it's always among the first obstacles to bypass at local CTFs and it's the #1 exploit that people think about when they think about a "security vulnerability".

<comment><USER10> Well, its not quite that easy for a rookie as you say. Just because you can trigger a buffer overflow bug does not mean you can exploit it. Most modern processors will allow disabling execution with an IP-on-Stack test. Thats assuming you can actually control the IP... , and assuming you can actually deliver the payload in the corrupted program state and not crash the program, etc etc..

<comment><USER11> Even a rookie would spot this mistake, but he would need to learn a lot before exploiting it. But with a nice target like this one... :)

<comment><USER10> I don't agree that this is a valuable target. AFAIK most consumer routers disable access to the web interface from outside the LAN range (by default).

<comment><USER12> Yes but you can break almost any routers wifi password in 24hrs.

<comment><USER13> But you have to be in range of the wifi to do it. This isn't something that's going to be a widespread problem.

</comment></comment></comment></comment></comment></comment><comment><USER14> In other news, it's 2014 and people still use non-bounds-checked string libraries in C to deal with unvalidated and unauthenticated inputs from a network.

<comment><USER15> The answer is to stop using C. It doesn't even have to be in Haskell. Hell Lua stops this class of bugs.

<comment><USER16> If you're building these things it depends what your target market is. How much you want to pay for flash, RAM, packaging, etc. When flash space is a premium (I'm talking 2MB) it becomes a tradeoff between using a tiny C webserver and having a few extra functions or adding a Lua interpreter and dropping those tools. We're talking operating in a margin of a few hundred kilobytes.

Also, some of these firmwares are based on an existing code base, it's just cheaper to hack it than replace it.

<comment><USER17> openwrt runs Lua, and runs on many of these boxes. It is pretty small and you can cut it down further - eLua runs happily on microcontrollers.

<comment><USER15> eLua runs on this board, STM32F4DISCOVERY [http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252...](http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252419) and is quite easy to setup following instructions from [http://www.fussylogic.co.uk/blog/?p=1222](http://www.fussylogic.co.uk/blog/?p=1222)

</comment></comment></comment></comment></comment><comment><USER18> Every time I see stuff like this (buffer of some convenient fixed length, no real attention paid to its length) I really wonder whether whoever wrote that code ever thought of how long a string _could_ be (the entire address space of your process, basically), what the limits are, etc. If vsprintf() had the same 256-byte limit on its output buffer, there wouldn't be any overflow. If this fprintf() implementation was documented as to be used for output not exceeding 255 bytes, maybe who wrote the caller code would use "Location: %.243s\n\n" instead. Although a fully general fprintf() should not have any arbitrary limits like that, in a special-case embedded system like this it's not uncommon --- but if it has limits, _they should be documented clearly_.

I think it's not a matter of language or "safety" or "security" or anything else; it's a very, very, VERY simple matter of _knowing the sizes and limits_ whenever you write code or design anything. Somehow I think all this... astounding ignorance stems from the misconception that memory is somehow an infinite resource, or the discouraging "if you need to know the limits, you're doing it wrong" type of thought. It is _very_ important that you know the limits, so that you can work within them.

(Capitalising the words "Stack Overflow" is now a bit confusing, thanks to the site of the same name...)

</comment><comment><USER19> For those following along at home remember that MIPS has a delay slot. That's why the add is listed after the jr even though the add is executed before the return.

</comment><comment><USER20> I still remember HN/reddit bashing Chinese crap router with crap firmware yesteryear :)

<comment><USER7> It seems that all router/home networking device firmware is universally shitty and full of holes.

Example: [http://securityevaluators.com/knowledge/case_studies/routers...](http://securityevaluators.com/knowledge/case_studies/routers/soho_router_hacks.php)

<comment><USER21> With consumer gear it's a race to the bottom.

Until customers will demand more security than fancy features this problem will not be addressed.

<comment><USER22> For routers? What fancy features? They want a cheap way to create a wi-fi network that doesn't crash. Only a small fringe group of consumers have interest in exotic features in their wifi routers.

</comment></comment></comment></comment><comment><USER23> Are there ANY hardware manufactures that know how to write software? It seems like both firmware and hardware were an afterthought to almost any piece of computer hardware I have seen.

</comment><comment><USER16> Man having worked on a few router firmware sources I'm surprised there's not an exploit for every router out there, except maybe for the OpenWRT ones.

There was one router that had a built in backdoor, lets say you hit the router on a hidden page /sysctrl.html, which gives you essentially a poor-man's console with an input to send any command as root and it writes the output into a textarea. I mean it's as simple as launching telnet and then you're on the router as root.

<comment><USER24> I had one like that close to a decade ago (cheap ZyXEL, /syscmd.asp). However, I treated it as a feature; I think it was my first Linux-based router. That, and I only found it by exploring the filesystem base on the ping prompt that (IIRC) was passed to the shell without escaping semicolons...

I _think_ that page was behind auth; either way, anybody who had gotten on my home router could just have stepped over and unplugged it, so it wasn't an issue in my case.

</comment></comment><comment><USER25> This article reminds me of a talk given at 29c3:

[http://youtu.be/f3zUOZcewtA](http://youtu.be/f3zUOZcewtA)

Embedded devices are woefully insecure and no one seems to care!

</comment><comment><USER26> "I respect myself. That's why I refuse to use sprintf"

hahah. Nice.

<comment><USER27> It's from [0], which was on HN not too long ago [1].

[0] [http://natashenka.ca/posters/](http://natashenka.ca/posters/) [1] [https://news.ycombinator.com/item?id=7156405](https://news.ycombinator.com/item?id=7156405)

</comment></comment><comment><USER28> What editor is that?

<comment><USER29> It's a Disassembler - Ida Pro

[https://www.hex-rays.com/products/ida/](https://www.hex- rays.com/products/ida/)</comment></comment>


Tardigrade protein helps human DNA withstand radiation - <AUTHOR> http://www.nature.com/news/tardigrade-protein-helps-human-dna-withstand-radiation-1.20648 <comment><USER2> Curious about the timeline regarding application of this knowledge and techniques with respect to longer space travel (Mars trips?)?

With what I know any application of this would be a long long time into the future, but maybe that's incorrect and there are short-cuts available.

</comment><comment><USER3> I wonder if this interesting property reduces their mutation rate (and therefore slows their evolution).

<comment><USER4> To be fair, what do they need to evolve for at this point? It's hard to imagine an extinction event, short of the sterilization of the planet or the end of Solar activity, for them.

<comment><USER3> I would say their ability to resist extreme conditions might not be the same as resisting change in general. e.g: absence of food. Tardigrades are known to eat each other and in the absence of food they would probably resort to cannibalism.

<comment><USER5> They eat bacteria. The one thing that one can count on outsurviving tardigrades is bacteria.

</comment></comment></comment></comment><comment><USER6> The actual paper itself is available in full online and released under Creative Commons. We should do our best to promote research like this instead of linking to blogospam that is advertising articles like "Trumps IQ Will Shock You" or "Eat This Junk Food To 'Reverse' Dementia."

[http://www.nature.com/articles/ncomms12808](http://www.nature.com/articles/ncomms12808)

"Extremotolerant tardigrade genome and improved radiotolerance of human cultured cells by tardigrade-unique protein."

</comment><comment><USER7> The article in Nature is much more readable IMHO:

[http://www.nature.com/news/tardigrade-protein-helps-human- dn...](http://www.nature.com/news/tardigrade-protein-helps-human-dna- withstand-radiation-1.20648)

<comment><USER8> The comments on that article are particularly interesting.

</comment></comment><comment><USER9> Why is nearly every word in the title capitalised?

<comment><USER10> See 'Title case' at [https://en.wikipedia.org/wiki/Letter_case#Case_styles](https://en.wikipedia.org/wiki/Letter_case#Case_styles)

<comment><USER11> But it's weird with a long compound sentence.</comment></comment></comment>


macOS Catalina 10.15 Beta 19A546d update permanently deletes everything in /opt - <AUTHOR> https://www.reddit.com/r/MacOS/comments/czari9/psa_new_macos_catalina_1015_beta_19a546d_update/ <comment><USER2> Reminds me of a bug in macOS 10.1 (?) which recursively deleted /tmp on startup. So far so usual. But it also followed mount points in /tmp to other drives.</comment>


Ask HN: Recommendation for book related to ethics and hacking/computers? - <AUTHOR>

I need to write a book report on a book related to ethics, computers, and public policy.  There aren't any books that I have in mind, so I'm looking for recommendations.  An interesting biography of a hacker would probably work.  Thanks. <comment><USER2> <http://en.wikipedia.org/wiki/The_Cuckoo%27s_Egg_%28book%29>

</comment><comment><USER3> Larry Lessig's books are especially strong on public policy.

</comment><comment><USER4> The Hacker Crackdown?

</comment><comment><USER5> Stallman biography?</comment>


On Internal Engineering Practices at Amazon - <AUTHOR> https://jatins.gitlab.io/me/amazon-internal-tools/ <comment><USER3> Ex-Amazon SDE here.

A lot of this has changed.

First, there is a movement to build a lot of services in Native AWS instead of MAWS/Apollo.

Apollo doesn't require copying configs anymore; you can have the config exist as part of the package you are deploying. Generally, that's a best practice.

Pipelines can be configured as code too.

There is a centralized log service which requires onboarding. It does require some commandline tools, but it works. The logs get stored on S3, IIRC.

If containers suits your needs, you'd be hard-pressed to find someone telling you not to use it. Generally, though, you would want to use bare metal for Amazon's scale.

There is also a change to how NPM is being used at Amazon. It was a lot easier towards the end of my tenure, and was probably as close as it would get when working with Amazon's build systems.

Amazonians are generally conservative and don't use the latest and greatest unless it solves an actual customer need. Customer Obsession is still _the_ defining leadership principle.

<comment><USER4> > you would want to use bare metal for Amazon's scale

Containers are "bare metal".

<comment><USER5> > Containers are "bare metal"

Please explain this use of jargon. Are you saying that a Docker container is "bare metal" in some culture? A VM is bare metal? What do you mean by container, and bare metal?

<comment><USER4> Containers are just namespaces for things within the Linux kernel. Unlike with VMs, you're not running separate instances of the OS, it's all run by just one kernel instance, and that kernel usually runs directly on the hardware, that is, on "bare metal". That "ubuntu" base image you can spin up does not actually run the Ubuntu kernel. As a result, bare metal containers incur none of the "virtualization penalty" that VMs do.

Cloud is, in fact, abnormal in terms of how containers are used in that it wraps them into VMs. That's in part because VMs were already there and they simplify provisioning of something that looks like "machines" from the outside, and in part because containers do not offer much in the way of security guarantees (precisely because all containers running on the same host share the kernel), whereas VMs do.

<comment><USER5> Ah, you're using it to mean "no virtualization". Got it, thanks.

I tend to use the term to mean single-tenant, user-supplied OS, non- virtualized myself but I see where you're coming from.

<comment><USER6> All of that may be true as well - if the user picks the underlying OS (i.e. kernel) to run the container engine and installs on bare metal, then literally everything you wrote applies.

</comment></comment></comment></comment></comment></comment><comment><USER7> Based on my experience, the article contains a lot of misinformation. Some of the statements might have been true at one point in the past, but are now out of date by years, while others have never been true in the time I've been around.

Without getting into a point-by-point rebuttal, my reaction to each section/Exhibit is "that's wrong/misleading".

<comment><USER8> Isn't that a bit disingenuous? Your role at Amazon is nothing like the typical engineer at Amazon. You live in the shiny new world while the majority of engineers are stuck on something that's not too far from the article.

<comment><USER9> I was an intern at AWS this past summer(and will be returning as a new grad in May) and this article is not accurate based on my experience. My code (which was part of our team's actual production system, not a toy project) ran on EC2 instances in an autoscaling group. There was no manually provisioning servers. I worked with a Kinesis Stream and several other resources and there was a way for us to programmatically retrieve the names of the resources. My impression was the system we used to find a resource name works for all AWS resources so I imagine you could get the name of a load balancer this way as well. Finally, I'll just say my team worked entirely in Python. Maybe that was an exception, but it is certainly sufficient to directly falsify the statement that "internally, at Amazon, you can't even use a language other than Java." (How would the author even know this? Was he in on the S-team meeting where it was declared that all non java users get a pip?)

<comment><USER10> The Java claim is just factually false.

Java/C++/Python/Ruby/Go/Perl/Scala, even Rust, are used in Amazon for various projects. What might be true is that, consider how critical your service would be, the more it is, people will lean towards to more conservative/mature/enterprise-ish languages, not exotic ones, because that inherently means risk. And Java is the go-to option under that consideration, just because, it is Java, the least controversial choice if you had asked me.

But Amazon comparing with other companies I worked with, except extremely small startup, where tech guidance is like non-existent, the least restrictive when it comes to languages. It fits the Amazon's self perception, it is pragmatic, non opinionated, moral-agnostic. It cares about customer, because customer means potential of eventual profit. However you achieved that, is not Amazon's concern.

<comment><USER8> The L8 manager of our org declared that all projects must be on the JVM, and if the language wasn't Java, then we would need to submit a six pager explaining why. Perhaps he was just being conservative, but to me there's something off-putting when those types of decisions come from managers rather than from the engineers.

That said, our org did manage to have a few projects that aren't Java, so I guess I would have to concede that the Java claim is factually false as well. But it sure doesn't feel like I am empowered to choose something other than Java.

</comment></comment></comment></comment></comment><comment><USER11> I worked at a startup and then switched to a bigger product company: Zoho.

If there's one thing I'd take away for the rest of my career from Zoho, it would be frugality in adopting the latest of tech.

When NoSQL was all the rage, the company stood firm that relation databases had rock-solid mathematical foundation and stayed away from the bandwagon. It paid off.

When every other company wrote blogs about rewriting their software in NodeJS, Ruby & Python, the company stood ground with statically typed languages. It paid off.

My own team, Zoho Writer has a strong policy against incorporating third party libraries without good reasons. This way, the product is nearly a decade old, but the JS size has remained surprisingly small, all through its evolution.

I believe staying frugal in adopting the latest hype, can only be reasoned about in hindsight.

<comment><USER12> I have shared this blog posting more than I care to admit.

[https://mcfunley.com/choose-boring-technology](https://mcfunley.com/choose- boring-technology)

It amazes me that people will put their companies and employees at risk by using the new cool stuff just because everyone else is ( looking at you k8s )

<comment><USER13> Definitely, but, I'm sure that adopting new technologies at the right time can be a huge competitive edge for startups. Sure it can fail horribly in some places where hindsight will show that the trusted stack was the right choice, but it could also mean winning a race to market and continued relevance for a company if it works out.

<comment><USER12> Startups are complete risk and should jump on the new cool and shiny toy ship.

When you start making money or wish to start making money you need to stabilize the insanity.

I have done both.

<comment><USER14> Something that's "complete risk" should take even more risk? Doesn't seem logical.

<comment><USER12> so when you are swimming you hold one leg in the air or do you keep everything in the water so you can swim faster ?

</comment></comment></comment></comment></comment></comment><comment><USER15> One misconception people get wrong, from my perspective, about most FAANG is that you get to work with new and shiny things, especially new langauges. This is really more applicable to startups where risk taking is in the DNA, you will mostly get really strong pushback because there is just too much effort involved to support more than two or three languages at scale. There are normally niche languages, but they are essentially statistical anomalies and are usually borne out of a real business need (like swift for iOS). Mostly engineering for engineering sake is also going to be frowned upon unless it really helps the business.

I do agree that Amazon is the worst in regards to OSS. They really need to fix that, even if jut for PR, because they are consuming so much of it for AWS.

<comment><USER16> Very good comment, +1.

People don't really get the rabbit hole that is necessary in order to introduce a new technology at a large company. Just off the top of my head, a few of the issues:

* Not everyone has followed the broader technology world outside the big company. It's totally possible to imagine a situation where nobody in your management chain or team has even heard of something relatively mainstream like Docker.

* Your company uses custom build, deployment, and dependency management systems. Someone will have to do the work to implement support for the new technology in these.

* If the new technology has its own opinionated ideas about how to do any of the above, like Rust crates, npm, pip, etc., forget about it. You need to interact with previously existing internal code which means you need to fit into the already existing build/deployment/dependency solution.

* Your company has a bunch of custom internal services. You need to create bindings for these services' APIs in the new language.

* Your company might be doing some esoteric stuff that the new technology has no support for, like for example if your network stack does HTTP in some sort of custom-tuned way for performance, and the new language's HTTP library only supports a subset of everything that's possible.

* The new technology may have correctness or performance issues that have never been discovered because it has never been used on many thousands of servers where a 1% difference in CPU makes a huge difference, or it has never been used with a codebase big enough to take >1 day to build, or with binaries larger than several GB, etc.

And the biggest one...

* Every day, many new people are joining the company and beginning to ramp up on the (internally) mainstream solutions that have institutional inertia. This will dwarf the speed at which you can convince people to switch to the new technology.

The pattern I have seen is that something starts off being used for one-off scripts that don't have a lot of dependencies on the existing gargantuan infrastructure, then very, very gradually gaining mindshare internally and becoming more supported.

<comment><USER17> "...or it has never been used with a codebase big enough to take >1 day to build..."

I've not worked in this scale of enterprise environments so I find this tidbit fascinating. Why does the codebase take over a day to build? Does that time include rebuilding and deploying the underlying infrastructure?

I'm genuinely interested here. I can only imagine a few highly niche cases myself so I'm curious what I'm missing here.

<comment><USER16> Hard to find updated publicly-available information on this, but it was claimed that in 2003, Windows took 12 hours to build, on a multi-machine build farm: [https://www.itprotoday.com/windows-server/supersite- flashbac...](https://www.itprotoday.com/windows-server/supersite-flashback-nt- s-first-decade)

</comment></comment></comment></comment><comment><USER18> _As far as I know, Node.js was used inside in a limited capacity, but they had an alternative for npm for security reasons, and you had to get an npm package approved to use it internally._

FWIW, this is a _very good thing_. A company as large as Amazon should do this with all of their repositories; even a small start-up should be doing this to mitigate suspicious packages / third-party code vulnerabilities.

<comment><USER19> I worked on third-party package approvals at Google. The reasoning behind reviews was largely due to license compliance. If the license said "you have to display this license to end-users" then we had to make sure that the license was machine-readable and would be automatically bundled into the build to be displayed in that "open source licenses" section of pretty much every app ever. If the license said "by linking this into your code, you have to opensource all code at your company", we had to deny it. That sort of thing.

We suggested that people get security reviews, but it was up to the user of the package to figure out whether or not that was necessary. Often security reviews would be blocking the project's launch and would be done at that time.

The final thing we enforced was a "one version" policy. If everyone was using foobar-1.0, and you wanted to use foobar-2.0, it was on you to update everyone to foobar-2.0. This was the policy that people hated the most, but basically mandatory at the time because none of the languages widely used at Google supported versioned symbols. Having library A depend on foobar-1.0 and library B depending on foobar-2.0 meant that application C could not depend transitively on library A and library B at the same time, which would cause many disasters.

<comment><USER20> This all sounds like justified inconvenience in the name of safety at scale. As long as you have a good relationship with the package approval guys this is a fine workflow in my experience.

<comment><USER19> Yeah, I thought it was fine (I was both a reviewer and a user).

I mostly posted to provide some contrast to the folks that are saying things like "there are too many open-source libraries and they need to be approved to make sure there aren't any security problems", which is not what we did. We did not attempt to limit the use of libraries, nor did we vouch for the security-readiness of packages before they were allowed to be checked in to source control. If you think there are too many npm libraries and are looking for an example of a big tech company saying "no more!", this is not it. Use all the libraries!

</comment></comment></comment></comment><comment><USER21> Don't want to go into too much detail but this article is like taking the crappiest parts of the crappiest systems and declaring it representative of an entire product. There is a lot of really good internal tooling not mentioned here, and for the internal tooling mentioned here (like Apollo) absolutely none of its benefits are mentioned.

</comment><comment><USER10> Well, this article gets something right, but gets a lot of stuff wrong as well. What can be confirmed is that his access to the Amazon tech scene is limited, and he takes a sweeping generalization that is how the whole Amazon works.

Disclaimer: Ex-Amazonian, left like one year ago.

<comment><USER22> I agree.

Disclaimer: Also ex-amazonian, left like one year ago.

<comment><USER23> What happened like one year ago?

<comment><USER24> Well, like 2 amazonians left.

</comment></comment></comment></comment><comment><USER25> I like how Amazon has an MAWS movement internally, meaning "Move to AWS". I think most people think that they use AWS mostly, but they dont.

Its an interesting look behind the scenes at Amazon and how antiquated they appear to operate. Makes you wonder if Azure and Google have pretty good chances beating them down the road.

Edit: Interesting, further down one person commented that Amazon doesn't use AWS broadly because it's seen as not secure enough for certain workloads.

<comment><USER7> Based on my experience, that information and some of the comments about it in the thread are out of date or inaccurate.

'Move to AWS' was a program focused on accelerating AWS adoption that was primarily active something like 5-7 years ago. The program achieved its goals and concluded: virtually all infrastructure was running on AWS. I worked on the program for part of that time, in the last couple of years it was active. Amazon's migration to AWS was was covered in a 2012 presentation at AWS re:Invent: "Drinking Our Own Champagne: Amazon's Migration to AWS" [1].

Some more recent efforts around AWS usage were covered in a 2016 talk: "How Amazon.com Uses AWS Management Tools" [2] (which references the earlier talk and discusses some of the changes since then). There are ongoing projects to improve and optimize usage of AWS, as well as to adopt some of the newer services.

[1] [https://www.youtube.com/watch?v=f45Uo5rw6YY](https://www.youtube.com/watch?v=f45Uo5rw6YY) [2] [https://www.youtube.com/watch?v=IBvsizhKtFk&t=13m20s](https://www.youtube.com/watch?v=IBvsizhKtFk&t=13m20s)

<comment><USER26> Until they move off of sable, their NoSQL backend for retail, calling them mostly on AWS is laughable especially considering their major prime day outage this last year was caused by sable not being able to dynamically scale up [0].

[0]: [https://www.cnbc.com/2018/07/19/amazon-internal-documents- wh...](https://www.cnbc.com/2018/07/19/amazon-internal-documents-what-caused- prime-day-crash-company-scramble.html)

<comment> amzn-throw Depends on what you mean by mostly. Almost all code runs on EC2. All object storage is in S3. Almost all service asynchronous interactions are decoupled via SQS. Almost all notifications are shared via SNS.

Yes, most legacy systems use Sable but most new development for the last 2 years uses DynamoDB.

More and more event-driven applications with highly variable throughout are on Lambda. Even on AWS Service teams.

The Sable outage had a particularly laughable interpretation by the armchair quarterbacks from CNBC. The kind of scale involved makes Oracle-based approaches completely infeasible. (the internal Correction of Error document leaked and was wildly mis understood)

And the scaling timelines involved are so compressed that no company in their right mind "dynamically scales up as a result" \- it's always projected scheduled scaling. There were other cascading effects.

I know it's fun to dunk on Amazon but their commitment to operational excellence is unparalleled as public AWS post mortems after major events should reveal.

If you read the entire Correction of Error document on tbe Sable outage you'd agree, of course CNBC would never publish that, one gets more clicks by getting a professor out of touch with the realities of production software engineering to blurb some juicy quotes.

</comment></comment></comment></comment><comment><USER27> Ex-Amazon SDE checking in. The article is quite misleading.

The author confuses "shiny" with "good".

Amazon does package-based deployments because it scales well and allow engineers from many different teams to work on packages and also provides fast security updates.

Amazon used VMs more than a decade before container engines and the latter are still lacking security and stability.

Having worked in many companies, I would take Amazon's engineering practices over the modern shiny devops tool ecosystem every day.

I agree that Apollo is slow (due to the implementation) and has an ugly UI, and that the company has a very poor track record of contributing to OSS.

</comment><comment><USER28> Context: I spent five years as an engineer at Amazon, the last two as a tech lead on an internal developer tool (think SaaS for performance engineering).

This article is not untrue but it misses the fact that teams are empowered to own their solutions are not restricted in _how they setup their environments and which tools they use_. It's true that fixing these problems feels like wasted effort, it's by design: Amazon operates as many separate internal entities and I think replication of effort is an acknowledged downside of operating this way.

> 1\. Deployments > Their internal deployment tool at Amazon is Apollo, and it > doesn't support auto-scaling.

I had to manually scale up my service once in two years and we weren't over- provisioning wastefully. Before I left my product was supporting +40K internal applications with an infra+AWS cost < 2k / month.

We had good CI with deep integration with Apollo, you could track any change across the pipeline, we had reproducible builds and we had a comprehensive deployment log listing all changes.

Apollo is sloooooow though and the UI is very 90s.

> 2\. Logs > Any self respecting company running software on distributed > machines should have centralized, searchable logs for their services.

We were using Elastic Logstash Kibana powered by AWS ElasticSearch. I wrote a thin wrapper around logstash that was used in over 1K environments internally, so weren't the only ones doing this.

> 3\. Service Discovery > What service discovery? We used to hard wire load > balancer host names in config files.

Agree with this one. I will never forget the quality time I spent configuring those load balancers and ticketing people about DNS.

> 4\. Containers

As other commenters mentioned, if you want to use containers, you're free to bypass all of this and run your service in AWS where you can use ECR, EKS etc if you want.

> (As far as I know, Node.js was used inside in a limited capacity, but they > had an alternative for npm for security reasons, and you had to get an npm > package approved to use it internally.)

I built my UI from scratch using create-react-app and yarn offline builds (no mystery meat) and I bypassed all the internal JS tooling, which I thought was very poor. This was changing though.

Finally, my personal anecdote: you could onboard our product in less than an hour (including reading docs), it required no further maintenance and gave you performance stats for free. So not all was bad :)

<comment><USER28> > They have some amount of Rails, and JavaScript has to be there, but if you > want to experiment with, say, Go, Kotlin, or anything else, you are going to > get nothing but push back.

I missed this - starting 2018 we were writing all our backend logic in Kotlin and we got no push back from anyone.

</comment></comment><comment><USER29> Ex-Amazon engineer of several years here.

This is a pretty interesting article, but it's important to know that Amazon's internal tooling changes pretty fast, even if it's mostly several years behind state-of-the-art.

Exhibit A: Apollo

Apollo used to be _insane_. It was designed for the use case of deploying changes to thousands of C++ CGI servers on thousands of website hosts, worrying about compiling for different architectures, supporting special fleets with overrides to certain shared libraries, etc etc. It had an entire glossary of strange terms which you needed to know in order to operate it. Deployments to our global fleet involved clicking through tens of pages, copy- and-pasting info from page to page, duplicating actions left right and centre, and hoping that you didn't forget something.

When I left, most of that had been swept away and replaced with a continuous deployment tool. Do a bit of setup, commit your code to the internal Git repo, watch it be picked up, automated tests run, then deployments created to each fleet. Monitoring tools automatically rolled back deploys if certain key metrics changed.

Auto scaling became a reality too, once the Move to AWS project completed. You still needed budgetary approval to up your maximum number of servers (because for our team you were talking thousands of servers per region!) but you could keep them in reserve and only deploy them as needed.

Manually copying Apollo config for environment setup was still kind of a thing though. The ideas of CloudFormation hadn't quite filtered down yet.

Exhibit B: logs

My memory's a bit hazy on this one. There certainly was a lot of centralized logging and monitoring infrastructure. Pretty sure that logs got pulled to a central, searchable repository after they'd existed on the hosts for a small amount of time. But, yes, for realtime viewing you'd definitely be looking at using a tool to open a bunch of terminals.

The monitoring tools got a huge revamp about halfway through my tenure, gaining interactive dashboarding and metrics drill-down features which were invaluable when on-call. I'm currently implementing a monitoring system, so my appreciation for just how well that system worked is pretty high!

Exhibit C: service discovery

Amusingly, a centralized service discovery tool was one of the tools that used to exist, and had fallen into disrepair by the time this person was working there.

This was a common pattern in Amazon. Contrary to the 'Amazon doesn't experiment' conclusion, Amazon had a tendency to experiment too well - <USER2> Next Big Thing was constantly being released in beta, adopted by a small number of early adopters, and then disappearing for lack of funding/maintenance/headcount.

I can't think of any time I hard-wired load balancer host names though. Usually they would be set up in DNS. We did used to have some custom tooling to discover our webserver hosts and automatically add/remove them from load balancers, but that was made obsolete by the auto-scaling / continuous deployment system years before I left.

As for the question of "can we shut this down? who uses it?" \- ha, yes, I seem to remember having that issue. I think that, before my time, it wasn't really a problem: to call a service you needed to consume its client library, so you could just look in the package manager to see which services declared that as a dependency. With the move to HTTP services that got lost. It was somewhat mitigated over the years by services moving to a fully authenticated model, with client services needing to register for access tokens to call their dependencies, but that was still a work in progress a few years ago.

Exhibit D: containers

Almost everything in Amazon ran on a one-host-per-service model, with the packages present on the host dictated by Apollo's dependency resolution mechanism, so containers weren't needed to isolate multiple programs' dependencies on the same host.

Screwups caused by different system binaries and libraries on different generations of host were a thing, though, and were particularly unpleasant to diagnose. Again, that mostly went away once AWS was a thing and we didn't need to hold onto our hard-won bare-metal servers.

'Amazon Does Not Experiment'

Amazon doesn't really do open source very well. The company is dominated by _extremely_ twitchy lawyers. For instance, my original employment contract stated that I could not talk about any of the technology I used at my job - including which programming languages I used! Unsurprisingly, nobody paid attention to that. That meant that for many years, the company gladly consumed open source, but any question of contributing back was practically off the table as it might have risked exposing which open source projects were used internally.

A small group of very motivated engineers, backed up by a lot of open-source- friendly employees, gradually changed that over the years. My first ever Amazon open source contribution took over a year to be approved. The ones I made after that were more on the order of a week.

Other companies might regard open sourcing entire projects as good PR, but Amazon doesn't particularly seem to see it that way. Thus, it's not given much in the way of funding or headcount. AWS is the obvious exception, but that's because AWS's open source libraries allow people to spend more money on AWS.

Instead, engineers within Amazon are pushed to generate ideas and either patent them, or make them into AWS services. The latter is good PR _and_ money.

As for different languages: it really depends on the team. I know a team who happily experimented with languages, including functional programming. But part of the reason for the pushback is that a) Amazon has an incredibly high engineer turnover, both due to expansion and also due to burnout, so you need to choose a language that new engineers can learn in a hurry, and b) you need to be prepared for your project to be taken over by another team, so it better be written in something simple. So you better have a very good justification if you want to choose something non-standard.

Overall, Amazon is a pretty weird place to work as an engineer.

I would definitely not recommend it to anybody whose primary motivation was to work on the newest, shiniest technologies and tooling!

On the other hand, the opportunities within Amazon to work at massive scale are pretty great.

One of the 'fun' consequences of Amazon's massive scale is the "we have special problems" issue. At Amazon's scale, things genuinely start breaking in weird ways. For instance, Amazon pushed so much traffic through its internal load balancers that it started running into LB software scaling issues, to the point where eventually they gave up and began developing their own load balancers! Similarly, source control systems and documentation repositories kept being introduced, becoming overloaded, then replaced with something more performant.

But the problem is that "we have special problems" starts to become the default assumption, and Not Invented Here starts to creep in. Teams either don't bother searching for external software that can do what they need, or dismiss suggestions with "yeah, that won't work at Amazon scale". And because Amazon is so huge, there isn't even a lot of weight given to figuring out how other Amazon teams have solved the same problem.

So you end up with each team reinventing their own particular wheel, hundreds of engineer-hours being logged building, debugging and maintaining that wheel, and burned-out engineers leaving after spending several years in a software parallel universe without any knowledge of the current industry state-of-the- art.

I'm one of them. I'm just teaching myself Docker at the moment. It's pretty great.

<comment><USER29> Speaking of twitchy lawyers and Move to AWS... one of the weirdest things we had to deal with inside Amazon was that, for many years after AWS launched, we weren't allowed to use it because it "wasn't secure enough".

Given that we were actively shopping it around to major financial institutions at the time, doesn't that strike you as particularly hypocritical? :)

<comment><USER30> So wait, when I need to convince customers why AWS is secure for their data, I can't say "It's good enough for Amazon!"?

<comment><USER31> To clarify, an AWS customer has a shared responsibility to describe the security of their systems including how they use AWS tools, and in this respect Amazon is no different than other AWS customers.

</comment></comment></comment></comment><comment><USER32> Someone should probably add (2018) to this post as it's from May 2018.

<comment><USER33> Email email@example.com and they will take care of it.

</comment></comment><comment><USER34> I will be joining Amazon in about a month.

Is there _any_ chance I'll be able to work on OSS and/or "modern" tech (e.g. containers, Go, etc.) without a ton of push-back?

It also seems Amazon is obsessed with reinventing wheels and keeping their stuff internal, which is worrying. Is there any chance to introduce solid OSS tools to the development process? (whatever they might be)

<comment><USER35> AWS SDE here.

The short answer is, in order to get your team to adopt something, you need to make the case that it's better for customers (including things like migration costs). If the modern thing is more efficient, is higher availability, increases velocity, and so on then the case can be made.

Some specific examples based on things you cite:

* For an example of something OSS or "modern" coming from AWS, checkout Firecracker (written in Rust): [https://firecracker-microvm.github.io/](https://firecracker-microvm.github.io/)

* With regards to "reinventing wheels" Apollo + EC2 solves a lot (not all) of the problems that containers solve, and existed for years before containers became the hotness.

* Docker, which brought containers to the masses launched in 2013.

* EC2 launched in 2006 (7 years before Docker).

* Apollo (and the build system Brazil) predated EC2 by many years.

* Amazon.com was migrating to EC2/AWS before 2012 ([https://www.youtube.com/watch?v=f45Uo5rw6YY](https://www.youtube.com/watch?v=f45Uo5rw6YY))

* Another example, Lambda, which launched in 2014 runs on EC2 ([https://www.youtube.com/watch?v=QdzV04T_kec&t=1611s](https://www.youtube.com/watch?v=QdzV04T_kec&t=1611s)).

* New services get to build in AWS and use Lambda, ECS, DynamoDB etc based on their business needs.

<comment><USER36> Worked for EC2 as an SE ~ 5 years ago. We used to handle rack downs and page the relevant team if there was a large set of instances for the said team impacted. We once had a couple of hundreds of Amazon.com (merchant team) instances impacted. We paged the team and they were like "don't page us for anything less than 10 racks of our instances down". The burgers didn't even feel the impact. Their automation was insane.

</comment></comment></comment><comment><USER37> Getting an npm or other package approved for internal use is not an unusual practice.

<comment><USER38> Yes, but it probably makes Node.js useless in any such company since any non- trivial app will have 1,000 npm dependencies.

<comment><USER29> Yeah. I did this once a few years ago, and it was quite unpleasant. Did get it done in the end, but it definitely put my team off looking for any other useful NPM packages.

I wonder if it's any more streamlined now?

<comment><USER39> There's some internal builds tools that I can vouch for. If you're still at Amazon, feel free to ping me at dbarsky@ and we can chat.

</comment></comment></comment></comment><comment><USER40> The OP needs to put a date on the article, because AFAIK things are very different in 2019.

Also, it's interesting how they equate "experimentation" with "open source".

</comment><comment><USER41> Considering the constant stream of new services and feature, the lack of OSS is insignificant compared to value they add to the world.

Like the fact that you can create an SSL/TLS certificate for free for load balancers without the usual agony. So easy.

</comment><comment><USER42> I worked at Amazon in the late 90s. So my experience is most likely not relevant anymore, but I will make a few observations. First, I see that many commenters disagree with the OP, they had a different experience of Amazon, one where they were working with infrastructure that was responsive. modern, easy to use etc. It very possible that both observations are correct. In a large company, not all parts of the company will be using the same infrastructure at the same time. Indeed, I would be dangerous for the entire company to upgrade lockstep to a new technology infrastructure. Second, in most companies, innovation is not measured by the novelty or newness of the language or framework you use, but by the business impact your product or service makes. Much of Amazon's innovation was, and is, around business models. Indeed, when I worked at AMZN, I was writing C code (to power a website) using beautifully efficient database access code written by Sheldon Kaphan. There was nothing remotely advanced about the language. It took 9 months for me to get a 3 line code change into production. And I was using technology that predated Apollo (it was called Huston) There is nothing particularly wrong about that either (it was a potty mouth filter and was blocking some obscure swear words, and no one was too worried that the component it was part of didn't ship for the best part of a year.) I now run my own company, and I both manage technology, people as well as write code. I find myself exercising the same conservatism with respect to code and infrastructure that I found at Amazon, and for the same reasons. It is expensive and potentially company destroying to switch languages and core technologies. It is best not done, or if done at all, done with a lot of care and slowly.

</comment><comment><USER43> I was once pitched a startup founded by some ex-amazonians whose big idea was "Apollo for everyone". They were nonplussed by my spit take.

For the people saying "I worked there and it wasn't like that" I wonder if you worked in retail. It's a very different world from the more modern bits of the company.

</comment><comment><USER44> What amuses me is that most of retractions come from ex-Amazonians not from the current staff. This is the only company i know dealing with that much criticism from engineering.

Even more to add is that the article is more or less fresh and at Amazon's scale i doubt any major changes had undergone in the last 10 months.

<comment> amzn-throw There is a comment above you from an Amazon Principal Engineer: [https://news.ycombinator.com/user?id=jcrites](https://news.ycombinator.com/user?id=jcrites)

His profile says "Architect and cofounder of Simple Email Service. Creator of Cloud Desktop, a cloud-based development environment used by most Amazon engineers. Technical lead for Amazon's strategy for using AWS."

Can't get more "From the horse's mouth than that"

We are generally asked not to comment on stuff like this because of how easy it is to reveal confidential internal details.

For the record, the article is mostly wildly out of date, but others have already corrected the record.

<comment><USER44> I'm aware current employees comment over here. Two things to mention: principal/architect roles are always based not only on a merit of skill but politics. So, taken with a grain of salt.

Moreover, if you inspect the person's comments you will notice how "legally" clean they are. Even the phrasing looks the same for both comments "based on my experience", "this information if wrongful" etc. Looks like those were refined by the legal team before posted.

I wonder all that, because since my first engagement with AWS and Amazon recruiting around five years ago the engineering tone did not change. That concerns in a way that putting an effort to get a job there may turn out a major disappointment.

The cutthroat approach is nice sometimes as it adds the taste of competition but the whole noise seems like you're about to get buried rather than played or burned out.

<comment><USER45> translation of the first two paragraphs is "I've decided what I think already and if you say you work at Amazon now and are happy it's prima facie evidence that you can't be trusted to be objective about it"

<comment><USER44> Sort of.

If it's a liability to say nasty stuff about the employer and most of the ex- ones throw some heat the nearest possible conclusion is that the truth tends to bow to statements that are observed as outdated and controversial by present employees.

It just can't be a smear campaign against just that one company.

</comment></comment></comment></comment></comment><comment><USER46> The main benefit for amazon's tools is once you've been there a while you know how they work, and all the complexity and bugs have been stripped out of them. And because they force engineers to go oncall everyone has a pretty good idea of how to fix things.

When you have SRE's spending all day creating the next new thing (generally after deprecating the previous one with no replacement), you end up in a situation where you forget how to say, rollback a bad deployment. Or scale a fleet.

The problem with fancy infrastructure as code, containers and logging services is when they break you have no idea how to get out of trouble. SSH and grep almost always work, as does symlinking a directory.

</comment><comment><USER47> > "It's complicated, so it's gotta be good. I must be dumb to not get it."

Having worked with aws a lot recently, this article doesn't surprise me at all actually. When you see the low quality of UI and documentation for most of their tools that users pay for, I wouldn't expect their internal tooling to be any better.

I'm not saying their tech is bad, once things work, it works great - I'm talking about the usability of those tools as I try to use them, and it makes me feel the same as the OP's quote.

<comment><USER12> If you are using the UI to leverage AWS you arent really leveraging AWS.

AWS is designed to be used via automation and the API.

Disclaimer : I dont work for AWS but have spent many years building relatively large stacks on AWS (thousands of ec2 instances with monthly spend being a couple supercars in value)

<comment><USER47> yes, but before using the API you need to know which API to use. If you are looking into using a new service, say, analytics. Which coupling of services do I use, between cloudwatch, firehose, etc etc. Or reading documentation for example. They have terrible documentation.

Someone using their API/cli is already familiar with aws and how it works. The point, before getting to that point, you need good docs and UI to allow people to discover and learn.

</comment></comment></comment><comment><USER48> The author is wrong about his description of tooling and best practices at Amazon.

I'm also annoyed that the post isn't dated anywhere so there's no way for me to tell if it's just old.

</comment><comment><USER49> Looking through the rest of the blog, it looks like the author worked at Amazon between 2014 and 2016.

</comment><comment><USER50> This article is so outdated from what the current state is and has been for quite a while now.

</comment><comment><USER51> To me, it sounds like a company who is still working with the mentality of 90s. The same I'm facing at work, where new technology is treated as scary and there's fear of change something that (somehow, only God knows how) is working and none is allowed to touch such things

<comment><USER52> New technology _is_ scary. It should be scary. If you don't find it scary you're probably not looking at it right. It's usually full of risk, which if you are in management (or a remotely responsible employee) needs to be evaluated and if possible contained, and ultimately needs to pay for itself (i.e. Offers a pay-off that more than outweighs the risk).

If we are honest with ourselves, most new tech in this industry totally fails that litmus test.

There are an awful lot of shiny-bauble chasers and snake oil salesmen both inside and outside companies.

I don't know what your precise situation is and obviously it's very much a spectrum rather than black and white, but a healthy aversion to promises made by the authors and salespeople of relatively unproven new things is extremely valuable.

</comment></comment><comment><USER53> I think there is no serious authenticity associated with this blog post.

</comment><comment><USER54> This matches my experience using the internal tools pretty well.

But hte team I was on was mostly using AWS, which meant the tooling was better.

We also had a bunch of people who wanted python instead of Ruby, so they started using python and eventually we were just a team that used python. Cool.

Apollo is probably the worst thing. Brazil, Pipelines, etc... those are mostly fine.

Amazon has done a ton with the JVM. They don't need something new, so they don't bother. That's fine.

They also do adopt other tech as needed to do things. I know people who worked in Go, because it was container stuff.

This was also one of things that gave me pause when considering interviewing with snap a while back. So many former Amazon people. Seemed like a lot of stuff was going with "just copy amazon, make it a bit better". I don't want to write java. bleh.

Anyway, this article is going to have a lot of people saying "oh no that's not right". It is. There are exceptions but overall it's pretty much bang on.

Oh and open source. My understanding is jeff doesn't like contributing back. The company doesn't like contributing back. They keep an iron grip on IP. They are ridiculous about letting employees do side projects. They fight back with every single FOSS contribution and even after some of our senior guys did a whole bunch of work it still required multiple layers of approvals and a whole bunch of hooops and an extra training course and blah blah blah blah. It's really really dumb. I find it crazy that Amazon doesn't get more flak for being probably the worst company for open source around right now.

But MS has tossed out their old CEOs, has tons of interest in making open source work well for them, and contributes loads... still get shit on.

<comment><USER55> Working on a side project is super easy. Just file a TT (or I guess SIM now?). As long as it isn't competing and not a game, it's generally quick approval.

<comment><USER56> What is the issue with games?

<comment><USER55> Amazon owns game studios and might have many different game concepts being worked on, such that an employee might inadvertently compete with a similar game studio idea.

</comment></comment></comment></comment><comment><USER57> In my career I've experienced alot of engineers that had a desire to shy away from command line or command prompt tools, shell, CMD.exe, batch, scripting, cron and related 'traditional' automation, in favor of GUI, IDE, html, browser etc.

I've even had some young sexy angular-wizard type engineers that had the ear of mgmt sarcastically respond with statements like "I don't do command line".

This article and my experience with AWS development and Amazon leads me to believe this entire company is led and staffed by such engineers.

</comment><comment><USER58> It's hardly surprising. The quality of their public products isn't much better than what's described here. It's fine for companies with plenty of engineers, money, and time to base their tools off of, but that's about it. Without building a ton of extra tooling and having specialized information only available through paid support, it's almost impossible to operate anything on aws. The documentation is plentiful, mostly out of date, wrong, incomplete, and difficult to browse, search, and use. Doing devops using aws is a nightmare that never ends. Not to mention the speed of deploying anything is beyond slow, so any work takes many times the amount of time it should. For large companies with plenty of resources, these are minor points. For small and medium sized ones, it's a loss of productivity and money that simply cannot be justified over other methods.

<comment><USER59> Dang probably true for the products you were using but Redshift has been great for me, including the documentation which I have never found to be out of date.

I wouldn't say its the economical option though.

Oh and its high time 'count(distinct) over()' partitions was supported.</comment></comment>


OpenCart Issue #1286 (Full comments) - <AUTHOR> https://gist.github.com/uppfinnarn/9956023/

<comment><USER2> The way he handles his PR is ugly. Exclamation mark in every reply. Is that necessary?</comment>


Foveated 3D Graphics (2012) [pdf] - <AUTHOR> http://research.microsoft.com/pubs/176610/foveated_final15.pdf <comment><USER2> I always thought this was an approach that would be well suited to ray tracing or similar. Both ray tracing and rasterisation are proportional to scene complexity and pixel count, but the balance is different. Ray tracing handles scene complexity better and rasterization covers pixels quicker.

The excellent [http://www.adriancourreges.com/blog/2015/11/02/gta-v- graphic...](http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics- study/) shows how many pixels are written to to construct a scene using rasterization. Many many intermediate render targets are involved. Any intermediate layers that are not directly in screen-space would not benefit from foveation.

Raytracing/ray marching etc. working on a pixel by pixel basis would be far more suited to larger fuzzy pixels where you are not looking.

</comment><comment><USER3> This is definitely the future for both desktop and VR gaming. There is no way games will go to 4k and beyond at 2x60hz and spend 60 rendering passes doing pixels in the top left corner of the screen. The question is what will happen to console gaming? The eye tracking issue isn't quite as easily solved for consoles.</comment>


XARs: An efficient system for self-contained executables - <AUTHOR> https://engineering.fb.com/data-infrastructure/xars-a-more-efficient-open-source-system-for-self-contained-executables/ <comment><USER2> Facebook switched from PHP to Python? That's new to me.</comment>


Ride-hailing apps have allowed more binging and increased demand for bartenders - <AUTHOR> https://www.economist.com/graphic-detail/2019/11/19/after-uber-arrives-heavy-drinking-increases <comment><USER2> I feel like this article disingenuous. Uber has reduced drunk driving accidents by 62%!! (in Portland, but likely similar for other cities) That's huge.

A 10% increase in heavy drinking seems small by comparison. Why not focus on that fact? Well, because it makes Uber look good, for one thing. Can't have that.

<comment><USER3> > A 10% increase in heavy drinking seems small by comparison. Why not focus on > that fact?

10% seeming smaller than 62% is not a _fact_ that anyone should be focusing on.

There are actual numbers that can be compared in context; the fact that a percentage of one thing is expressed as a larger number than the percentage of another thing doesn't mean it's more important. Very few people die of drunk driving accidents (as compared to the number of people who drink), so if 20 fewer people in an area per year die from drunk driving, but incidents of binge drinking in that area increase from 1 million to 1.1 million, it's not simple to say that the outcome has been positive. Maybe 21 more people get esophageal cancer. Maybe 21 more cases of domestic violence end in a homicide.

That being said, this is a wealth effect and inevitable if you're making progress. People are drinking (out) more because their perception is that with rideshares it has become safer (easier to get home.) A cure for HIV would cause an increase in the spread of other sexually transmitted diseases, for example, but that doesn't mean that you shouldn't cure HIV.

One material difference I can see between rideshares and a cab is that rideshares are often cheaper because 1) they are subsidized by investors and 2) they can be shared. This doesn't say anything interesting about Uber; if you wanted to make cabs cheaper, you can tax them less or subsidize them. The other, which I think might be more important, is that many rideshare users don't feel the need to buy a car, and that the rideshare demographic is largely similar to the binge drinking at bars/clubs demographic. Of course, taxing cars or the parking around bars/clubs could have the same effect.

<comment><USER4> I agree with you on all but pointing out the cancer rates.

If we're looking at it purely from a statistical point of view, then yes, the numbers might not look that good in favour of "more drinking + ridesharing is better than less drinking + drink driving".

Ethically, I consider people drinking themselves to an early grave of their own free will to be "less bad" than a drunk driver killing someone else on the road or a drunk person committing a violent crime against another person.

I make this point in the context of the rest of what you've said, though, which raises good discussion points about "should we fix X really bad thing if it leads to people doing more of Y maybe-less-bad thing?"

<comment><USER5> Ethically weighting deaths is a dangerous road. What would you say to "Innocent deaths from drunk driving go to 0, but suicides increase 1000-fold"?

<comment><USER4> This is a question I don't feel equipped to answer, despite having asked myself many times.

I think it's widely accepted (and I believe) that "drinking + driving + killing someone else = very bad", and that "drinking + assaulting = very bad", but I don't think I know enough about the health implications of drinking.

If a person really was drinking themselves to death of their own free will (i.e. they are aware of the physical health effects, and they do not experience any addictive effects from alcohol), then I don't see an ethical issue with them choosing to do that.

But if suicide rates go up, why could that be?

My opinion is that if someone who chose to drink (i.e. knew the risks and was not addicted) accidentally fell off a bridge or accidentally shot themselves with their own gun, it is _their own fault_.

When someone is suffering in terms of mental health such that they are addicted to alcohol, or are depressed, or feeling suicidal, then I just don't know. It feels to me like that although the alcohol is not the root cause in these situations it definitely could've pushed them over the edge. I think this is analogous to "someone who felt suicidal committed suicide after another person told them to jump off a building"... I really don't know where I stand on the issue.

</comment></comment></comment></comment></comment><comment><USER6> Yea the tipping point for self driving cars will be when it can drive you home while drunk legally. Probably will be made legal first someplace like South Korea — there you can easily pay somebody to show up with their buddy on a scooter to drive your car home for you with you in the passenger seat. The guy on the scooter follows you and picks up his buddy. I forget what the pricing was but it was something like 2x the cost of a taxi. So wasn't actually too crazy.

<comment><USER7> There was an affordable service that would drive your car home for you. The problem leading to its failure, as I understand it, is that drunk people that needed it were too wasted to remember that it existed.

<comment><USER8> That's funny in a sad way. I do remember that being a thing ~10 or 15 years ago - they were at least demo'ing it at one of the blocks in my city where a large concentration of bars could be found. I was very curious on the technology of their fold-able scooters (how quaint given Lime at al)

I could also imagine having to drive a drunk person's car home would be somehow risky, given that you have no idea how said person will act with their property.

</comment></comment></comment><comment><USER9> There are probably a lot of factors that have contributed to the increase in high risk drinking, but even if we ignore that, I feel like the trade-off being made here is acceptable.

People who maybe prior couldn't imbibe due to no public transport options etc, have decided now that with ride-hailing apps that this is an available option. Whether or not you agree with the choice they are making, the fact that they even have the choice seems worthwhile.

<comment><USER10> I'm very happy with a tradeoff where people damage their own health instead of innocent people on the road.

I also wonder how much of this increase in drinking at bars is drinking that would have happened at home previously.

</comment></comment><comment><USER11> Maybe now that there are viable alternatives to getting to and from home/work the law here in the States will catch up to saner legislation elsewhere and properly punish drunk driving instead of a slap on the wrist for the first few offenses "don't do it again but here is your license, you can keep driving."

<comment><USER12> Allow me to give the standard response about how driving is necessary here. DUIs are not cheap, not convenient, but someone shouldn't become unable to provide for their family based on one.

<comment><USER13> I live in Ireland. Driving is essential here, unless you live in a major city.

Nonetheless, we clamp down hard on drink-driving, to such an extent that I was massively shocked by how acceptable it was in the US.

<comment><USER12> Sounds like Arizona here. Penalties are extremely harsh there.

</comment></comment></comment></comment><comment><USER14> found the paper: [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3484845](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3484845)

</comment><comment><USER15> I wonder about other changes as various things change.

Could self driving cars mean more driving? / car related demand?

I drive my family around all the time. I'm not a fan of it, but if my car drove itself I'd probabbly be quite happy to plan additional / longer driving trips. I'd certainly like to setup my minivan as a series of mini desks everyone could sit at .. I could do lots of things during trips...

<comment><USER16> My kids have a lot of after school activities which my wife spends hours a day bringing them to and fro, even when they are more than capable of doing the activity entirely independently and don't expect to be watched by a parent during the activity.

For some reason it's deemed "not appropriate" for them to Uber to and fro. Occasionally there will be parents who we can carpool with, but almost always it ends up being a huge time suck to drive them, wait around, and then bring them back.

I think it's not so much an issue of them being in a car alone, it's the random stranger driving them that makes it hard for a, e.g. 10-16 year old to get around on their own if they can't walk, bike, or take public transit.

So my guess is that a self-driving car will be more acceptable to bring kids around the suburbs to all their after-school activities. Which is a massive productivity boost for the parents, basically freeing up an entire human for 4 hours a day.

<comment><USER17> It's not uncommon for wealthier families here in Guadalajara to have their 13-year-old daughter Uber around.

We sure do like our coddling in the USA, though, where it's even safer.

An example of someone writing about the problem: [https://www.thecoddling.com/](https://www.thecoddling.com/) \-- Makes a good case how instilling these ideas in our youth that everyone is out to get them comes back to bite them (and us all) in the ass as they enter adulthood.

An example of an org trying to fix it: [https://letgrow.org/](https://letgrow.org/)

Of course, a self-driving car is even better than an Uber driver for various reasons, not the least because ape-driven vehicles aren't particularly safe.

<comment><USER15> I feel like choosing to uber or not is a big distance away from "coddling".

</comment></comment></comment></comment><comment><USER18> Jokes' on them, the Bay Area responded to this new challenge by having no place to go drink or have fun. Problem solved!

<comment><USER19> wait what? I live in Bay Area and can confirm there are a lot of places people drink and have fun.

</comment></comment><comment><USER20> I will note one cheerful conclusion: so many people care so much about not drinking and driving. (Consider that 30% of the people don't drink, and another 30% drink rarely, these statistics are a credit to the species.)

I look forward to people pointing out the flaws in this reasoning.

</comment><comment><USER21> I feel like there is a huge demographic issue underlying these numbers. The cohort of young adults in the US probably peaked around 2012, so more binge drinking is likely caused by that alone. (I didn't read the paper the article is based on so maybe my point is covered there)

</comment><comment><USER22> Whilst Uber and the like have improved the cab situation in UK cities, it's hardly been revolutionary. It's become a bit more convenient and (sometimes) a bit cheaper.

What was the situation like in places like Portland before Uber? Were old- school cabs just unavailable or just really awful?

<comment><USER23> Not Portland but I lived/drank in Eugene for awhile when Uber/Lyft were still banned (IIRC they've since been let in). Outside of metro areas there is only one answer to that question in my opinion, lots of drunk driving.

<comment><USER22> > Outside of metro areas

I guess this is key. Most places in the UK aren't that far from a town.

Does "metro area" have a precise definition? Would an small to medium UK town count?

<comment><USER23> In this context it's about mass public transit options and walking distance between a safe residence and wherever "downtown" is. Eugene and adjacent Springfield combine for a population of ~220,000 over ~88 square kilometers with limited late night transportation options other than sketchy and unreliable taxis.

</comment></comment></comment></comment><comment><USER24> Imagine what fully self driving cars will do, uber without the cost

<comment><USER25> Why would you assume there is no cost? Either you hve to buy it, or rent it as a service. You are still paying either way.

<comment><USER26> through scaling the cost to the provider should be much lower, which means either the cost to the consumer will either be less, or there will be a great opportunity for competition.

</comment></comment></comment><comment><USER27> Good thing there is no reasonable public transit in US and no plans to improve it. Imagine the amount of binge drinking that would ensue!

</comment><comment><USER28> I always thought that once self-driving cars are fully autonomous, pub/bar business will go through the roof.

<comment><USER29> Concur in part. When I am on vacation under the right circumstances, such as multi-day Disney visit or cruise, I do drink more. Some people would probably drink more just because it would be safe, but I think a lot of people would dial it back again due to hangovers interfering with work.

Maybe not "through the roof" but definitely a sustained increase.

<comment><USER28> I should have said - I'm talking about the UK here. More of a drinking culture than, say, the US :-)

</comment></comment></comment><comment><USER30> It's odd how each graph shows a dip at -1 year.

</comment><comment><USER31> Correlation is not causation.

</comment><comment><USER32> Alcohol consumption is horrible for public health though :(

</comment><comment><USER33> Correlation does not mean causation

</comment><comment><USER34> Can confirm, definitely see many more drunk assholes loitering outside the bars on my street.</comment>


Preparing for Continuous Delivery: Understanding your deployment process - <AUTHOR> http://rdbl.co/preparing-cd <comment><USER2> I've prepared packages and distributable for many enterprises and it's always CD as in continuous delivery not deployment, except on dev servers. A delivery may be a zip archive run via bash or powershell, or more of traditional msi packages and if necessary installed as part of the build pipeline. But remember, delivery means the package is delivered, it doesn't have to be installed.. But it could, and I've built releases this Week alone that _large government agency here_ has allowed me to deploy as it contained just the change they needed.

</comment><comment><USER3> I wonder how many companies are really using Continuous Deployment. Can somebody share their experience with that.? Is it feasible to remove QA people and dedicate that to developers?

<comment><AUTHOR> It's feasible, as long as you can tolerate a bug for a short time. The advantage is that once you notice a bug, there's less in the way of getting a fix out to production.

And let's face it: we're all tolerating bugs in production all the time.

As an aside, CD doesn't obviate QA or testing. It strongly favours automated testing over the manual flavour, especially during integration, but even then there's nothing stopping you from conducting manual tests on your branch before integration.</comment></comment>


Embedded in Minecraft: Uncensored Library Can Get You Killed in Some Countries - <AUTHOR> https://themindunleashed.com/2020/03/embedded-inside-minecraft-is-the-uncensored-library-of-articles-that-can-get-you-killed-in-some-countries.html <comment><USER2> I didn't see where in the article it said going to this library inside Minecraft could get you killed. I saw that in Minecraft there is a library that OUTSIDE of Minecraft, had you been caught accessing the same literature, could be harmful. Misleading headline?</comment>


Is 1I/'Oumuamua an Alien Spacecraft? - <AUTHOR> http://sites.psu.edu/astrowright/2017/11/22/is-1ioumuamua-an-alien-spacecraft/ <comment><USER2> Why would anyone want to do an almost full 180 on an interstellar spacecraft? There is very little delta-v to be gained from that.

It's not like the gravity assist from the Sun would compensate for the extra couple hundred thousand years from the detour.

<comment><USER3> It's an "angle of 66° from the direction of its approach" says [https://en.wikipedia.org/wiki/%CA%BBOumuamua#Trajectory](https://en.wikipedia.org/wiki/%CA%BBOumuamua#Trajectory) . Not "almost full 180".

It's not an interstellar spacecraft. I started to think of examples, but none make sense with what we know. It'll still be within our Oort cloud for the next 20,000 years, and it doesn't seem lined up with anything previous or next.

<comment><USER2> OK, it's a 130 degree turn. Still, it's quite a detour if you are trying to get from A to B.

And sure, it's not likely to be an interstellar spacecraft, but a very weird object still.

And even if it were an interstellar craft, it'd be a seriously lame one using a gravity assist ;-)

</comment></comment></comment><comment><USER4> Maybe it was scanning us?</comment>


Ask HN: Where do you find software engineering jobs? - <AUTHOR> LinkedIn? Networking? StackOverflow Careers? GitHub Jobs? What techniques/sites do you use? What methods are most effective? <comment><USER2> If you look for something local, why not just write a good resume and pick those companies around you that actually interest you and just go for it?

I am all for tech platforms, but when i want to work with this company i prefer real human to human interaction over everything.

</comment><comment><USER3> Let's see. My first job, I got when a job offer fell through, and the hiring manager told me about this other company that had a similar job open. My second job was after reading about a startup launching and emailing them. My third was when I joined former co-workers. My fourth was when I contacted people I used to work with.

I guess you can call it mostly networking. Obviously, networking works better as you gain more experience, start knowning more people and get better technically.

</comment><comment><USER4> You could get more specific advice with some more info. Where are you? How much experience? Looking for remote or onsite? What technology do you know well?

Generically, I like SO careers -- you don't need rep on it to apply to jobs.

The most effective application advice I could give is to make your resume and cover letter specific to the job you are applying for. Your cover letter should be treated as a writing sample that is an argument for why you should be hired for the specific job being offered.

<comment><AUTHOR> Thanks for the reply--

I have about 6 years of experience. I'm a senior team lead at a bay area startup.

I'm really looking for what areas to 'focus' on.

1\. I don't think SO career profile is worth maintaining. You're right, the job selection/application process is nice and simple. 2\. Resume/cover letters are still very important and need to be maintained/tailored to each job. 3\. LinkedIn seems like a good networking/reference tool so should probably be maintained. 4\. Dice.com? Doesn't seem worth maintaining to me.

It seems to me directly applying for positions with a nice resume/cover letter are still #1. A decent LinkedIn seems to help showcase recommendations/network, but isn't super important.

As for tech, I feel I am comfortable with anything from C/C++ to Ruby/Python/Go to JavaScript. I have experience on mobile, desktop and web development. I'm open to all opportunities but hoping for mobile/desktop or backend work.

I only have 6-ish years of professional experience but I've written code from a young age and have a number of open source projects as well as contributions to major projects like Vim, Homebrew, etc.

<comment><USER4> If you are actively looking, I'd try hired.com.

For passive (just being out there), SO inbound is way higher quality than LinkedIn. LI is spammy for me.

The last time I did a massive search (2006), I really liked indeed.com for aggregating. I made an RSS to a very specific search term. It took months to even get one hit, but I worked there for 7 years.

</comment></comment></comment><comment><USER5> So far, I've had my best (and) worst luck through networking - facebook and email.

I get contacted by recruiters and resume/remote work startups through HN and Linkedin, but neither has resulted in actual employment,

I would suggest _trying everything,_ but focus on personal networking if your resume and CV aren't stellar, or you aren't in a large market.

</comment><comment><USER6> I got my last 2 jobs simply by updating my LinkedIn, and having recruiters contact me. Both were high-paying, high-profile, really painfully awful jobs. I'll be looking out for ways of getting actually good jobs, assuming such a thing exists.

</comment><comment><USER7> I managed to find jobs in my field just by sitting on IRC channels, like those specific to a platform or technology that I'm good at/currently using/can help others with.

I guess it's similar to having a good rep on SO and getting recruitment offers through there.

</comment><comment><USER8> I've had surprisingly good luck on craigslist, I find both small and large companies post on craigslist. Networking, as everyone else has mentioned, is definitely the easiest approach and usually produces good quality leads.

</comment><comment><USER9> Right here on HN is a good place to start. There is usually a who is hiring and who want's to be hired thread every first week of every month.

</comment><comment><USER10> I'm a fan of landing.jobs

</comment><comment><USER11> I got my current job by being reached out to on Dice.com

</comment><comment><USER12> i search city/local-specific tech job boards as well.</comment>


Long Lines for Women's Bathrooms Could Be Eliminated. Why Haven't They Been? - <AUTHOR> https://www.theatlantic.com/family/archive/2019/01/women-men-bathroom-lines-wait/580993/ <comment><USER2> Women don't pee any slower than men. Men, being gross and all, we are willing to pee communally, women are typically not. Does anyone really _want_ to pee in a trough with a bunch of others watching with their wandering judging eyes???

To achieve parity, remove urinals and place sinks above waist height (yes for _that_ reason). Hell who am I kidding, just remove the sinks as well.

Now everyone will pee privately, in their own stall making things slower, but no one will wash their hands speeding things up.

Bathroom parity achieved!

<comment><USER3> Why do the sinks have to be gender specific?

<comment><USER4> Men pee in the sinks in the less reputable venues...

<comment><USER3> But they already offered a solution to that.

</comment></comment></comment></comment><comment><USER5> Seems pretty absurd that the government is requiring buildings to have more stalls for women than men. Shouldn't companies have the freedom to decide what ratio is required for their building? Or at least to make the ratio equal? I mean the easiest solution would be to just make it all unisex, maybe with a separate area for urinals or something, but I don't see that happening any time soon.

And I'm not sure why they jumped to sexism as a cause of the issue - as they pointed out later in the article, men and women have fundamentally different bathroom needs, and take different amounts of time.

</comment><comment><USER6> Yeah, the opposite is true in many Silicon Valley offices - the male's toilet has a line after lunch.

<comment><USER7> And people wonder why the potted fern in my office is so much healthier than all the others.

Seriously the reason the line is so long for the women's room is because the bosses don't care because they use the men's room.</comment></comment>


SETI: No Signal Detected from KIC 8462852 - <AUTHOR> http://www.centauri-dreams.org/?p=34363 <comment><USER2> When my great grandma was born, we didn't have flight, radar, lasers, radio, etc... Why would we think that a civilization capable of building massive space structures would be communicating in such a slow and imprecise way. The idea that we've discovered all there is to know about communication over vast distances is hubris.

We can't see anything because we have not yet discovered what we're looking for.

<comment><USER3> That we would receive a signal with the radio telescope discussed here would pretty much demand either that they make tremendous use of a very specific form of propulsion, or that they are putting a substantial fraction of their available energy into contacting civilizations of precisely our technological level. There's no thought that we'd pick up their radio chatter between themselves- we couldn't pick up Earth's radio noise from that distance, and we're only getting quieter as our technology becomes more effective.

Aliens in the business of contacting emerging civilizations must find themselves with an interesting tradeoff between transmitter power usage and contactee technology level- at a guess, it would be exponentially more expensive to contact species earlier on in their development. We may still just not be far along enough that the cost-benefit ratio makes sense to talk to us.

<comment><USER4> First time I started reading about quantum computers and the idea of entangled particles I immediately thought it would be a neat way to solve long distance space Comms. Anyone with a better brain than me care to explain if it could be a possibility?

<comment><USER5> In short, "it doesn't work the way you think it does"

People keep digging in this area because it's hard to measure accurately so we're not 100% yet, but the current consensus is that the interaction between entangled particles, isn't faster than light and should not be faster than light.

<comment><USER6> Do the effects of gravity move faster than light?

</comment></comment></comment></comment></comment><comment><USER7> Well, if it's actually a Dyson swarm in the making, we'll find out, watching the star go gradually dark during the next few hundred (or thousand?) years..

<comment><USER8> It's an interesting idea. For a civilisation is constructing a Dyson swarm, the time required to build a 20% coverage one to 30% one should be less than a decade. If I remember correctly, NASA is already be able to observe 1% of the difference. So we only need to wait for a year.

</comment></comment><comment><USER9> Is there any reason to expect such narrowband signals, or are they the only kind of signals they could hope to detect?

</comment><comment><USER10> Correction: "No signal that we use Detected from KIC 8462852"

And ? Nobody with good physical understanding uses Hertz EM waves for communication except emergency broadcasts if he is clever. Assumptions over assumptions and not looking outside the box, this is what SETI does and that's why they are not seeing anything of interest.

</comment><comment><USER8> It would make no sense if a Type 2 Civilization this close to earth did nothing to us.

<comment><USER11> 1480 light years away...it's just too far for practical travel on any sort of scale, and I assume scale would be required to "do something" to us beyond taking a glance - and even that seems far-fetched.

<comment><USER8> Assuming a Type 2 civilization has 10x population of the earth, each individual of it would consumes more energy than all of human beings combined. It's reasonable to suggest that light-year to it would be less challenging than AU to us.

</comment></comment></comment><comment><USER12> Is there any hope of discovering historical observations of this star ?

</comment><comment><USER13> >1480 light years away

One point consistently glossed over is the fact that if you believe nothing can exceed the speed of light then even if we find intelligent life we will never communicate in any meaningful sense of the word. It would be more like mutual observation. Are there any sci-fi works that acknowledge this depressing reality and somehow manage to make a workable story?

<comment><USER14> _A Deepness in the Sky_ deals with interstellar traders that do not have FTL.

The universe the book is set in has a gimmick to allow FTL, but that book doesn't use FTL (part of the gimmick is that it isn't possible in much of the galaxy).

Edit: The Revelation Space books also have lots of people moving between stars at below light speed.

<comment><USER15> The author is also a computer scientist so many of his books are well detailed for those versed in related fields (the way biologists write sci-fi books that scatter biology details other readers not versed in the subject would miss) like people here.

A Deepness in the Sky, for example, touches on open source, technical debt, project management, memory density, branching, DRM, encryption, stenography, and other more nuanced topics; but it's a sci-fi novel first. All in the backdrop of a universe with no FTL (at least for this book in the "series", more like books in the same universe).

He also does great alien races (the other book in the series, A Fire upon the Deep, has alien races which behave on different computational architectures to achieve sentience; and touches on obfuscated code (among other topics) in a great way).</comment></comment></comment>


Ask HN: How do I delete a submission? - <AUTHOR>

Text says it all, I submitted a link that I want to go away. <comment><USER2> You click the delete link under the submission. If it is not there you are too late.</comment>