Secure Secure Shell - <AUTHOR> https://stribika.github.io/2015/01/04/secure-secure-shell.html <comment><USER3> It's possible that NSA can recover keys from 1024-bit RSA/DH/DSA handshakes, but it's extraordinarily unlikely that they can do so scalably; that would be an ability that currently qualifies as space-alien technology.

RC4 is terribly broken and should be disabled. But the practical attack on RC4 requires many repetitions of the same plaintext --- "many" in the millions. This is a real threat to HTTPS/TLS, but not as much to RC4. Even hypothetical improvements to Fluhrer/McGrew would still require lots of repetitions. Disable RC4, but if you're playing along at home, this probably isn't it.

No serious cryptographer seems to believe that the NIST curves are backdoored. Avoid them if you can; they suck for other reasons.

MD5 is survivable in the HMAC construction.

<comment><USER4> It is conceivable, with the right tradeoffs, that computing individual discrete logs over a few popular 1024-bit moduli could be made cheap. However, none of the available evidence suggests this practice.

There is a lot of inconsistent thinking behind the advice given in the article:

\- Hard-to-implement NIST curves suck, whereas GCM and Poly1305 are recommended.

\- NIST apparently sucks, but NSA-designed SHA-2 is recommended.

\- MACs need 256-bit tags, so UMAC and not-NSA-designed RIPEMD160 is apparently not fine, but GCM/Poly1305's 128-bit tags are recommended. On this note, 256-bit tags are pointless when the rest of the crypto infrastructure is sitting on 128-bit security.

\- 3DES is not recommended because DES is 'broken', not realizing that this break is due to small key length of the original DES; 3DES is deemed to be quite secure (but _slow_ ).

\- 64-bit block size is enforced, but for no good reason: SSH's 32-bit sequence number, along with counter mode, renders block size worries moot.

<comment><USER5> I think the reason why many still think SHA2 is safe is mainly because of Bitcoin. There's a lot of money at stake and many crypto experts working with Bitcoin. If there was a hole, it's possible someone would've found it. AES was also designed by NSA and is considered safe.

That said, I think it's better to avoid them anyway just to give another hit to NIST/NSA. Plus, ChaCha20 and BLAKE2 have much better performance in software than AES and SHA2/SHA3 anyway, so I would like to see those adopted as _default_ options instead.

<comment><USER4> > AES was also designed by NSA

No, it was designed by Joan Daemen and Vincent Rijmen, two Belgian academics.

</comment></comment></comment></comment><comment><USER6> Looking at which key exchange protocols, HMACs etc. various other SSH implementations out there support, it seems that many of them would be barred from accessing a server hardened like that :/. In fact, it almost seems like the intersection of mutually supported protocols is empty resp. only contains known-to-be-unsafe ones... :(.

Which makes me wonder: Is there anywhere a comprehensive comparison with tables that show which SSH clients (and servers) support which algorithms for key exchange, HMAC, etc.? That would help determining whom one is going to shut out by disabling which protocol, and thus help in making an informed decision on that.

Of course, to be really useful, such a table would also need to take into account which version of each listed software added support for which protocol -- as it is, the OpenSSH shipped in e.g. Mac OS X 10.8 (5.9p1) does not support email@example.com which the OP recommends...

Sources: [http://www.libssh2.org/](http://www.libssh2.org/) [http://api.libssh.org/stable/](http://api.libssh.org/stable/) [https://support.ssh.com/manuals/server- admin/44/Ciphers_and_...](https://support.ssh.com/manuals/server- admin/44/Ciphers_and_MACs.html) [http://www.lysator.liu.se/~nisse/lsh/lsh.html](http://www.lysator.liu.se/~nisse/lsh/lsh.html)

<comment><USER7> This is a good idea. I'm thinking about adding functionality to the next version of Userify that will provide customization of ciphersuites (etc) on the sshd_config side. It'd be even cooler if it used just this sort of table.

<comment><USER6> For fun, I started work on this. It's still rather crude, and the code is hackish, but anyway: Comparison page: [http://ssh- comparison.quendi.de/comparison.html](http://ssh- comparison.quendi.de/comparison.html)

Git repository: [https://github.com/fingolfin/ssh- comparison](https://github.com/fingolfin/ssh-comparison)

Improvements are highly welcome; not just adding more clients, but also on refactoring the code, improving the UI (I suck at HTML), adding features... The TODO already lists some ideas.

<comment><USER7> This is excellent, thanks BlackFinGolfin!

</comment></comment></comment></comment><comment><USER8> "Don't install what you don't need", but run Tor to connect to your servers via SSH. Huh?

Hardening SSH makes a lot of sense and this article provoked a lot of thought. But there's too much political rant and leaps of faith for my taste. I'd like to hear some hardening guidance with more fact, less vitriol.

<comment><USER9> I can't imagine running a tor client on a production server and question its safety on my desktop (When I use it, I run up a disposable VM that gets wiped). So run software that connects you to the most hostile network out there and hope to god everything is secure on the client side of things?

This is the problem with trying to fight the NSA or some other over-inflated bogeyman. If you focus on weird edge cases you lose sight of practical security. I'd be more worried about opening myself to tor than some theorized attack on ssh ciphers.

Unfortunately, it seems network security has become fairly political, and if you don't make jabs at the NSA, while of course ignoring other state actors, then you won't be put on HN and reddit, which always welcomes politicized information at the cost of accuracy. I hope this hysteria is temporary and cooler heads will prevail and the Alex Jones listening crowd will stop holding the microphone.

<comment><USER10> > I'd be more worried about opening myself to tor than some theorized attack > on ssh ciphers.

Most of the attacks launched on Tor aren't in the "remote takeover of the tor server via memory corruption" category, they have (in recent history) mostly been in the form of:

        * Attack firefox.exe in Tor Browser Bundle
        * Control a lot of nodes, do something networky to discover the user's actual IP/location

What is the threat you anticipate will result from "opening yourself to Tor"?

<comment><USER9> Yes, these are the attacks we know of, and the first one only because the FBI told us so. I suspect Tor is a lot more targeted and dangerous than people assume and using it casually to administer servers is asinine.

</comment></comment></comment></comment><comment><USER11> I'm a little surprised that SSH authentication methods can't be easily disabled using the sshd_config file. Almost all the other security algorithms can be easily tweaked. I thought this article had just made a mistake, but I read over the man page and it appears there is indeed no way to modify this using the config file.

This isn't a protocol weakness. Reading over the SSH RFCs, the server is allowed to specify which algorithms it supports, so this could easily be a OpenSSH configuration option.

<comment><USER12> I found this extremely concerning too. It should be possible to modify these options without resorting to hacks (that may break when OpenSSH is upgraded) _if_ these modifications are indeed necessary. From some of the comments here it's clear that this article is a mixture of good, bad, and silly advice - <USER2> those other authentication methods actually need disabling?

</comment></comment><comment><USER13> I'm a bit concerned at some of the leaps of logic made in this article.

We're told to discount 1024 bit exchanges because of "unknown attacks". If they're unknown, why are we determining that 2048 bits is safe? How do we know the attacks aren't specifically against some other aspect?

The guide talks about creating a newer stronger host key, but doesn't provide any information about preventing initial MITM there: ensuring you get the right host key on first connection is a major issue, and somebody trying to "make NSA analysts sad" ought to be explaining methods for ensuring that happens securely via host key CAs or similar tools.

Likewise, the suggestion for "Preventing key theft" is "ven with forward secrecy the secret keys must be kept secret. The NSA has a database of stolen keys - you do not want your key there.". No insight is provided on how to actually accomplish that.

This is certainly a way to turn off weaker ciphers and exchanges, but passing it off as a way to "make NSA analysts sad" is hyperbolic and runs the risk of people believing the hype.

<comment><USER3> We don't know exactly the design of a rig that would solve a 1024-bit discrete log or factoring problem, but we have a decent idea of what it would probably cost, and most VC firms could fund it.

Costs don't scale linearly. No math projection puts 2048 bit keys in reach. The thing that breaks 2048 bit RSA may well put RSA completely out of action, a reason to prefer alternatives to RSA over 4096-bit keys.

<comment><USER13> Granted, but if that's the concern, that's what the article ought to be explaining:

We are aware of the infrastructure to break 1024-bit discrete logs, and it's feasible; current projections put 2048 bit key safely out of reach for the time being, so we'll disable 1024 and leave 2048 enabled.

My concern there is with the talk of 'unknown attacks' and then providing suggestions based on that statement.

</comment></comment></comment><comment><USER14> "Unfortunately, you can't encrypt your server key and it must be always available, or else sshd won't start. The only thing protecting it is OS access controls."

You can encrypt the server key and only decrypt it into a loopback mount when you want to start sshd or accept a connection (I don't remember offhand if sshd reads it only once or at each connection), then unmount it. You get the same functionality as typing in your keystore password when you start apache or netscape or whatever web server (because you encrypt your https private keys too, right?). An untested poc:

      # making the image
      mkdir TMPFS
      mount -t tmpfs -o size=4m tmpfs TMPFS
      cd TMPFS
      dd if=/dev/zero of=servkeys.img bs=1m count=2
      mkfs.ext2 -F -m 0 -t ext2 servkeys.img
      mkdir MOUNT
      mount -t ext2 -o loop servkeys.img MOUNT
      cp /etc/ssh/sshd_config MOUNT/
      ssh-keygen -t rsa -b 4096 -f MOUNT/ssh_host_key
      umount MOUNT
      gpg -se servkeys.img
      mv servkeys.img.gpg ..
      cd ..
      umount TMPFS
      # running sshd
      mount -t tmpfs -o size=4m tmpfs TMPFS
      cd TMPFS
      gpg -d ../servkeys.img.gpg > servkeys.img
      mkdir MOUNT
      mount -t ext2 -o loop servkeys.img MOUNT
      sshd -f MOUNT/sshd_config -h MOUNT/ssh_host_key
      umount MOUNT
      cd ..
      umount TMPFS

<comment><USER15> After a reboot, how do you access the server in order to perform the mount and start sshd?

<comment><USER14> Out of band. A vSphere console, VPN, KVM, LOM, modem... As a super-cheap alternative, a bastion host vps can be the intermediary. After connecting to the bastion host, you can then connect over the cloud provider's private network to a stripped-down remote shell on the target, and enter the password to bring up the public remote shell. Keeps the real keys safe, adds a layer in front of the target, and is convenient enough to administer from a mobile device.

</comment></comment></comment><comment><USER16> The article states that host key authentication methods cannot be disabled. Instead of creating broken symlinks, you can actually specify this server-side in sshd_config (at least on CentOS 7):

      HostKey /etc/ssh/ssh_host_rsa_key

You can also force this on the client-side in ~/.ssh/config:

      HostKeyAlgorithms ssh-rsa

See man pages for defaults.

</comment><comment><USER17> FWIW, I have submitted a somewhat similar configuration as a pull request for ioerror's duraconf project at [https://github.com/ioerror/duraconf/pull/52](https://github.com/ioerror/duraconf/pull/52).

This project also hosts secure ciphersuite configurations for postfix, nginx, apache, GPG, etc.

</comment><comment><USER18> In the Symmetric ciphers section, it ends with "This leaves 5-9 and 15" but why are 2-4 bad (aes128-cbc, aes192-cbc, aes256-cbc)? It seems the argument is that GCM is better than CBC, and CTR is okay. My general impression is that CBC is preferred (for example, Rails uses AES-256-CBC by default in its MessageEncryptor class).

<comment><USER5> Apparently implementing CBC correctly is too complex to do right:

[https://www.imperialviolet.org/2013/10/07/chacha20.html](https://www.imperialviolet.org/2013/10/07/chacha20.html)

<comment><USER3> No, that's not what he's saying. He's saying that making the TLS CBC constructions secure is hard. They were designed in the 1990s. Making a CBC implementation secure today is much easier.

</comment></comment></comment><comment><USER19> Instead of storing keys on a pendrive, consider using smart cards or some other crypto devices for that purpose. There are some tradeoffs involved, so research before acting.

</comment><comment><USER20> Unfortunately it seems that the latest version of PuTTY (0.63) does not support any of the advised MAC's.

<comment><USER21> Unfortunately PuTTY still isn't served over https, even after all these years. If you're concerned about esoteric MITM attacks, this is worth remembering...

<comment><USER22> Considering that PuTTY has GPG signatures, there is no need for downloading it over HTTPS. Of course, this does leave the issue of how to obtain and confirm the right GPG key for verifying the download.

</comment></comment></comment><comment><USER23> Hey All, OSX user here, i'm having trouble trying to replicate the config on my machine. Thusfar i've found, If you using a mac, things are slightly different, ie, /etc/ssh/ssh_config Is actually /etc/ssh_config /etc/ssh/sshd_config Is actually /etc/sshd_config /etc/ssh/moduli Is actually /private/etc/moduli

That's as far as i can tell anyway. I'm not sure what to do when it comes to authentication however. I'm assuming that your supposed to be editing /etc/ssh_config/ however i don't know if i'm supposed to remote the '#' from any lines i'm editing? I also dont appear to have any files that i can find called ssh_host_rsa_key nor is there a 'HostKey' line in the ssh_config file.

Any help would be most appreciated!

<comment><USER24> ftr /etc on Mac and /private/etc are the same. It looks like the contents of /etc/ssh is in /etc on Mac OS X's SSH

</comment></comment><comment><USER25> For the MAC, the article suggests an exception to github.com. But it looks like an exception is required for the Kex protocol as well. I see this error:

       Unable to negotiate a key exchange method

If I understand correctly the response from ssh -v -v, github.com only supports the following Kex protocols:

email@example.com,email@example.com,ssh-rsa,ecdsa- email@example.com,ecdsa- email@example.com,ecdsa- email@example.com,email@example.com,ssh-dss- firstname.lastname@example.com,firstname.lastname@example.com,ecdsa-sha2-nistp256,ecdsa- sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss

Edit: By trial and error, I find that this works for github.com:

KexAlgorithms diffie-hellman-group1-sha1

<comment><USER26> Doesn't the article suggest a KexAlgorithms exception rather than a MACs exception? I get the same error, but adding the above KexAlgorithms doesn't help

<comment><USER25> The article seems to have been updated pretty heavily. We might have been looking at different versions.

Here's the complete change log: [https://github.com/stribika/stribika.github.io/commits/maste...](https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure- secure-shell.md)

</comment></comment></comment><comment><USER27> > Some of the supported algorithms are not so great and should be disabled > completely. If you leave them enabled but prefer secure algorithms, then a > man in the middle might downgrade you to bad ones.

How does that work? The algo exchange is authenticated too.

<comment><USER28> How can it be? What algorithm could you possibly use to authenticate the part where you negotiate which authentication algorithm to use?

<comment><USER27> Itself. :)

You could possibly force a weaker DH kex I think, but there's no way to force e.g., rc4 with hmac-md5. Disabling group1 is a pretty big interop hit, though.

</comment></comment></comment><comment><USER29> This seems like a great idea. Unfortunately most of the recommendations seem to not be supported on my MacOS machine. Also, when I paired it down to the ones that are supported I wasn't able to connect to github. :( Very annoying.

<comment><USER30> Agreed. And to add to it, even though Yosemite has OpenSSH 6.2p2, it has most of the newer features disabled.

FWIW, this is what I have in my config file on Mac.

      Ciphers aes256-ctr,aes128-ctr
      MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1

<comment><USER31> See [https://news.ycombinator.com/item?id=8849392](https://news.ycombinator.com/item?id=8849392) for how to safely upgrade Yosemite's OpenSSH to 6.6p1.

</comment></comment></comment><comment><USER32> "ssh-keygen -G /tmp/moduli -b 4096 ssh-keygen -T /etc/ssh/moduli -f /tmp/moduli

This will take a while so continue while it's running."

First line has taken 6 hours on an ec2 t1.micro.

<comment><USER31> The second line took a little over 3 hours on my 5 year old MacBook Pro.

</comment></comment><comment><USER33> One thing bothers me:

> Unfortunately, you can't encrypt your server key and it must be always > available, or else sshd won't start. The only thing protecting it is OS > access controls.

That should be solvable with systemd and fuse - create an encrypting filesystem with a fixed key obtained from an USB pendrive, which is then ejected (so it would need a reboot to be enumerated again), and have the filesystem limit open() calls to the key file. It should not need more than one read call when openssh starts.

<comment><USER34> That actually makes setting up SELinux seem like the simpler route.

<comment><USER33> iirc SELinux can only restrict the process groups that are able to read the file, which doesn't help you in a remote code execution exploit inside openssh.

The question is, is is possible to use the keys without having them in RAM any more?

<comment><USER35> > which doesn't help you in a remote code execution exploit inside openssh

To be fair, If it gets to the point where they are executing arbitrary code in the openssh process, your key is already compromised.

SELinux would help with most other causes of key leaks, however.

> The question is, is is possible to use the keys without having them in RAM > any more?

In my (albeit limited) experience, no. Even if only because context switching would push the key out of the CPU registers and into RAM if it occurred at the wrong time.

<comment><USER7> > To be fair, If it gets to the point where they are executing arbitrary code > in the openssh process, your key is already compromised.

This. Exactly.

</comment></comment></comment></comment></comment><comment><USER36> Would'nt NSA attempts at cracking encryption systems basically be free audits on those encryption systems. (providing the public some how figures out how it was broken.)

<comment><USER37> Assuming they bothered to share the results of those attempts sure. The problem of course is that the NSA is both attempting, and in some cases succeeding in cracking encryption systems but keeping it all locked away behind security clearances. In the past we've learned quite a bit about the weaknesses of various crypto systems via post-mortems of NSA exploits, but it always comes well after the fact that the encryption is weak and broken has already become if not common knowledge than at least largely assumed. E.G. it's probably a safe bet that 1024 bit encryption is either broken by the NSA currently, or is likely to be broken soon, but it will probably be many years (barring another Snowden like event) before the public knows anything about exactly HOW the NSA has/will break it.

<comment><USER38> An extreme example for this kind of approach might be found in the history of the Enigma cipher and the British/Allied successful attempts in decryping German communications during the war. If it would have been obvious that information about an impeding attack could only have been gathered from intercepted and decrypted communications, the British would rather let boats be sunken and people die than give away the fact that the code had been broken.

Because if the fact would be known, the adversary will immediately cease to use this method of encryption, rendering the advantage of breaking the cipher void.

<comment><USER39> As a small aside, for anyone interested in this, The Imitation game was in my opinion fantastic, though I assume anyone here would already have seen it, or have plans to.

</comment></comment></comment></comment><comment><USER40> Every now and again I step back and think of the absurdity of us having to take all of these precautions to stay safe from the people employed to represent our interests

</comment><comment><USER41> To say the least, the number of recommended options here which are not supported on the version of openssh which comes with OS X is disappointing.

<comment><USER31> [https://news.ycombinator.com/item?id=8849392](https://news.ycombinator.com/item?id=8849392)

</comment></comment><comment><AUTHOR> Based on the Snowden documents and the fact[?] that the NSA can decrypt SSH at least some of the time the author advocates disabling some of the weak points of SSH. He also describes how to go about doing so.

<comment><USER42> Are there any facts on the NSA being able to decrypt SSH? All I saw was some Spiegel article where it showed the NSA had compromised some targets. But zero details, so it _could_ have been as easy as a MITM and the user not verifying the public key. Or it could be an unknown exploit in the actual code.

Everything I've heard so far points to the crypto being OK. That, so far, no special NSA crypto-defeating capabilities have come out. (Hence the NSA doodle with the smiley face on the links where Google removed TLS.)

Of course the NSA might have magic powers, but nothing in the last few years suggests that possibility any more than we'd have thought before.

<comment><USER43> There was a powerpoint where they implied they could sometimes get around ssh protections. Most people assume it's not actually the protocol that's broken, but it seems like a good excuse to clean up ssh anyway.

</comment></comment></comment><comment><USER44> It's possible the NSA doesn't give a shit about your shit too.

<comment><USER45> From the slides leaked at 31c3 and by Der Spiegel that's not the case.

They want everything.

Even if you're not a target you're of interest -- either as a vector to a target.(someone you know, regardless how many "hops") some thing you have (information, or equipment/infrastructure as a proxy or platform for attack)

Think of this example: you've ssh access coincidentally to a VPS on the same metal that coincidentally runs another VPS that belongs to a guy, who as a favour runs a totally separate server that hosts a "bad dude"(tm). Everybody in that chain and everybody connected to every one involved with the hardware are direct targets, all of their work colleagues are for the same reason.

Now extend that up and down every technological stack and industry and you'll see how capricious the notion is.

And if you're not a US citizen, you've no rights so who gives a shit? If you happen to be a US citizen, you've still no rights because the people targetting you will just be members of another Five Eyes organisation.

<comment><USER44> Ok... First, if they're using my VPS to get to someone else's... um. Ok. So it really doesn't affect me. Sorry about your neighbor. He should cover his ass better and not keep top fkin secret info on a god damn VPS.

Oh, and even if this were like a possible scenario, why not just open random accounts until they strike gold? Or infiltrate the datacenter with a mind reading quad copter drone and plug a usb drive into your machine? I mean honestly, there's a 1000x easier ways to do this. The NSA isn't after your shit. Get over yourself and quit drinking the koolaid.

<comment><USER45> > Get over yourself and quit drinking the koolaid.

Given these are disclosures from their internal presentations, it's their koolaid that we're discussing.

</comment></comment></comment></comment><comment><USER46> > Use free software: As in speech. You want to use code that's actually > reviewed or that you can review yourself. There is no way to achieve that > without source code. Someone may have reviewed proprietary crap but who > knows.

Maybe this person forgot about Heartbleed? Or that Debian bug that was around for years? Or Shellshock, dating back to 1989?

Stop pretending and assuming that just because software is open source that it is automatically reviewed.

<comment><USER47> His claim is that it's necessary - not that it's sufficient.</comment></comment>


My Message To Google: Stop Cheating - <AUTHOR> http://techcrunch.com/2011/02/26/my-message-to-google-stop-cheating/

<comment><USER3> Google isn't necessarily cheating.

Perhaps, just perhaps, when people search Google for those things, they really do prefer the Google.com results that come up. It's a name they already know and trust, so clicking the link seems like a no-brainer. They don't need to cheat to get their own results to head to the top of the list.

</comment><comment><USER4> Let me get this straight, the World is accusing Google of cheating because its search engine provides a Google based client amongst the first choices instead of the client that might be more familiar to that factor.........

Tell the Harvard professors to walk into 2,000 McDonalds and order a happy meal and take a survey and complete case study on how many clerks suggest Burger King before they suggest a number 3 value meal.

Now, if Google wanted to be firm, and maybe this does exist, not sure, but when the only privileged results in a search should come from companies who pay for it, and if they do pay for it, Google should have a special surcharge from companies wishing to appear above Google services in that specific search.

Google doesn't cheat, it does what most businesses try and accomplish, a way to run your customers back into your cycle. - <USER2>

<comment><USER5> I don't disagree with the overall point, but the McDonalds analogy doesn't quite work.

By specifically going to McDonalds you are indeed showing them that you're shopping for a McDonalds Happy Meal, because that's all they've got to sell. But when you're searching for a given term on a site that indexes the entire internet, you're just looking for whatever's most relevant, regardless of where it's hosted.

If you'd wanted the search to only apply to YouTube, well, that's what direct youtube.com and the "site:" keyword are for.

<comment><USER4> Yeah, the Mcdeez analogy doesn't really work, but you know what I mean anyway....</comment></comment></comment>


Ask HN: Can Jasmine Unit Tests Expose Security Vulnerabilities on Server? - <AUTHOR>

Scenario: I'd like to set up Jasmine-standalone-2.0.0 front-end unit testing on the development server where I work. I'm a full stack dev but mostly front-end. I'll admit I'm not super security savvy. A system admin is concerned that there will be security implications from 1. the Jasmine framework library being housed within the directory structure of a site build and 2. that having Some-SpecRunner.html files accessible by a browser could have security implications.Is anyone aware of security issues/vulnerabilities associated with the Jasmine Unit Testing Framework on dev servers or production servers? And if so any suggestions on how to best set Jasmine up to allay these concerns? Thanks HN! <comment><USER2> If I understand correctly what your question is, it shouldn't be a problem. Since your JavaScript - which you are testing - is publicly accessible, the tests shouldn't do any harm. They cannot do anythin, what the users couldn't do anyways.

What can be a problem: if you produce sample data during running the tests, you are going to produce a lot of trash data in your production environment. But you shouldn't do it anyway - just mock AJAX calls and so on.

<comment><AUTHOR> Thanks for responding - that's my understanding too. Though if there's something I'm not aware of, I'd love to know!

Thanks for raising the trash data issue. The framework does a pretty good job of set up and tear down before and after each test is run, so I'm not too concerned about the trash data as it's destroyed once the test has completed. (If I'm understanding your point correctly?)

<comment><USER2> I mean something like you call a REST API where you create fake data which is then visible on the production site. To avoid this, you should mock AJAX calls.

<comment><AUTHOR> Got it - thanks!

</comment></comment></comment></comment><comment><USER3> I'm not quite understanding the problem.

Normally, I run unit tests on my dev box; presumably your sysadmins don't care about that. I also run them on a special-purpose CI server. None of these machines are accessible to the outside world. I would never put the the unit test code in a place where it could be triggered by regular users or the general public.

Is that how you're setting it up? If so, what is the sysadmin worried about?

<comment><AUTHOR> Thanks for responding! Currently running Jasmine on local dev box, yes that's cool, sysadmin not concerned about that.

We don't have CI server. We have a dev server that is currently exposed to the world, our production server is separate. If Jasmine installed on the dev server a SpecRunner.html that triggers the unit tests on that dev server could be accessed by anyone if they knew the url.

This is what the sysadmin is concerned about. Would you say it's best to either 1. just run the unit tests locally as we don't have CI server set up or 2. Hide our dev server from the outside world and then it would be ok to run the unit tests on it?

Hope that helps to clarify?

<comment><USER4> Your dev server shouldn't be accessible to the public. If you want a server to be accessible to the public that isn't your production server (which is valid), you should be doing things as similar to production as possible (not running tests on it).

<comment><AUTHOR> Thanks barylen for the response! Totally get what you're saying, could you expand a bit on why?

<comment><USER3> I agree with barylen. Dev should never be visible. For the general reason that the default is "hidden". You make specific exceptions for the small number of things you want people to see.

There are a lot of reasons for that, but for me the two big reasons are good user experience and good security. You get a good user experience by carefully controlling what people see and making sure that's polished. You don't want to have to think about them stumbling across things that aren't for them. And good security requires minimal attack surface. You don't give naughty people anything to abuse that you don't have to.

<comment><AUTHOR> That all stands to reason, thanks for the input wpietri.

</comment></comment></comment></comment></comment></comment><comment><USER5> You shouldn't be unit testing on production. You should run as little as possible in prod.

<comment><AUTHOR> Thanks for responding staunch! Is that mainly to avoid performance costs/clutter, or for security reasons or both?

<comment><USER5> You're increasing risk for little benefit. A Javascript unit testing framework could _likely_ be used for crafting XSS exploits. Or it could end up slowing down real users when you forget to turn it off (or whatever). Probably nothing bad will happen but it's a needless risk and a bad practice.

<comment><AUTHOR> Ok, got it - makes sense. Thanks for the input staunch, much appreciated.</comment></comment></comment></comment>


On Search and spoiled bloggers - <AUTHOR> http://helloform.com/blog/2011/02/on-search-and-spoiled-bloggers/

<comment><USER2> I for one appreciate all of the high profile blog posts about Google's recent search quality. Google basically did with search what Microsoft did with IE6. Once they had dominated the market, they figured "Well, that's that, let's make some other cool stuff", and have gone on to enter into all kinds of unrelated markets instead of improving search at all. If you look at improvements to Google's search from say 2004-2010 there is almost nothing new.

Finally once they got a little bit of competition from Bing, we are seeing some new things like instant search, and they are addressing search quality, adding new features etc...

</comment><comment><USER3> So the point of the blog posting is that instead of deeming the search quality to suck, one might, by having lower standards, not conclude that they suck. In fact much of the article is actually about how blogs shouldn't be filled with fluff, or with bullshit.

Yes.

<comment><AUTHOR> This is not about lowering standards, Sam. This is about expectations (and indeed, bullshit on blogs - hence the article title). The one problem search has right now are content farms - like the guys who were scrapping off sites like Stackoverflow, which certainly bit many of us here by bringing actually good results down -, but that isn't to say that "search sucks". There absolutely needs to be a solution to spam and gaming search results.

That being said, the article is indeed not more about search than it is about crap supposed-high-profile blogging. Mike doesn't highlight the problems with search, doesn't mention possible solutions. He talks about Google being in shaky ground because people are paying attention to bing and other competitors. I think that's crap.

<comment><USER3> The thing is, it is fair to say that search sucks. Many times it's impossible to find what you're looking for. Even the desperate tricks like including the word "forums" in the search don't always work any more. And the post does highlight the problem with search (which is that it sucks). As for possible solutions, that's a hard problem. You can't say that Arrington needs to mention possible solutions, is he going to suggest that they invent some kind of algorithm? It is fair to point out that specialized tools are more useful (and maybe that future search engines will need to be built around these).

<comment><AUTHOR> You can extend that argument to "x sucks", then, where x can be virtually anything we know - since it is valid to say something sucks without mentioning why, or how it could be better (because he doesn't need to publish an algorithm indeed, but what good is saying something is bad if you don't even know how it could improve?)

<comment><USER3> Absolutely.

Which is fine. For example, in this case, I hadn't thought about the quality of Google's search results and how they are doing. This has brought the matter to my attention and now I have a different perspective on the future of search engines.

</comment></comment></comment></comment></comment><comment><USER4> The contention isn't that search quality sucks - it is that search quality has declined visibly over the past few months. Personally, I find most of the articles maligning Google to be little more than linkbait trying to capitalise on a meme, but let's at least discuss the real issue rather than simply saying "Search is amazing. Now shut up."

</comment><comment><USER5> "Time passed, and they resented the defects no longer. The defects had not been remedied, but the human tissues in that latter day had become so subservient, that they readily adapted themselves to every caprice of the Machine. The sigh at the crises of the Brisbane symphony no longer irritated Vashti; she accepted it as part of the melody. The jarring noise, whether in the head or in the wall, was no longer resented by her friend. And so with the mouldy artificial fruit, so with the bath water that began to stink, so with the defective rhymes that the poetry machine had taken to emit. all were bitterly complained of at first, and then acquiesced in and forgotten. Things went from bad to worse unchallenged." - The Machine Stops.</comment>


Interview with Alan Kay and Danny Hillis - <AUTHOR> http://www.wired.com/wired/archive/2.01/kay.hillis_pr.html

<comment><USER2> Great conversation!

I like the pervasive biological metaphor that they use. Intercellular enzymes might operate with the precision of programs, but they float in a forgiving, scalable goo. I want that goo in my software.

The most advanced programs we have now are about the equivalent of unicellular organisms. It will be some time before we figure out how to make systems with "life" and resilience.

Kay also mentions funding, which seems to be a cherished topic on this forum: "[ARPA]'s like the goose that laid the golden eggs. When you start forcing the process, it kills it. ARPA succeeded because they basically funded people instead of projects. They didn't really care what the people were doing. They figured neat people would do neat things... And, boy, it's really hard to find any funding like that nowadays. "

</comment><comment><USER3> _DH: You don't learn much by taking apart a dynabook, except not to do it. It had never hit me before, but the current generation of kids don't even get to hack the operating system._

Perhaps not in 1993, but now we have full open source environments to play in. The code may not always be very comprehensible, but at least it's possible to see what's going on under the hood.

</comment><comment><USER4> From 1994 by the looks of it; I don't think that's apparent on the (print- friendly) link, but it's all the more interesting with that in perspective!

Related topic: who would you consider the Kay, Hillis, etc of today? (apart from Kay, Hillis, etc) Or can we only tell that sort of foresight in hindsight?

<comment><USER5> _Related topic: who would you consider the Kay, Hillis, etc of today?_

I don't know that I would place Hillis on the same level as Kay, given the conditions of today.

Right now, Apple is making a killing by selling machines whose user interface is a descendant of Kay's work, whose programming environment is a descendant of Kay's work, and whose form factor is a descendant of Kay's dynabook concept. Kay, in effect, blueprinted today yesterday.

Hillis, on the other hand, made his impact in parallel computing. Whereas Kay's work dealt with today (yesterday), the stuff Hillis did yesterday deals with tomorrow. In the next decade or two, we might watch Hillis' work come to fruition as Kay's already has.

<comment><USER6> good insight!</comment></comment></comment>


The electric pickup wars are about to begin - <AUTHOR> https://edition.cnn.com/2020/02/14/cars/electric-pickup-truck-wars/index.html <comment><USER2> I'm looking forward to the electric van wars, which should hopefully be right on the hells of the electric pickup wars.</comment>


PatchAttack: A black-box texture-based attack with reinforcement learning - <AUTHOR> https://arxiv.org/abs/2004.05682 <comment><USER2> Help me out. I am naive about neural networks. I have skimmed the paper, read the abstract and he conclusion and looked at the examples.

Does this not illustrate what is the fatal flaw in image recognition based approaches with neural networks, that their failure modes are inscrutable?

80% or 95% of the time they do well but the corner cases where they do poorly they fail in ways that are entirely unlike the was our brains' systems fail. Unpredictably. So they can be useful for non critical applications but not critical applications. Like self driving cars....

Stages of grief here... I was looking forward to my car with a cocktail cabinet that would drive me to parties and home again... I believed the hype five years ago. Is this why progress has stalled?

<comment><USER3> Not a full answer, but specifically for image recognition, there's been some exciting work by Chris Olah and others to visualize exactly what's going on in neural networks. Some of this work has been really fascinating, identifying what specific neurons or sub-networks seem to focus on.

One overview can be found here: [https://distill.pub/2018/building- blocks/](https://distill.pub/2018/building-blocks/)

So I think others in the space have the same frustrations about the lack of insight into these models, and we're working on ways to get better answers out of these black boxes.

</comment></comment><comment><USER4> Shower thought: vinyl car wrap with a bunch of pictures of stop lights at various angles

<comment><USER5> "Reckless endangerment: A person commits the crime of reckless endangerment if the person recklessly engages in conduct which creates substantial jeopardy of severe corporeal trauma to another person."

[https://en.m.wikipedia.org/wiki/Endangerment](https://en.m.wikipedia.org/wiki/Endangerment)

</comment></comment><comment><USER6> Some sort of rule on top can simply negate this by requiring x amount of area with respect to the image

</comment><comment><USER7> Original title was "PatchAttack: A Black-box Texture-based Attack with Reinforcement Learning" which seems better. The phrase "99% with black-box RL" is particularly inscrutable.

<comment><USER8> Changed now. Thanks. Submitted title was "PatchAttack: Image classifier adversarial attack, 99% with black-box RL".

Submitters: please use the original title and then, if you like, add a comment to the thread explaining what you think is important about the article. You'll have more room for your explanation that way, people won't complain, and you won't be breaking the site guidelines: [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER9> Is there a policy for shortening long original titles? Some research papers can be a bit wordy in their titles.</comment></comment></comment>


Ubuntu May Become Rolling Release With 14.04 - <AUTHOR> http://www.thepowerbase.com/2013/01/ubuntu-may-become-rolling-release-with-14-04/

<comment><USER2> It would be great to actually get bug fix updates to packages rather than only the security. I know that technically they are supposed to be shipping them, but they rarely do.

Also, they would have to double-down on QA which is unlikely.

<comment><USER3> We've been doubling down on QA since the last LTS, there's some info on that here: <http://qa.ubuntu.com/>

<comment><USER2> Good to hear.

</comment></comment></comment><comment><USER4> I quite like the sound of this, but I only really install LTS, and then only on servers, so as long as LTS stick around I'm not too bothered what they do between each release ;-)

Also, BSD releases work that way don't they?

</comment><comment><USER5> I hope that they keep the _Long Term Support_ versions, for which they used to provide updates for up to 5 years.

<comment><AUTHOR> In the video, they revealed that the plan is to move from LTS to LTS, with each LTS rolling until the next. I think it sounds cool.

<comment><USER6> Kind of like debian stable and debian testing relationship.

</comment></comment></comment><comment><USER7> I think that's a good idea. Most of the interim releases are usually filled with bugs and more unstable anyway.</comment>


Why Mozilla's layoffs and Google deal made me rethink my browser of choice - <AUTHOR> https://www.techrepublic.com/article/why-mozillas-layoffs-and-google-news-made-me-rethink-my-browser-of-choice/ <comment><USER2> [https://news.ycombinator.com/item?id=24220702](https://news.ycombinator.com/item?id=24220702)

</comment><comment><AUTHOR> Genuinely curious what other HNers think. I've been a Firefox user for 10+ years and am not happy about the Chromium market-share, Google's stance on adblockers (e.g. uBlock Origin), etc. but it does feel like a losing battle.

<comment><USER3> As another longtime Firefox user (since Thunderbird actually being a product days), I'd say Mozilla-the-company has been shooting themselves in the foot in the same way as Wikimedia or OpenOffice.

By abstracting away market pressure and substituting an unaccountable org structure, they've successfully eliminated any incentive to respond to actual user desires.

Consequently, the project has been rudderless from a strategic perspective for years now.

<comment><USER4> Honestly it is Thunderbird which I am most concerned about losing in all of this. Google & Gmail have done untold damage to what we know as email.

<comment><USER5> Thunderbird was carved off, going so far as to have the supporting infra separated from Mozilla. Should be safe.</comment></comment></comment></comment>


PowerShell Remoting - <AUTHOR> https://www.sconstantinou.com/powershell-remoting/ <comment><USER2> Remoting is SSH, but with much much MUCH more bulk (because it transfers full objects over the wire and uses SOAP as its wire protocol; see here: [https://docs.microsoft.com/en- us/powershell/module/microsoft...](https://docs.microsoft.com/en- us/powershell/module/microsoft.powershell.core/about/about_ws- management_cmdlets?view=powershell-5.1)

Now that Windows 10 and above support native SSH with a somewhat-real pseudo terminal, we can probably just use SSH instead in the next year or two without having to pay Bitvise a ton of cash

<comment><USER3> The bulk because of soap is sort of irrelevant unless you are in a really slow connection where the size of every packet counts.

I have more serious griefs against powershell remoting.

For instance it is set up as a delayed start service which means you often have to wait more than a minute after a VM rebooted before you can log into it.

Windows Update is accessible by remoting through a COM API that doesn't allow remote connections, so you can't do the equivalent of a simple apt-get update remotely. There are horrible hacks around it, like setting up a scheduled task to trigger or collect the update and run that task from remoting and collecting the result some random way like reading a text file.

It really feels half baked, barely usable, and an ugly reminder that CLI has been added to windows as an after thought.

[edit] also I believe it is unencrypted by default. You have to enable https, which isn't straightforward. And you can't change the default ports.

<comment><USER4> > Windows Update is accessible by remoting through a COM API that doesn't > allow remote connections, so you can't do the equivalent of a simple apt-get > update remotely.

This isn't even remotely related to PowerShell (no pun intended), it's a security based decision of the windows update API. You can say that it is annoying, stupid and cause of hacks that are much less secure than opening remote operations to the API, and I will agree with you. But it isn't PowerShell business.

As as side note If you are using SCCM you can use WMI for windows update.

PowerShell is far from being half baked, it is a first class citizen in Windows, all the OS GUI tools today executes operations through PowerShell. Many let you see the commands so you can bypass the gui next time and run the commands yourself. As a matter of fact, many things these days can only be done by the shell, while the GUI only expose limited set of the available API.

<comment><USER3> I am not sure what you are trying the achieve by setting the cursor between the update API and powershell. Both are managed by the same group within the same company. The fact is Microsoft delivered an ssh-like scripting capability that cannot do simple things like updating the OS. You can call powershell a wonder, I beg to differ.

<comment><USER4> > Both are managed by the same group

I highly doubt that this is this the case.

>The fact is Microsoft delivered an ssh-like scripting capability that cannot do simple things like updating the OS

If you measure PowerShell by its ability to perform OS updates then you are correct, it is a failure. But the fact is that this annoyance isn't caused by the shell being half baked but rather it is an API decision of a different, unrelated product. The shell provides great usability in all other aspects - that is, the whole OS and other Microsoft and 3rd party software.

</comment></comment></comment></comment></comment><comment><USER5> I love powershell, but I will say the troubleshooting the remoting aspect of it suuuuucks.

There were plenty of people cheering when they say they could ssh from powershell to a win box running powershell, just because of how annoying it is.

<comment><USER6> Trying to open a remote PowerShell session into a Windows VM running in Azure is agony. This seems like the most basic, fundamental operation you could imagine for an IaaS platform, particularly when you wrote all the components involved, and it's nearly impossible.

<comment><USER7> I haven't tried doing this with Azure, but if it involves setting up PowerShell Remoting for local accounts and non-domain computers, then I can see why it would be a hassle.

</comment></comment></comment><comment><USER8> The article is about powershell to powershell remoting. I like powershell itself fairly well, but I just feel so much more comfortable in bash/zsh and more importantly the environment around them.

I'm interested to see whether Windows SSH servers become more viable after ConPTY[0] is widely available.

[0]: [https://blogs.msdn.microsoft.com/commandline/2018/08/02/wind...](https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows- command-line-introducing-the-windows-pseudo-console-conpty/)

<comment><USER9> One benefit you get with powershell to powershell remoting is that the output of the commands come back as objects rather than text. You can even use "implicit remoting" (not sure if that's the marketing term) to make the remoting part of it transparent to your automation - see Import-PSSession.

<comment><USER8> That's a pretty cool feature, but I don't often remote into machines and then want to do the processing locally. Maybe that's because I don't have this feature, but I've never felt like I wanted to. Usually I just treat the client like a dumb terminal.

I'd bet a project like Ansible could use something like that to great effect though.

<comment><USER10> From what I understand, PowerShell has been open-sourced and ported to Linux. Are non-Windows users adopting it? It's probably facing a long climb. Having 30+ years of productivity hacks is tough to compete with.

<comment><USER11> I use PowerShell on Windows because CMD is atrocious and some things just aren't great in Windows for Python. C# is also not efficient for those people used to the efficiency that comes with a Linux terminal and how to use it.

When I'm on Linux, I have tons of commands, bash, python, perl, Awk, sed...etc etc. All of those tools work perfectly with text which the Unix style OS embraces. Windows on the other hand is all objects and this can be painful in PowerShell at times.

Tldr; PowerShell is alright on Windows as it is the only real viable option for a power user. However, Linux is far better with what it already has and PowerShell would be a step backwards in functionality and efficiency.

<comment><USER12> WSL (Windows Subsystem for Linux) is doing a pretty great job of making those *nix commands easily available on Windows. I don't know if it's ready for say DevOps day-to-day professional usage, but just being able to find, grep, awk on Windows works great for me.

<comment><USER11> Sadly I'm still on Windows7. I'll start the fight with IT over access (I assume configuring it requires admin) as soon as I'm on Windows10.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> _" The listener that is created when you enable PowerShell Remoting is over HTTP. You are able also to configure WinRM over HTTPS"_

Doesn't seem like a good idea to default to plaintext.

<comment><USER14> It's typical Microsoft engineering, and I say that as a frequent defender of powershell here.

It's encrypted, except when it isn't, except on Tuesdays when it is.

[https://www.reddit.com/r/PowerShell/comments/97oxox/comment/...](https://www.reddit.com/r/PowerShell/comments/97oxox/comment/e4blfgj)

" _Just an FYI not all psremoting traffic is encrypted when using http. Message encryption is done using the authenticated context which varies based on what auth was actually used.

For example Basic auth has no authenticated context in SSPI so has no encryption.

NTLM (fallback if kerb is not available) is next to useless as it is based on RC4 which is considered broken today.

Kerberos should be using AES if configured correctly but older environment may have older insecure algorithms set up if the config is mismanaged on the domain level.

CredSSP uses the TLS context that is set up in the auth so is similar to using HTTPS.

When using https you not only get a more consistent and secure encryption mechanism on all auth methods. You also get encryption on the whole TCP packet that is sent to the client, whereas http message only encryption encrypts the message body._"

And

" _My understanding of the issue is that WinRM can do more than just Powershell Remoting (for example there are also Python libraries that run on Linux machines to interface with WinRM which I 'm assuming do something different to PS remoting since PS is not native/required on those platforms). So if you are doing ONLY Powershell Remoting you're probably fine with HTTP, but if you're doing anything else then it could be exposed via HTTP WinRM. So HTTPS is still recommended.

tl;dr - All Powershell Remoting is WinRM, not all WinRM traffic is PS Remoting._"

[https://www.reddit.com/r/sysadmin/comments/5vph9l/winrm_encr...](https://www.reddit.com/r/sysadmin/comments/5vph9l/winrm_encryption_question_xpost_from_rpowershell/)

And

 _I think lots of people couldn 't get a straight answer on this and it came up on the recent MCP Insider AMA.

First 3 minutes of video 2 "it's secure, use it [...] tell 'em Jeffrey Snover told you, go do it".

"_Also, for more information on security when remoting read the powershell.org free e-book, Secrets of PowerShell Remoting.*"

[https://www.reddit.com/r/PowerShell/comments/34yzgt/comment/...](https://www.reddit.com/r/PowerShell/comments/34yzgt/comment/cqzj4l2)

<comment><USER15> I totally agree here. Every time Microsoft roll out a new product or feature, it seems they go out of their way to make it as complex as possible.

A lot of their server side products have weird restrictions or integrate with their other products in strange ways. Nothing is standardised, or simple.

For example, I'm in the middle of a project that needs to log audit data from a front-end service. The service isn't that busy, so doesn't really log that much, however the reporting interface _only_ works with System Center. So to build out the reporting infrastructure I need: 2x System Center Service Manager Management Servers, and 2x System Center Service Manager Data Warehouse Servers, and 2x SQL Servers in a live-sync arrangement. That's six servers, three in each Datacenter. Four of which need 16Gb of RAM. The Management Servers do hardly any work, but due to an artificial restriction placed in the installer, you cannot install them on the same boxes as the Data Warehouse component. Even if you could, MS wouldn't support it.

All this to log no more than 100-200 events a day. To do the reporting any other way, is unsupported. It's nuts. I am starting to believe that Microsoft are now deliberately making their products so complex and so expensive to build on premises, in order to push customers into their Cloud platforms instead. This is certainly true of Exchange Server which is now an absolute nightmare to manage on premises. It's a mail server, why is it so complex?!

To be honest, it wouldn't surprise me if even internal Microsoft product designers and engineers no longer understand how most of the Microsoft server products even work or integrate.

And I say all this as someone who's spent 25 years working with Microsoft products as my day job.

</comment></comment></comment><comment><USER16> Along the same lines: [https://github.com/geophile/osh](https://github.com/geophile/osh)

Osh (Object shell) is a command-line utility for running sequences of operations connected by a pipe-like construct. Objects are piped, not strings. Included in the sequence of operations may be remote sequences of command, which run on all nodes of a cluster. For example, if you have configured a cluster named foo, then you can get the pid and commandline of every node of your cluster like this:

        osh @foo [ ps ^ f 'p: (p.pid, p.commandline)' ] $

\- osh: Invokes the interpreter

\- @foo [ ... ]: Run the bracketed commands on every node of cluster foo.

\- ps: The osh ps command, which yields a stream of Process objects.

\- ^: The osh pipe symbol

\- f: Function application. The function in this case takes a Process p, and returns a tuple containing the process's pid and command line.

\- $: Print the contents of the input stream, one per line.

This is a python tool, so the stuff piped between operations are python objects.

<comment><USER17> I casually follow the development of the Elvish shell, which uses structured data, and is written in Go:

[https://elv.sh/](https://elv.sh/)

The latest release has a package manager for plugins, so hopefully we'll see more support for remote stuff through that route.

PowerShell has some great ideas, but it seems doomed to mostly be a quirk of Windows at this point. I'd really love to see a more modern shell than bash get adoption across the industry.

<comment><USER16> Hadn't heard about Elvish, thanks for the reference.

I've thought about a new version of osh, making it less of a command-line utility, and more of a shell. What do you think would be the main properties of a "more modern shell"? Do you think it is OK if this shell drags in a Python interpreter?

</comment></comment></comment><comment><USER18> Pywinrm is your friend if you are a nix person.

<comment><USER8> That's a good tip, I'll check that out. Still hoping for SSH server support though...

<comment><USER19> I've installed and run OpenSSH via Cygwin on Windows systems going back to Windows Server 2003 at least. I think Cygwin provides a better UX than WSL, and its deployment is easily automated.

</comment></comment></comment><comment><USER20> I worked at a client that manually pulled data from 70+ remote servers every morning to combine into a financial report.

I enabled ps-remoting, wrote a bunch of scripts, and turned this process into an automated batch job that took 3 minutes.

One of those odd jobs that was a lot of fun.

</comment><comment><USER7> I can appreciate the clear explanation of Powershell Remoting in this guide. It was a big part of one of my previous jobs. It is a pathway to basic dev-ops things in a Windows environment.

</comment><comment><USER21> Given that my company pushes things out using GPO, I'm trying to figure out if we are missing something by not leveraging PS Remoting.

Does anyone have any use cases where PS Remoting would be more useful?

<comment><USER22> Ansible supports powershell remoting. In a past role I used it to install SQL Server and other software packages on Windows servers. I've also used it to install VMware vCenter and all its dependencies, pGina etc.

A bit clunky to set up but it works. I'd rather use SSH than WinRM though, which should be possible in the future now that MS has added SSH support to Windows.

</comment></comment><comment><USER23> font-weight: 300;

Why do they insist on making the text hard to read?</comment>


The Principled Documentation Manifesto - <AUTHOR> http://hackingdistributed.com/2013/02/11/principled-documentation/ <comment><USER2> I wrote this, to turn my frustrations about the state of NoSQL documentation into something positive. I didn't think it'd get HN'ed so quickly. I look forward to suggestions for new gospel.

<comment><USER3> I find the "commandments" format to irk me slightly. I realise it lends a ready-made structure to any document, but "thou shalt" is sufficiently fusty that it can rub people the wrong way.

I've found the pattern format to work well in practice, because a well-written pattern pretty much explains itself. In particular, framing the discussion with a problem helps to illuminate when and where a pattern ought to be applied.

In terms of your general thesis in #2-5 that formal specification has failed and that a structured form of informal specification (wrap your head around that one, fellow pedants) ... I'm not sure.

I mean some of what you've argued for seems to me to be a "language design smell" -- just as some of the original Go4 patterns were seen in retrospect to be. So for example when you argue for taking a contractual approach. Why shouldn't that be in the language? It's not as though you have to go all the way to writing Z specs or Coq proofs. Personally I'd be perfectly happy to step up to Eiffel contracts.

Guarantees embedded in source code also have the nice property that they are slighly less likely to turn out to be filthy horrid lies; just as is generally thought of sourcecode comments.

I agreed with point 7, about stating the end state of the method rather than its process. I feel the same way about tests; I find test doubles to be thoroughly unsettling because I wind up explaining the logic of my program twice, instead of separating mechanism and validation. Perhaps such "naked mechanism" is just another indicator of code that will require high coupling.

Where you went wrong was that you, like I, assume that things with "database" on the label have silly-old fashioned notions like a fanatical focus on data safety.

I also agreed strongly with 8 and 9. Sometimes I look at the front page of HN and it is totally unintelligible gibberish. Having to know the intricate injokey history of two dozen sequential puns to run a piece of software drives me up the flaming wall. It's one of the things I least like about the ruby ecosystem.

<comment><USER4> > "thou shalt" is sufficiently fusty that it can rub people the wrong way

Particularly when used inconsistently, e.g.: Thou shalt specify _your_ assumptions

</comment></comment></comment><comment><USER5> Treating docs like specifications may seem onerous because of the specs that come to mind: entire languages, or the CSS/HTML specs. Massive documents, way too much work.

But I fell in love with the CL HyperSpec years ago. Pick any section, (<http://www.lispworks.com/documentation/HyperSpec/Front/>) ... and it's amazingly clear, with sample code and everything.

And, yeah, it's a big spec. But CL is a big language, and not just any language, but a batteries-mostly-included language, fully specified.

In contrast, the programmer-facing API for most libraries is going to be fairly small. HyperSpec-quality docs probably wouldn't be that hard for most small-to-midsized projects.

</comment><comment><USER6> If you're wondering how to write thorough doc for an engineering audience, I highly recommend looking at IBM's doc for z/OS. The first thing you'll notice is: there's a lot of it.</comment>


Ask HN: Is there really bloat in Rails and if so where is it? - <AUTHOR>

I see people referring more and more to the "bloat" of Rails and interested to know what they're referring to.
I use Rails on a daily basis and I don't notice anything overblown or imbalanced about the framework. I would say that I use most of the features and I'd miss them if they weren't there. If anything I find that some things such as routing are perhaps too pithy and not flexible enough.
I'm no framework polyglot though so I'm interested in the comparisons that might be drawn? Are there genuinely parts of Rails which are unnecessary?
Is it that the framework has truly become overblown or is it just that it's not suitable for certain jobs? <comment><USER2> There's a number of parts of Rails core that could probably be spawned off to other gems. For example, the form building tools: there are several better ones out there - I know I always use Formtastic over what Rails provides.

Another one would be the built-in testing DSL. RSpec and Minitest do that pretty well now, why is it a part of Rails?

Then again, I hate these type of conversations: my bloat is someone else's timesaving feature. "Why does Rails have an ORM, they're too abstract!" some might complain... but engineers on a Rails app bigger than a few man-months may love the time the ORM saves. (Especially when the client changes their mind on how a business domain feature should work, for the third time in as many iterations).

</comment><comment><USER3> The trend is moving toward putting the view logic into the clients as championed by the many Javascript MVC frameworks such as Backbone.js, Ember.js etc. When you use these to build your web interface, what is needed on the server is just JSON API. From this point of usage, Rails is "bloated" as you do not generate views on the server and push down to the clients.

There is also another aspect of the web that might caused that view. That is the rising usage of websocket type of real time app, which Rails is not able to handle directly yet. This makes full-stack framework like Rails looks less agile thus bloated when you compare to Node.js for example.

</comment><comment><USER4> "Bloat" = "Bigger than the framework _I_ know"</comment>


Show HN: Curated Docker on ARM Images and Tutorials - <AUTHOR> https://github.com/alexellis/docker-arm/blob/master/README.md <comment><USER2> This seems like a useful collection of resources. Because there isn't really anything for people to try out or play with, it doesn't seem to embody the spirit of "Show HN".</comment>