Programming language subreddits and their choice of words - <AUTHOR> https://github.com/Dobiasd/programming-language-subreddits-and-their-choice-of-words <comment><USER2> An interesting indicator from the "mentions" graph: how compatible or co-used two technologies are in practice.

For example: C++ programmers apparently don't mention SQL at all, while it's very popular with PHP (which doesn't have a built-in ORM). There is also no overlap between C++ and JavaScript programmers.

Rust is obviously very influenced by C++ and Haskell, but the C++ community doesn't even know about its existence. Somewhat naturally, the Matlab and PHP communities really don't have much in common.

<comment><USER3> None of these languages have a built in ORM.

<comment><USER4> Does any language have a built in ORM? I was thinking maybe Ruby, but even that is a gem.

<comment><USER5> Would Entity Framework qualify as a "built-in" ORM for .net languages?

 _edit_ I guess not, since it's a nuget package now. Maybe LINQ to SQL could have been considered a built-in ORM?

<comment><USER6> > Maybe LINQ to SQL could have been considered a built-in ORM?

It might be more accurate to say LINQ is built into the languages, but LINQ to SQL is a .NET platform feature, not a language feature. (Of course, the languages are so tied to the Microsoft distribution and the .NET platform that distinctions between language features, language standard library features, and platform features are, for .NET languages, somewhat academic in practice [inasmuch as there is a practical difference that is likely to matter, "does it work on Mono" is probably more important than strict language/library/platform distinctions].)

</comment></comment></comment></comment></comment><comment><USER7> "But what is up with the Visual Basic community? They are neither angry nor happy. They just ... are? :)"

This is answered by the mentions relative to TIOBE graph. They use VB, but they are careful not to talk about it.

<comment><USER8> Not sure if "careful" is the right word. I've gone through many, many languages over the last 20 years, and VB has become my first choice (when the choice is up to me). Most other VB devs I know (there aren't many) just seem... uninterested in arguing over it vs. C#, or anything else for that matter. It's part of the appeal to me - shipping, and the journey are worthy of discussion. Language is incidental.

</comment></comment><comment><USER9> I wonder why Perl was excluded. A quick search reveals that /r/perl has more subscribers than lua, matlab, objectivec, scala, sql, and visualbasic.

<comment><USER10> I suspect the answer to "Why was ___ excluded" in most of these cases is "accidental oversight".

<comment><USER11> >>"accidental oversight"

Which is just another word for "conspiracy."

<comment><USER11> Proof that HN has no sense of humor. :)

</comment></comment></comment></comment><comment><USER12> I know PHP-bashing isn't particularly creative nor nice, but I wasn't surprised when I saw the word-analysis at the end there :)

That said, I don't think the findings for C was shocking either.

You're not going to be writing kernel-modules in Clojure. It's going to be some sort of C. And the chances of it involving hardware (performant code or not) is significantly higher than other non-systems languages.

<comment><USER13> Why are no one using JSP, by the way? Isn't it a better, more secure direct competitor to PHP?

<comment><USER14> The thing PHP and JSP were designed to do seems to be generally seen as a bad idea nowadays. PHP is used anyway only because it's already installed everywhere, so those who would be able to set up JSP can also choose something else (i.e. neither PHP nor JSP) and probably do.

<comment><USER13> What would you use instead? Javascript fetching data from server and doing all UI stuff on client?

<comment><USER15> You use a _structured_ framework that has some separation of concerns (typically Model-View-Controller or some variant). In Java-world, some examples are Struts, Spring MVC, and Play, all of which can be used to write high-quality software for real-world applications. JSP might even be involved in the view/presentation layer.

There are also MVC frameworks for PHP. The most popular, though, are those for scripting languages like Ruby and Python, namely Rails and Django.

What you _shouldn 't_ be doing is interleaving data access, business logic, and presentation all in one file, which is what straight PHP and JSP usually consist of. This is called "spaghetti code" and it's been widely regarded as a really terrible practice for around 10 years.

You can do client-side apps in Javascript that fetch JSON or XML from the server, but you want to be using a framework with some structure to serve the data, still not just straight PHP or JSP.

<comment><USER6> > What you shouldn't be doing is interleaving data access, business logic, and > presentation all in one file, which is what straight PHP and JSP usually > consist of. This is called "spaghetti code" and it's been widely regarded as > a really terrible practice for around 10 years.

"spaghetti code" actually has a much broader definition than that particular kind of lack of structure (though I agree that that example might be viewed as a fairly modern example of "spaghetti code") and has been considered a terrible practice for _much_ longer than PHP, JSP, or even the web itself has existed. [1]

[1] [http://en.wikipedia.org/wiki/Spaghetti_code](http://en.wikipedia.org/wiki/Spaghetti_code)

</comment></comment></comment></comment></comment></comment><comment><USER16> This is awesome. It almost paints a picture from PHP => Python => cpp & Java.

Considering that would be considered a growth path of a developing programmer, I find that fascinating.

PS: Go will always have problems with stuff like this. They should have just named the language string or var or something equal toxic to machine collection.

<comment><USER17> I'm not defending the name choice; but to be fair, nearly all of the major languages have put zero consideration into their name SEO: Java competes with coffee, Ruby with the gemstone, Python with the snake, C# with the musical note, and C ... C is just a damned letter :P

<comment><USER16> Maybe this just means engineers shouldn't name things! :)

Then again marketing people would have made choices like RadPython, RubyGrunge, and CFlowerPower...

<comment><USER18> Well there are four hard problems in computer science:

1\. Naming things 2\. Cache coherence 3\. Off-by-one errors.

<comment><USER17> Yep, I gave up on naming things. I tried to use really creative names as is common in the Linux world (Ristretto, Amarok, Brasero, Thunar, etc), but it drove me up the wall (I once named a project "xkas", ugh.) It's so hard to find a name that's easy to pronounce, sounds good on the tongue, and is not already used a million times.

Nobody's ever going to find them through Google, but oh well. Nobody was going to use them anyway. May as well name them the way I like, right? ;)

</comment></comment></comment></comment></comment><comment><USER19> It's great to look at correlations between Rust, C++, and Haskell. Rust programmers are very interested in Haskell, and Haskell programmers Rust; which indicates that Rust's design has a lot of influence from Haskell. C++ programmers are talking about Rust more than anything else; which shows that they are likely interested in moving to Rust.

This is very exciting to me, because I believe Rust is going to be a great replacement for C/C++, and if anyone understands how to create quality programming languages, Haskell programmers do.

TL;DR Rust is going to be the new C++, and the new Lisp. These are exciting times.

</comment><comment><USER20> I feel like Haskell gets name dropped a lot more - when you mention something from a C-language you can have a reasonable expectation the other person knows what that thing is.

<comment><USER10> I tend to agree -- I feel like the C-family concepts are the default, and when you go outside of that range, you specify.

e.g.

"I think function application is super easy, you just do f(x,y,z)!"

vs.

"I think Haskell style function application is super easy, you just do f x y z!"

But I also suspect Haskell is just getting more attention these days -- it's quite trendy for sure.

</comment></comment><comment><USER21> I agree with the author that the top graph may not be hiding any important insights, but the interactive version (linked from the image) is sexy as all get-out.

</comment><comment><USER22> I wish the colors indicated not absolute comparative volume (more X talk happens on Y forum, than visa versa, so it's colored Y) but instead comparative relative volumes

        Forum X spends a great percentage of their time
        talking about Y than visa versa so it's colored X

Basically, who obsesses over who more.

</comment><comment><USER23> That's really clever. I had a good laugh at some of the results. Well done.

</comment><comment><USER24> There's a language that everybody is talking about; yet nobody uses it.

Kind of a spinoff of Stroustrup's, "there are languages everybody complains about, and languages nobody uses".

</comment><comment><USER13> This is really cool. I wonder how the "buzzfactor" of Haskell would measure up against Idris.

</comment><comment><USER25> looks like users of PHP are most offensive when given to choice of words to hate the language and users of mathematica are least offensive ! Funny but not unexpected

clojure users seem very happy with what they use!

On the mutual mentions java users have near zero mention of haskell?

<comment><USER26> I started using Clojure about a month ago, after spending a lot of time with Python and I have to say it does make me oddly happy. Once you have paredit set up, the way you can move code around is just mesmerizing.

</comment></comment><comment><USER27> My kingdom for a sarcasm detection algorithm!

</comment><comment><USER28> nice job. as a user of PHP. no comments. :)</comment>


What's the matter with PGP? - <AUTHOR> http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html <comment><USER2> At one point in this essay, Matt suggests that every successful end-to-end encryption scheme has employed transparent (or "translucent") key management. What he's referring to is the idea behind, say, OTR: two people can use it without the key handshake required by PGP.

Matt is wrong about this. He's being victimized by a pernicious fallacy.

It certainly appears that the most "successful" cryptosystems have transparent keying. But that's belied by the fact that, with a very few exceptions (that probably prove the rule), cryptosystems aren't directly attacked by most adversaries... except the global adversary.

In the absence of routine attacks targeting cryptography, it's easy to believe that systems that don't annoy their users with identity management are superior to those that do. They do indeed have an advantage in deployability! But they have no security advantage. We'll probably find out someday soon, as more disclosures hit the press, that they were a serious liability.

There is a lot wrong with PGP! It is reasonable to want it to die. But PGP is the only trustworthy mainstream cryptosystem we have; I mean, literally, I think it might be the only one.

<comment><USER3> PGP is only trustworthy if both parties treat key management with the utmost severity, and if everyone in the conversation maintains the integrity of a given thread (in the email case).

There are a precious few individuals for whom I have that level of trust in their management of their private key. I could not even trust my wife to manage a hardware key that I gave her, it would fall apart immediately; "I cannot use this key on my chrome book? I cannot use this key on my Galaxy? I cannot use this key on my iPad? Give me a soft key that I can use, or a cloud service..."

Therefore, PGP is not mainstream. There is a large population of people doing it incorrectly, and they must because they have no other real choice.

<comment><USER2> Both of these statements can't possibly be true:

* PGP is only trustworthy if both parties treat key management with the utmost severity.

* Transparent key management systems that rely entirely on heuristics and click-through warnings are trustworthy.

<comment><USER4> Really they can both be true. They're just true for different constituencies. The vast majority of users are not targeted by active attacks, nor should they have reason to be. They may be hacked or subpoenaed after the fact.

<comment><USER5> I thought that "active" attacks is exactly what we were trying to guard against?

</comment></comment></comment></comment></comment><comment><USER6> Learning to drive a car is hard. You have to watch the road, coordinate hands and feet, anticipate other drivers' moves and so on. No one bats an eye about this, because "it's a skill you have to learn". If you don't play by the rules of the road, you'll end up killing someone, or getting killed.

But for some reason (maybe because it's generally less life-threatening), people seem to expect deeply complex subjects, like e-mail encryption and identity management, to be easy. "Yeah, if you can just give me a fancy, easy- to-use GUI with forward secrecy, that'd be great!" Sure, it'd be great. But it's not going to happen. And that's not because PGP is broken -- of course, it does have its weak points. It's because people are too lazy to bother to learn.

What's the old addage? You can have quick, cheap and reliable. Pick two? Same here. You can have secure, easy to use, and reliable. Pick two.

<comment><USER7> I can't drive. Not for lack of trying.

I seemingly can't develop the the muscle memory of unintuitive (to me) concepts like "clockwise is right" and "counter-clockwise is left", nor can I get used to the way a gas pedal actuates non-linearly. These are just two examples of a long list of problems that I have with the controls.

Then there is the utterly confusing signage.

I just can't do any of it, not without sweating like a pig. And I definitely can't be doing all of it at the same time. That's just nuts.

Every time I pick up a PS3 controller I have to learn to use it again, which depending on my withdrawal period can take anywhere from a couple of minutes to like half an hour. The only reason I can touch-type is because I'm doing it every day.

Please don't make the assumption that other's experience of the man-made world around us is in any way similar to yours, that's just not true.

Oh, and I have had absolutely no problem figuring out PGP encryption usage.

<comment><USER8> In what way are you contradicting Tharkun? I can't figure it out.

"Please don't make the assumption that other's experience of the man-made world around us is in any way similar to yours, that's just not true." Where did s/he? I'm genuinely stumped.

Learning to drive a car IS inherently hard (as in complex), just as "e-mail encryption and identity management", and that is a fact. If you for some reason are more or less adept than the average person at either of these things, I don't see what difference that makes to the reality of the situation. Like driverdan said, if you simply can't do something, you'll have to find a workaround.

<comment><USER7> What I said was to augment what he said.

But here's a true, I swear, you can probably check that it is, story just for you:

I didn't know how the whole army thing works when my time came. Just wasn't ever interested. Didn't know my sergeant from my brigadier.

The army took me seeing that I'm fit, for certain values of fit. Put me through boot-camp. That's when I landed in military jail for the first time. I could take everything that was going on in there only with a dose of humour, but grinning 24/7 was apparently not acceptable behaviour. But that wasn't what got me in jail.

There was one thing I could not take, absolutely. Still can't. There wasn't a moment to myself, I couldn't ever get alone in there. I had to always be accounted for, from their point of view; but from mine I couldn't find a place or the time to take a short meditation. I don't know what I have, but I've been getting through it all my life with meditation, and once that wasn't available I was heavily depressed. I thought of suicide, I talked of suicide, and that's basically all I ever talked or thought about. While grinning at anything they had to say to me in return.

So I went home. Took my stuff and went out the gate.

Later came back and went to military jail for a sentence. Then for boot-camp number two, as I didn't finish one.

But later when I did finish it on my second attempt, they didn't want me anywhere near a base anymore. They wanted me out of base for most of the time. They way to achieve this in the army is to make you a driver. This way you're driving around, not being in the base, problem solved.

If you read my previous comment, you know what the problem with that approach is. They didn't. So I explained, repeatedly. Any time they'd let me see an officer that was in charge of that kind of thing, I'd explain that I can't drive, won't ever be able to, and not even torture can "change my mind".

Either they have decided to test that last bit empirically, or just couldn't wrap their heads around the idea of someone not being able to do something that "any idiot could"; but long story short I've done 7 months of prison time in three separate terms over the span of 1.5 years before they saw me as unfit for service and let me go, and be as I am.

That is to say, you're not always in a position to find a workaround, if I may refer to your closing sentence.

</comment></comment></comment></comment><comment><USER9> I don't agree. I use GPGtools on OSX with the openpgp smartcard and it works flawlessly and is truly convenient. Furthermore I can use 4096 bit RSA keys.

One thing I have learned watching the crypto forums over the years is that there are well calculated misinformation campaigns trying to dissuade people from using secure methods. I see it again and again and the people on this forum need to think carefully before swallowing this as sincere.

I would never never never trust a solution from Google or any large American corporation. They have just been caught lying about prism (Google) and taking bribes (RSA). These companies are now and always will be totally untrustworthy.

<comment><USER10> You talk bad about RSA and use RSA keys at the same time?

<comment><USER11> [http://en.wikipedia.org/wiki/RSA_(cryptosystem)](http://en.wikipedia.org/wiki/RSA_\(cryptosystem\))

[http://en.wikipedia.org/wiki/RSA_Security](http://en.wikipedia.org/wiki/RSA_Security)

</comment></comment></comment><comment><USER12> Why isn't RFC 1751

[http://www.ietf.org/rfc/rfc1751.txt](http://www.ietf.org/rfc/rfc1751.txt)

used to provide the fingerprints that are readable? Verifying would be much more convenient than now.

"For example, the 128-bit key of:

             CCAC 2AED 5910 56BE 4F90 FD44 1C53 4766

would become

             RASH BUSH MILK LOOK BAD BRIM AVID GAFF BAIT ROT POD LOVE

Likewise, a user should be able to type in

             TROD MUTE TAIL WARM CHAR KONG HAAG CITY BORE O TEAL AWL

as a key, and the machine should make the translation to:

             EFF8 1F9B FBC6 5350 920C DD74 16DE 8009"

<comment><USER13> I haven't used the "original" PGP program for a very long time, but IIRC it had the option to use RFC 1751 or a similar scheme. A quick web search finds to options to use this scheme in GnuPG. Strange!

<comment><USER14> You're probably thinking of: [https://en.wikipedia.org/wiki/PGP_word_list](https://en.wikipedia.org/wiki/PGP_word_list)

[edit: See also this thread: [http://lists.gnupg.org/pipermail/gnupg- devel/2001-March/0170...](http://lists.gnupg.org/pipermail/gnupg- devel/2001-March/017007.html)

I think they're missing (what I think was) the point of the list -- I seem to recall this was meant for use over the phone, and the words were selected by machine learning to all sound different. I've always thought this was a massive case of over-engineering -- and also somewhat narrow-sighted. I mean the list starts out with "Aardvark" of all things! ]

<comment><USER13> Yes, that's the list I was thinking of. The linked discussion was interesting. Good find! Perhaps the GnuPG devs are right that hex finger prints are more internationally viable than English words.

<comment><USER14> I've been thinking a lot about using words to stand in for numbers (eg: fingerprints) -- and I think the idea is good. But i18n should be considered -- and the PGP world list is probably the worst example I know of. The only thing it has going for it, is that is already collected/created -- but seeing as how it's not implemented by gpg -- that is kind of moot.

<comment><USER13> I can see why it would be hard to find one set of words that are easy to pronounce/understand in every language and every culture. But perhaps that isn't necessary? I'm thinking that this feature needn't be available in every localized version of GnuPG. Or that there could be localized word lists for various languages.

<comment><USER14> Maybe. I think sticking to something like the phonetic alphabet or "simple English" would be ok.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> In my opinion, mail crypto needs to become mainstream usable. E.g. even trivial contents should be encrypted by default and this should be usable by default. Currently, S/MIME does a better job than PGP.

While the CA-model seems to be broken in most X.509 use cases, like TLS/SSL, where a duplicate certifcate can be used to do a man-in-the-middle-attack, this does not really affect S/MIME, especially after both parties started a "conversion". People that need to communicate "really" secure, should therefore be able to ignore all "CA-Trust" and white-list certificates on a per user basis (e.g. like PGP).

Ordinary communication still can by default fall-back to the existing CA-model to keep it usable (but not secure).

Some steps:

1\. We need more love by the MUA-vendors, who mostly support S/MIME but it's still a PITA to use. Google e.g. still does not support S/MIME on android, see [https://code.google.com/p/android/issues/detail?id=34374](https://code.google.com/p/android/issues/detail?id=34374)

2\. We need CAs that are usable. StartSSL is nice and free, but it's not easy to use. Lower the entry barrier for getting and renewing/recreation of certificates

3\. (most important) Make it easy to manage local CA-trust. On each new system, the user should be able to select a "trust no CA/whitelist only" approach and then be responsible for trusting other parties. No vendor (Microsoft, Apple, Google, Mozilla) should silently distribute and trust new CAs without users consent.

<comment><USER16> The "global CA" model is bust. How it was ever considered usable is beyond me, but we now have more than a decade of experience seeing just how bad it is. It is utterly, fundamentally broken and easily subverted by state actors.

For now, the only reasonably usable secure key exchange method seems to be what WhisperSystems are doing on their phone app (safe against MITM if the parties know each other, and very hard to MITM even if not - especially not automatically).

<comment><USER17> What's wrong with blockchain based solutions like namecoin?

<comment><USER16> If I understand correctly, namecoin is a distributed DNS replacement. Is there a way it addresses impersonation (e.g. MITM?), if so, can you please point me at documentation?

DNS does not address it, and even DNSSEC does not (if you can forge the certificate, and you can mitm the traffic - which state actors are all capable of - then it doesn't matter that you can't forge the DNS response itself).

<comment><USER17> You can place your own self-signed public key in your namecoin record. There is no longer any need for certificate authorities which can be coerced into forging certificates.

<comment><USER16> Well, if this is properly supported by software using namecoin for DNS resolution, then - yes, this may work. The proof of the pudding, however, will arrive once it's eaten. I am not familiar with namecoin to point where the potential problems are, but do note that the failure of CAs is not in the cryptography but rather in the trust model. In modern cryptography, the problems are almost always with the practice, not with the theory.

<comment><USER18> > software using namecoin for DNS resolution

Actually, it should be the other way around: dnschain [0] bridges DNS resolution and namecoin, so there's no need to modify existing software.

[0] [https://github.com/okTurtles/dnschain](https://github.com/okTurtles/dnschain)

<comment><USER16> Cool! wasn't aware of it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> > If the NSA is your adversary just forget about PGP.

Why? Last I heard, breaking PGP was equivalent to being able to factor large integers into a product of prime numbers. So, NSA is able to do that, and no one else can, no one in the public heard about it, no university research mathematician published about it, NSA has mathematicians who figured out how to do that but their major profs back in grad school don't know how, no one got a Fields Medal for it, etc.? I don't believe that.

What's going on here?

He means I need a Faraday cage? Okay, tell the NSA I have one; put it in place this afternoon.

He means the NSA has trained cockroaches that can wiggle into my hard drives while I sleep and steal all my data? If so, then fine. I'll spray bug killer.

Otherwise, why should I believe that the NSA could crack my PGP encrypted e-mail?

<comment><USER20> If the NSA can't attack the crypto (not saying they can, but maybe) they'll attack endpoint. Systems like QUANTUMINSERT allow them to selectively MitM your plaintext HTTP connections, directing your browser to load some asset that exploits a browser vulnerability, and using that to install persistent malware.

</comment></comment><comment><USER21> Yes, usability is the problem. But none of these proposed solutions manage to actually solve the usability problem without throwing out the security.

We really _do_ need to let users manage trust, because trust is a rich concept. And humans are actually really good at trust, because we've been thriving and competing with each other in complex social situations for a long time.

The trick is finding ways to recruit people's evolved trust behaviors into an electronic context. That is, can we build meaningful webs of trust through repeated social interactions, just like in real life?

So it's not the mail client vendors who are best positioned to solve the problem, it's the social networks.

(Whether they _want_ to solve the problem is a separate question.)

</comment><comment><USER22> I'm using TextSecure on my Android phone as a Messaging replacement and it is great. However it appears to me that the service is not decentralised in any way. Is that assumption correct?

I like the email model such that anyone can install and run an email server. I'd actively push friends, family and colleagues to use a decentralised email replacement that was as easy to use and secure as TextSecure.

<comment><USER23> I don't trust TextSecure. It's _too_ transparent. It is entirely unclear what happens if it can't send an encrypted message. It's unclear where and how much I'll be billed (important to those of us outside the US). And sans user authentication, there's no real trust model there.

<comment><USER24> Feel free to not trust it, but it does indicate whether the message to be send will be encrypted or not: in the current version, a padlock will be locked or unlocked on the send button. If you receive an unencrypted message from another text secure user, it automatically detects the other party is using text secure and offers to initiate key exchange.

The billing criticism is fair and warranted; currently if your sending over SMS, the first message can only contain 60 chars due to protocol overhead, so you often end up with short messages costing multiple SMS.

There is a way to verify keys (manually!) but no indication that you have verified them.

</comment></comment></comment><comment><USER25> The user needs to control the encryption, not Google or Yahoo. Surely Google is not proposing a system that prevents them from reading your email and serving you ads? Until we have something that actually prevents Google and Yahoo from getting the plaintext, none of the other problems matter that much.

The NSA isn't my concern, Google etc. are. I don't want to bother going to the lengths necessary to secure myself from the NSA since that just isn't practical. But it would be nice if google and its employees didn't have access to the plaintext of my email. If I send an email to anyone using gmail and they decrypt it in a way that lets google see my text when they reply, all of my own security steps are worthless.

</comment><comment><USER26> Just a random thought - maybe there is a way to nail hard the point that "you cannot have security if you're lazy"? The society expects people to do driving licenses before getting behind the wheel. Why not expect people to put some amount of effort to be able to get mortgage or interact with court, etc.? Sure, many people will screw this up, but maybe this will be enough to secure majority.

</dream>

(confession: I myself am too lazy to use PGP)

<comment><USER27> Counter example: I'm not too lazy to use HTTPS.

Maybe if email encryption was more like HTTPS more people would use it? Just transparent and easy.

<comment><USER26> > _Maybe if email encryption was more like HTTPS more people would use it? > Just transparent and easy._

Sure, but the point of a lot of comments here seems to be that It Can't Be Done.

<comment><USER28> It certainly can be done.

It's just that lots of people think HTTPS security is not good enough. (And you can include me on that set.)

</comment></comment></comment></comment><comment><USER29> PGP is about identity and privacy. We are not going to get that from Email. Email isn't worth fixing. Its time to move on.

In the last few years we have seen IM and SMS merge into an almost seamless experience. Surely we could engineer a UI that also copes with larger bodies of text at the same time?

We need clients or servers that are multi-protocol. That way we can experiment with new ways of communicating.

</comment><comment><USER30> Good article. However if your adversary is a three or four letter agency then by all accounts it seems that PGP/GPG still does work. Snowden and Greenwald used it, apparently successfully after some tuition.

The article also doesn't mention Bitmessage, which addresses a lot of the concerns. Bitmessage isn't forward secret though.

</comment><comment><USER31> Here is a good criticism of PGP from 1999 that explains why it isn't usable by ordinary folks - [http://www.cs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Enc...](http://www.cs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Encrypt/OReilly.pdf)

</comment><comment><USER32> Here's a handy guide which addresses a couple of these problems:

[https://help.riseup.net/en/security/message- security/openpgp...](https://help.riseup.net/en/security/message- security/openpgp/best-practices)

</comment><comment><USER33> Not mainstream ≠ suck.

Also, about "terrible mail client implementations", — the problem is, to not be terrible for many is to be built-in to GMail (and work transparently there). The consequences of that are obvious I hope. So no, thanks.

</comment><comment><USER34> This could perhaps be made easier to use if you had a UI like this: You phone pops up a message saying: "Hey, I notice you seem to be in the same room with Bob! We can increase security of Bob's messages to you my exchanging a fingerprint. Do this now? (Yes/No/Woah, Bob isn't here!)

If you click yes, you then exchange fingerprints using eg QR codes, and the authenticity of messages from Bob are _retrospecively checked_

Problem is, it's not obvious this can be done without compromising privacy of location.

<comment><USER28> > Problem is, it's not obvious this can be done without compromising privacy > of location.

That's a problem for Free Software running on local machines!

</comment></comment><comment><USER35> > Adding forward secrecy to asynchronous offline email is a much bigger > challenge, but fundamentally it's at least possible to some degree.

Is it really fundamentally possible? The author asserts this without really backing it with anything. I can understand how OTR-like systems can work between a static pair of clients, but it is not entirely clear if it is possible at all to extend such scheme to work in scenarios where message delivery is async and I might be using a set of clients/devices for messaging.

<comment><USER36> Matt links to a paper on forward-secure public key encryption in the notes. While this shows it is possible in principle, the actual procedure is pretty awkward, and probably not usable in this current state.

</comment></comment><comment><USER37> PGP needs to onboard themselves with Elliptic Curve Crypto... significantly smaller makes them more distributable which solves a few of the problems mentioned.

<comment><USER2> Most systems should switch from simple multiplicative group crypto to elliptic curve, but it's hard to make an argument that doing that would resolve any of the problems Matt is referring to.

</comment></comment><comment><USER38> These are largely problems with email, not PGP - which btw is not just by email, in fact I almost never use it with email.

SMTP is not meant to be secure. You insist in communicating through an insecure channel-protocol and making it secure as an afterthought, and it's always going to be inconvenient or otherwise suck. I say PGP is pretty good at what it does, and it's nice in that it doesn't promise what it doesn't do.

</comment><comment><USER39> > Now let's ignore the fact that you've just leaked your key request to an > untrusted server via HTTP. This is a public Key, so secrecy it's not needed > here, also he is providing the Fingerprint on another location, so if there > was a MITM attack, it should happen on both twitter (HTTPS) and pgp.mit.edu

<comment><USER40> I think Matthew Green's point was more that requesting a public key leaks your intent to communicate with someone—the metadata, if you will—to an untrusted third-party.

Of course, e-mail headers, including From and To, must necessarily transit as cleartext, even when e-mail bodies are protected by PGP. The keyserver should perhaps be the least of Matthew's concern.

<comment><USER14> So... gpg + mixmaster remailers + Tor for http?

</comment></comment></comment><comment><USER41> Can forward secrecy even work for emails, where you don't have a bidirectional communication channel? (Maybe the answer is "You have to build that bidirectional communication channel", but that means such a system can't simply use mail, it has to use mail plus X).

<comment><USER14> If we assume Alice and Bob use the keyserver network, and each have their own "master" key-pair that is mutually trusted, they can rotate public sub-keys quite frequently (you just need to search for any new keys before sending an email -- this is of course another (not smtp) channel -- but who doesn't use keyservers?).

</comment></comment><comment><USER42> keybase.io and the mailvelope browser plugin both do fine work in making PGP simple to use.

It isn't about being NSA-proof, its about having the volume of "Enveloped"/PGP encrypted emails be so high that it isn't possible to directly target everyone.

</comment><comment><USER43> No perfect forward secrecy. If someone gets your PGP key, they get all of your messages (past / present / future) and you might not even know your key was compromised.

<comment><USER44> Of course you can use forward secrecy (PFS) and ephemeral keys with PGP/GPG/GnuPG. I've been doing that for ages. Any public / private key system is able to do that. Simply generate new key pairs and send the new signed public key when ever that's necessary. I've blogged about that several years ago, when someone claimed that it can't be done. You can freely select if you want to rotate keys on every message, daily or so.

<comment><USER43> So you're just going to keep 1000 private keys around to decrypt your old stuff?

</comment></comment></comment><comment><USER45> [http://www.theregister.co.uk/2014/08/14/pgp_viability/](http://www.theregister.co.uk/2014/08/14/pgp_viability/)

</comment><comment><USER46> I think [https://lavaboom.com/en/](https://lavaboom.com/en/) addresses most of the issues mentioned. Just because pushing for privacy (an abstract idea, difficult to measure the worth of - especially on the Internet) is hard doesn't mean we shouldn't do it. Encryption is one of the fews things we can rely on and we should be using it. PGP isn't a lost cause, we just need to make it easy use - this includes automating (to some degree) the key exchange. /I'm one of the founders of Lavaboom, happy to answer any questions/

</comment><comment><USER47> I just hope that however google and yahoo implement PGP into their mail offerings, they do it in a way that cannot be intercepted by governments/bad guys.

<comment><USER10> but they are not allowed to tell you if it can be intercepted...

<comment><USER47> exactly, which is why they'd need to build it in a way that cannot be backdoored.

However, if the government comes to Yahoo/Google, and says: give us a backdoor.. how can we be sure it doesn't happen?

</comment></comment></comment><comment><USER48> > _even modern elliptic curve implementations still produce surprisingly large > keys._

> _Modern EC public keys are tiny._

Well, which is it?

</comment><comment><USER49> I'm kind of sad the author didn't touch on key signing at all. The trust levels are basically meaningless. What does it mean to trust someone more than someone else? If doing a request to get someone's key exposes your social network, imagine what publicly signing someone's key does. Just some food for thought :)

<comment><USER50> trust levels used during signing represent quality of identity check. in simple terms: if you checked ID of the person that is "sig3", if guy just claims the name on internet than it's "sig1"

on the other hand, "owner trust" is a local concept which is not exported and used solely for trust-path verification

</comment></comment><comment><USER51> > Except maybe not: if you happen to do this with GnuPG 2.0.18 -- one version > off from the very latest GnuPG -- the client won't actually bother to check > the fingerprint of the received key.

Even in it's long form, it's relatively easy to generate different keys that have the same fingerprint.

<comment><USER52> I'm aware of simple brute-force attacks on short key IDs [0], which are just the last 32 bits of the fingerprint (e.g. 438CF0E2). With significant effort, one might be able to extend that to 64 bits.

I'd be much more surprised by a full fingerprint match. Wouldn't that imply a SHA-1 collision?

[0] [http://www.asheesh.org/note/debian/short-key-ids-are-bad- new...](http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html)

<comment><USER51> Yes I was referring to the 64bit long key ID. The full fingerprint is a SHA-1 and not vulnerable.

See [https://www.debian- administration.org/users/dkg/weblog/105](https://www.debian- administration.org/users/dkg/weblog/105)

</comment></comment></comment><comment><USER53> Yeah really, it's actually Pretty Good if you think about it.

</comment><comment><USER54> Problem:

PGP is complicated (VERY complicated, to the average user), resulting in next to zero adoption.

Suggestion:

Simplify the goals in a way that can be upgraded at at some later date.

I think we need a browser plugin (All browsers. Other non-browser tools too, ideally, but the browser is important) that lets you securely _SIGN_ posts locally in a style more or less like GPG's --clearsign option. Ideally, this should _literally be_ \--clearsign for compatibility, with the plugin hiding the "\---- BEGIN PGP SIGNED MESSAGE ----" headers/footers, though these details are less important.

The key should be automagically generated, and stored locally in a secure way. (Bonus points for leting you use the keyrings in ~/.gnupg/ as an advanced, optional feature). The UI goal is to simply let people post things and click a _sign this_ button next to a <textarea> or similar. Ideally, later on, this could become sign-by-default.

On the other side, the browser plugin should notice signed blocks of text and authenticate them. Pubkeys are saved locally (key pinning). What this provides is 1) verification that posts are actually by the same author, and 2) it proves that someone is the same author _cross-domain_ (or as different accounts/usernames).

No attempt is made to tie the key to some external identity (though this would be somewhat easy for to prove). The idea is to remove the authentication problem (keyservers/pki) entirely. This can be man-in-the-middled, but the MitM would have to be working 100% of the time or the change in key will be noticed.

No attempt is made regarding encryption (hiding the message). This should also greatly simplify the interface.

The goal here is to get people using proper (LOCAL STORE _ONLY_ ) public/private keys. The UI should be little more than a [sign this] button that handles everything, and a <sig ok!> icon on the reading side. It should be possible to get the average user to understand and use such a tool.

 _Later_ , when the idea of signing your posts has become more widespread and _many people have a valid public /private key pair already in use_, other features can be added back in. As those "2nd generation" tools have a large pool of keys to draw from, it should be easier to start some variant of Web Of Trust. Even if that never happens, getting signing widespread _is_ useful on its own.

I realize this doesn't protect against a large number of well-known attacks, and only offers mild protection against MitM. This is intentional, as the goal is getting people to actually _use_ some minimal subset of PGP/GPG-like tools, possibly as an educational exercise. The rest of the stuff can be addressed later.

<comment><USER55> I've designed an API for this and started working on it since I got a Yubikey Neo in the past few weeks, if you or anyone is interested. I'm focusing on UX specifically.

My design has a REST endpoint that runs locally, and a JS client/SDK then connects to it on a known endpoint. My "MVP" version is to have the user running an interface with the request queue in a separate tab, and the server always at a fixed localhost:port endpoint. The client page would then issue a REST request that hangs until the user responds to the request in the separate tab.

This would conceivably work as a browser plugin as well since I'm planning to write it in JS for Node--basically the server logic would instead live in the plugin and the SDK would check for presence of the plugin before making a REST call. IMO the advantage of making it a REST endpoint though, is protecting private keys from whatever else might be going on in the browser process(es)--based on my own worst-case on assumptions, unsure if it's actually an issue with the plugin architectures.

I'm an aspiring interaction/UX designer so that is the aspect I am focusing on, and my motivation is that I am personally starting to use GPG with a Yubikey + offline master. So yea, collaborators hit me up, especially if you're in SF.

</comment></comment><comment><USER56> This article fails my smell test. The adolescent vocabulary doesn't correlate with the otherwise polished writing style and the technical merits fall far short of the proposed remediations. It is therefore likely to have been funded or otherwise inspired by the NSA in an attempt to smear PGP, still the most effective cryptography available to the average person.</comment>


Dear Package Maintainers: Stop Being Clever - <AUTHOR> http://www.standalone-sysadmin.com/blog/2013/07/dear-package-maintainers-stop-being-clever/ <comment><USER2> I posted this as a comment on the blog, but I'm duplicating here:

RHEL and Debian (and their respective derivatives) have different philosophies on packaging, which is why you see this result.

The RHEL philosophy is simple; package installation only installs the package, starting daemons is a separate process.

The Debian philosophy is that installing a daemon should also make that daemon run, unless it's not possible the make the daemon run securely by default. Things like the /etc/default RUN="no" aren't the package maintainer trying to be clever, but rather them following Debian packaging guidelines. There also the reason you see things like MySQL listening only on the loopback interface by default on Debian.

One you understand this the decisions seem a bit less crazy.

For me, the big issue with the Debian approach isn't on installation, but rather on upgrade. On Debian, running 'apt-get upgrade' on a live server can cause an unspecified amount of downtime. If you're upgrading MySQL, MySQL will get restarted. If you're upgrading a library on which multiple daemons rely, they will also get restarted. yum upgrade on RHEL doesn't suffer from the same problem, and you can schedule the restart yourself.

Again, this is because of a philosophical difference. On Debian, the idea is that if you've asked to upgrade something, it should be upgraded. On RHEL, you can upgrade a package, but continue to run the old (potentially insecure version).

<comment><USER3> > If you're upgrading MySQL, MySQL will get restarted.

Or specifically, it will get stopped, your packages will spend 15 minutes updating (or longer if there's an interactive prompt mid way and you aren't paying attention), and then it will get started again.

I'm quite happy with the debian way of doing things, but I'd really like it if apt-get was smart enough to stop / upgrade / start individual services, rather than stop-all / upgrade-all / start-all...

<comment><USER4> 15 minutes? Mysql upgrade and restart takes up to 5 second in a usual case. Also services do get stopped / started one by one, not all at once.

<comment><USER5> It depends on the upgrade sequence; I've definitely seen the behavior of a service getting temporarily shut down during something like preinst upgrade, a bunch of packages being installed, and only at the end during configure them all being restarted.

<comment><USER4> Report a bug then, or check if this is really possible to restart the service after installation. In some cases that may be the only reasonable way to do it. For example services based on scripts/libraries which get dynamically reloaded on each request cannot be updated while they're running, because it would cause mismatch between the components. Killing them, updating all files and starting again is the only way to do it.

As you said - it's not a debian-specific thing. Some packages may do it if they explicitly require it (and I haven't seen one doing this in the official repos so far).

<comment><USER5> I did not and do not consider it a bug; it was just inconvenient; it was really really inconvenient once when I did an upgrade involving hundreds of packages.

</comment></comment></comment></comment></comment></comment><comment><USER6> What I don't understand is why every maintainer adds a (unneeded) layer for enable/disable.

If you want to run a service, you have a runlevel editor.

This is, chkconfig in RH based, and update-rc.d in debian based.

That is the tool for the job.

Nowadays it seems that everybody prefers to invent an additional switch, this is a shell boolean or string, in /etc/sysconfig (RH) or /etc/default (debian).

Why ?

</comment><comment><USER7> When packaging a daemon for Debian, the maintainer should add sufficient questions during installation, and sane default values, to start the service.

Contrary to the article, I think this is a rather good policy. It makes sure packages are usable as they are, rather than the normal process of config, make, make-install, and last adding user configuring before anything will start up. Debian is not Gentoo.

For those daemons which this isn't possible, package maintainers has a harder time. One of the better ways is simply to have it run, but in a safe way which do nothing. That would solve the issues the article describes, and would not be harmful.

<comment><USER8> What does packages using non-standard hacks that break puppet scripting have to do with configuring and building source code? That's not related to the issue at all...

<comment><USER7> The article talks about two issues. One is that debian has policy to default run daemons after installation. The second issue the article brought it up is the issues with puppet.

Regarding the first issue, sane defaults and usable packages directly after installation came as a result of the config, make, and make-install process. Users should get a useful package directly without needing to spend days adding all the default settings to start a simple mail or web daemon.

The second issue has nothing to do with config, make, and make-install. It has to do with non-standard hacks. If nagios3 had simply started up like apache, this would have been a non-issue.

</comment></comment></comment><comment><USER9> Every package maintainer needs to make some decisions when packaging software. Debian has very specific guidelines about packing, so if you don't like it may be Debian is the wrong distribution _for you_.

Recently a workmate installed nginx from the upstream repo and... surprise: nginx packages things different to Debian. You may like it more or less, but there are different solutions for the same problem.

<comment><USER10> Author of the article here. Thanks, and I agree with you. I have some disagreements with the way Ubuntu does things like this, and I'd prefer an RHEL clone (which, of course, has tradeoffs too).

That being said, I'm in the environment relatively recently and it's established, and I'm the one who has to learn to adapt since I don't see our infrastructure changing dramatically soon. Other than finally adding configuration management, that is.

</comment></comment><comment><USER11> I remember installing Red Hat 4, going on IRC and getting rooted. Red Hat's approach comes from lots of learning, and I think it's smart. Thanks for the post.

<comment><USER12> Could you elaborate as to how this happened?

<comment><USER13> Years ago, Linux distributions defaulted to installing everything and the kitchen sink and enabling all those services automatically.

After years of "OOTB pwnage", they started to make things a bit more secure by default and they eventually got to the point we're at today (where most installations are relatively secure by default, OOTB).

(Side note: I believe it was RHL 5.2 that shipped with wu-ftpd enabled out of the box. By the time it shipped (or shortly afterwards, I forget which), there was a remote root exploit for wu-ftpd. Thus, if you installed RHL 5.2, you'd likely get pwned in short order.)

<comment><USER11> This is exactly correct. I was a Slackware zealot for a long time but frequently tried Red Hat because my boss back then was a big fan. I didn't actually convert to appreciating Red Hat until I worked there and learned the advantages of using RPM and other tools included in Red Hat that were absent in Slackware. In either scenario, and this is still true today, if you plan to connect your system to the Internet, you need to know your configuration and care for the system after it is live.

Modern distros help with this a lot by offering rapid package updates, automatic updating and smarter firewall and security measures. A lot of this stuff was controlled by very esoteric text configuration files in the past, which made it hard even for a savvy person to get right every time.

</comment></comment></comment></comment><comment><USER14> Debian always think they know better than the authors of the software they're distributing (the worst, but by no means only incident being their key generation bug). When I maintained a linux program I received twice as many bugs from Debian users as anything else, because Debian repackaged KDE in a way that broke its autoconf macros. And anyone who's ever tried to follow a tutorial for e.g. Tomcat will know how radically Debian rearranges its files.

IMO it's not worth maintaining Debian packages of one's software or supporting it on Debian. Let Debian have their own packager for it if they want to, and direct support requests to them.

<comment><USER15> Perhaps you were seeing more bug reports from Debian users, because more people were using your software via Debian than elsewhere?

<comment><USER14> Right, but the excess was all people with the same problem. I added a note to the homepage ("debian users: you need to install libblah-devel, configure will not warn you about this because of how debian packages KDE") but it didn't seem to make any difference.

</comment></comment></comment><comment><USER16> We have a similar problem when deploying Openstack using puppet - all the services need to be brought up after config that sets things like the central DB and AMQP locations. It means that a deployed site will always have errors in their logs right from the start, which confuses customers and makes it harder to spot when there is actually an error in the deployment tool.

<comment><USER17> If you're using Ubuntu, the .deb packages need a lot of work. I've been playing around with this for the past week and there are all sorts of little glitches and gotchas. A big problem is that the package maintainers didn't use debconf, so you end up having to install, set some settings and then bring the service up.

This is definitely not the debian/ubuntu way of doing things.

If I find some time I'll see if I can repackage things to properly use debconf and push things upstream.

<comment><USER15> No, Ubuntu specifically made the choice to avoid debconf for Openstack packages.

If you are using debconf interactively, it simply doesn't scale - if you are preseeding - or using juju, puppet or chef - what value does debconf add?

Please don't assume that it is simply wrong, just because it doesn't do x or y.

The debconf templates will always be trying to play catchup, and the transition of options between components doesn't make a lot of sense.

It would be really good to know what issues you have identified, as we take quality very seriously in this area.

However, your help with packaging will be most appreciated. Feel free to give me a shout on IRC, and we'll go through it.

<comment><USER17> I'm not quite sure I'm parsing your sentence correctly. If you're preseeding with debconf the value is that you got to preseed the correct configuration options. This means the debs will work with anything, not just the flavour of the week devops tool. Juju, Puppet and Chef aren't the only games in town. I'll agree that they are all very useful tools, but you shouldn't need to write complex scripts/manifests/whatever around them to stand up services. That should happen out of the box without requiring anyone to jump through 50 hoops. It also means that you can scale from 1 instance all the way up to 5000 instances which is a lot better than optimizing for the 5000 instance case.

I'll definitely give you a shout on IRC.

</comment></comment></comment></comment><comment><USER18> I hate to say it, but this is just a rant by a RedHat/CentOS admin who has started using Debian/Ubuntu for the first time and just doesn't know why things are done differently there.

<comment><USER10> Author here. You're 99% correct. I'm historically an RHEL-based admin, who has started using Debian/Ubuntu for the first time (relatively, for about a year), but I totally get _why_ these things are done. What I deeply disagree with is _how_ they're done.

Why are there so many non-standard ways that a package can decide to not start? I really appreciate that the package maintainer is _trying_ to do the right thing, but it's ridiculous that there isn't _a way_ to do it - there's the Debian default and then there's whatever the packager thought up.

That's nuts, and needing to manage the same resource twice in puppet isn't a tragedy or big deal, but it's a symptom that something is wrong.

<comment><USER19> You keep saying things like "so many non-standard ways that a package can decide to not start" and "whatever the packager thought up". Can you provide examples of what you mean?

In your blog post you only mention one way of controlling startup- via an environment variable sourced from a file in /etc/defaults. This is the standardized, documented place in Debian for controlling the behavior of init scripts. Offhand, I can't think of any other ways I've seen packager maintainers controlling startup. I'd really need to see more evidence before agreeing that things are "ridiculous", "nuts", or "wrong".

[http://www.debian.org/doc/manuals/maint- guide/dother.en.html...](http://www.debian.org/doc/manuals/maint- guide/dother.en.html#initd)

<comment><USER20> The file is a standard, but the contents are not. For the most part, that makes sense, but it would be nice if there were a few standards there. Eg, DISABLE_ALL_SERVICES=true|false. :)

More examples here: [http://serverfault.com/questions/526075/fixing-services- that...](http://serverfault.com/questions/526075/fixing-services-that-have- been-disabled-in-etc-default-with-puppet)

As it is, figuring out exactly how to do this has to be done for each service. It's tedious, IMO, though I understand the history of why this is the case.

<comment><USER19> Sure, I can see the value in making service configuration more standard. E.G. after getting over the learning curve I've found working with systemd more pleasant than SysVinit.

I disagree that this is currently really more of a problem on Debian/Ubuntu that it is on Red Hat. E.G. If I want to manage BIND via puppet on Red Hat, I'm going to have to care about /etc/sysconfig/named.

</comment></comment></comment></comment></comment><comment><USER21> The author is spot on.

This has been a long-standing bug in Debian which, due to their glacial processes, will probably prevail eternally.

In theory it is possible to disable the post installation auto-start with a specially crafted 'policy-rc.d'. In practice you don't want to go there, as it tends to break in unexpected ways.

</comment><comment><USER22> I answered the serverfault post.

[http://serverfault.com/a/526123/76707](http://serverfault.com/a/526123/76707)

I'm a longtime Redhat/CentOS guy recently moved over to Ubuntu. It has definitely been a bit weird getting adjusted.

One counterpoint to the OP's rant? SSH.

</comment><comment><USER23> It seems like a lot of these comments are missing the point by discussing virtues of various packaging systems and auto-start behaviors.

It seems to me that the author was saying that consistency is important - installed services are expected to have a consistent behavior on a given platform.

A lot of tooling is built based on this, because that behavior is defined by the respective systems.

When people force override of these behaviors, it does break things as well as cause frustration.

The article isn't a criticism of any one packaging system or autostart choice of a distribution, but rather of individual packagers who impose their own choices over those of the system they're packaging for.

</comment><comment><USER24> Debian's thinking on this is that a user won't install a daemon unless he wants it to run, and that a package should get everything into an immediately useable state by default. Therefore, a daemon should be started automatically when a package is installed.

I agree with the objection: I think that times have moved on, and in reality today people use configuration management tools and almost always want to change the default configuration on a server daemon. Therefore, it doesn't make much sense to start it automatically.

As bashtoni says: this isn't a problem with package maintainers. It's a problem with Debian Policy.

A stepping stone to a full solution is to arrange a standard to configure the system not to start a daemon by default, and arrange for packages to follow that standard. policy-rc.d is just such a standard.

</comment><comment><USER25> I agree on the autostart.

</comment><comment><USER26> I believe ElasticSearch will automatically connect to any nodes with the same cluster-name. The package installs it with the default cluster-name. Since it starts on install, you don't have a chance to change this name before it's done that...

<comment><USER27> Apache's Cassandra deb that a similar behaviour and has a greater impact than ES's super-hero node names. A newly started Cassandra node will absent a token declaration in its yaml file, auto-assign a token. This is never what you want in a cluster distribution. So the workaround is either to patch the deb to not autostart or let it start, stop it, and blow away the data directories. This allows cluster management tools (such as Priam) to control the token allocation first, and then re-start Cassandra.

This is effectively how Debian/Ubuntu work. Once you know it, you can work around it. That said, it would be nice to have packages that don't run their service.</comment></comment>


Ask HN: What do you Google every single time and never just memorize? - <AUTHOR> <comment><USER2> Git commands: How to reset my repo to match the remote? How to delete a file from repo but leave the local copy? How to undo an unpushed commit?

I've actually started putting these in Anki[1] to memorize, along with python and js syntax. Too early to tell if I'll keep the reviewing habit, but so far it's going well.

[1] [https://apps.ankiweb.net/](https://apps.ankiweb.net/)

<comment><USER3> I use fish shell, which lets you create abbreviations. Abbreviations are like shell aliases, except that after you type them, they expand to the entire command -- so it helps you memorize the real thing as well! Also there's auto- complete, which helps you find your saved abbreviations.

For example, to save an abbreviation:

$ abbr undo-unpushed-commit 'git reset --hard HEAD^'

... later ...

Start typing a few chars and it'll suggest the rest:

$ undo-u|npushed-commit

Press the right arrow key to accept the suggestion

$ undo-unpushed-commit|

When you press enter or space, the abbreviation will expand:

$ git reset --hard HEAD^ |

\---

There are a lot of other reasons to use fish shell. For example, when you save abbreviations or functions or aliases, they immediately persist and propagate to other shell windows!

[https://fishshell.com/](https://fishshell.com/)

</comment></comment><comment> tony-allan I can never remember the Python strip() method. My first guess is always trim().

Sigh.</comment>


REST APIs for Databases via OData – Thoughts? - <AUTHOR> https://www.progress.com/blogs/restify-databases-expose-your-database-to-rest-web-services <comment><AUTHOR> Have you folks heard about OData? How practical is to rest-enable databases with OData? The idea is to make the databases accessible to analytics users while abstracting the database behind the REST APIs. Thoughts?</comment>


Ask YC: Is there a solution better than advertising? - <AUTHOR>

I need a bit of money for a web project I'm working on while I get it up and running. I have ~2k users right now, and I get enough hits to fund hosting if I put up ads. Is it "wrong" to put up ads after so many users have signed up? Is there some other way to monetize a small project? <comment><USER2> Where does the world get the expectation your time is free, and if they have that expectation, why should you adopt it? I feel my rent should be free, but my landlord sees things differently. Until our landlords come around, and food is also free, no, I don't think it's dishonest for me, or you, to be compensated for their work through ads or subscriptions.

To more directly answer your question, though, you could also look at doing "pro" level subscription memberships if that applies. That can work well.

</comment><comment><USER3> Ads are acceptable though it may slow down site growth. If the ads don't get in the way of your users, they won't mind as much. Also, a donation button might be worthwhile as well; but don't expect it to make much money for you. Consider for example the sob story at the top of the page: <http://gnosis.cx/TPiP/>. Two donations out of 1,000 book downloads a month.

If you can add some extra/useful features to the site, why not setup a premium subscription? Set the price low to start and that will likely get more revenue this way.

Good luck!

</comment><comment><USER4> It is not a question if it is wrong, but if it will work or not.

</comment><comment><USER5> "Is there a solution better than advertising?"

With 2k users, there'd better be.

I'm no expert, but a donation link would probably be more honest, more appreciated, and more effective. Just tell your story. People may surprise you.

</comment><comment><USER6> If you need the money, start integrating tasteful ads. Especially if ads are part of the intended eventual revenue model, getting them started early is more honest with your users, and starts your ad-optimization learning cycle. (In some cases, ads will even make a site look more professional/stable.)

If your userbase is such that it may react negatively, and you still need the money, consider a donation or subscription option. Or sell part of the venture, if the eventual upside can justify the trouble for you and risk for investors.</comment>


Linux follows an inverse form of Conway's Law - <AUTHOR> https://email@example.com/does-conways-law-apply-to-linux-6acf23c1ef15 <comment><USER2> Conway's Law absolutely applies to Linux. The trick is to remember that the communication patterns that Linux is optimized to reflect is "git tree pulls". Over time, things have been factored to minimize the amount of cross-tree merge conflicts. That way we can decentralize the development effort, and worry much less about conflicts when Linus has to pull from a hundred-odd git trees (many of which have sub-trees that were merged together by the subsystem maintainers before Linus then pulled them into his tree). But _that_ is the primary communication pattern which is critical, and we have absolutely optimized how the code has been laid out to minimize communication difficulties --- when defined in terms of merge conflicts.

</comment><comment><USER3> I don't think the author makes a very convincing point here; Linux is frequently cited as a prime example of Conway's Law in practice for a reason.

The reason the driver subsystem is architected as pluggable modules ("drivers") is to support the extremely wide array of organizations that have to build into it.

The reason why Linux is broken down into subsystems is to support the "specialists" who work in only on system at a time.

The reason Linux is a monolithic kernel that has a large degree of complication internally (vs. a microkernel) is because Linus is strong enough to make it happen.

I mean, the logical error is right in the title. The author inverted cause and effect.

<comment><USER4> It seems absurd that an article claims to disprove a hypothesis linking structure to communication patterns without even the slightest mention of trying to observe those patterns. But they go even further: they claim to have determined the direction of causality between two variables without even having measured one of them!

</comment></comment><comment><USER5> Misleading y-axis strikes again: [https://cdn- images-1.medium.com/max/800/1*MiF0VmKW19IC3OlVDI...](https://cdn- images-1.medium.com/max/800/1*MiF0VmKW19IC3OlVDISgZA.png)

<comment><USER6> It's not just a misleading y-axis, it's completely the wrong kind of graph for showing that kind of data. Should've used a stacked bar graph...

<comment><USER7> I would have gone with a pi graph of the average over the years.

<comment><USER6> That would only be useful if you didn't care about historical data. Also, plotting averages like that can be _exceptionally_ misleading because you don't get an insight into the distribution of the data.

</comment></comment></comment></comment><comment><USER8> What the article is suggesting is that the Linux architecture wasn't affected by organisational pressures that closed-source systems face.

That is to say that subsytems were defined solely based on technical considerations, which is how it should be if the goal is sound engineering.

Not sure what to make of the ratio between "specialists" and "generalists". A comparison to ratios from other projects would provide some helpful context.

<comment><USER9> > That is to say that subsytems were defined solely based on technical > considerations, which is how it should be if the goal is sound engineering.

I think that's too idealistic. As another sibling poster pointed out, it's more like a democracy... with all the attendant upsides and _downsides_. (Also, I'm _sure_ there's a lot of interpersonal politics involved, even if it's all over email.)

Don't get me wrong, the Linux kernel works surprisingly well and I rely on it for almost everything (including my livelihood), but if you _really_ look at it, some of the subsystems are _shockingly_ bad.

I think a good example is containers/namespaces which have a ridiculously bad security record. (See "user namespaces".) Again, I'm sure the people working on these things had the best of intentions, are _very_ competent generally, and were hampered by the "never break userspace" rule. However, if containers/namespaces were truly _designed_ , it could have been done a _lot_ better. (See "Zones" on Solaris et al.)

<comment><USER10> I agree with you. But I think you're being generous when saying _some_ of the subsystems and architecture are shockingly bad. Some of them are not even designed. If you look at them it's like "This isn't even useable!"

The problem with namespaces and all the "container" tooling built on top of it is, as you noted, security. They were never designed to be secure from the start. It was not meant to be. And it was always puzzling to me why someone would use them to build containers on. Knowing it wasn't secure.

As you also note Solaris got it right with zones, FreeBSD got it right with jails, there was plenty of options to use and build on. But as is the typical Linux story they had to do things there own way, and poorly.

I still have no idea what Linux land is going to do for a filesystem. Since it's pretty clear ZFS is kept at arms length. Btrfs seems like the horse they are hitching to? Filesystems are hard. Which is why they can't seem to write a solid, reliable one and keep starting over. I think it's a big issue for them and is only going to get worse as data continues to explode exponentially.

I wish zfs had been BSD licensed. And I wish Linux had simply adopted it as well. But those ships have sailed. Where to now?

<comment><USER9> Agreed, I probably was being a bit too generous, but I usually try to be as "diplomatic" as possible :).

I don't know much about the BSDs, but my impression was that jails don't really offer nearly enough to rival Zones. Zones is really "containers done right"[1].

Definitely agree on ZFS. I'm currently using ZoL on my Ubuntu servers, but I'm not going to try using it on anything else. (FWIW, it's working marvellously so far.)

Personally, my current best hope for a good Linux FS at the moment is Bcachefs[2]. It's based on the proven Bcache. It's mostly done by a single very talented programmer/designer who _knows_ when he's out of his depth[3].

[1] Not "virtualization" per se, but as close to it as makes no difference, if that makes sense?

[2] [https://www.patreon.com/bcachefs](https://www.patreon.com/bcachefs)

[3] [https://bcache.evilpiepirate.org/Encryption/](https://bcache.evilpiepirate.org/Encryption/) (the initial paragraph; AFAIR there's a lot more out there about the process, but I didn't stash any links and that's all I could find in 30 seconds :).

<comment><USER10> Zones was the logical conclusion to FreeBSD jail work. They added the full features jails now has finished. Each zone getting its own IP stack for instance. Jails didn't have that in the beginning. It was written by one guy to simply offer a basic but secure container for running multiple web servers in isolation from the host. Had he had the resources of sun Microsystems I'm sure he would have had all the features zones had from the start. But one man can only do so much with finite resources. And the main design goal was security and isolation. Which was accomplished. Separate network stacks was added later.

I'm glad to hear your using it. I really can't imagine using anything else. Open source or commercial. Nothing is as compelling or reliable and easy to use. Me personally, i am forever grateful for Sun open sourcing it. I remember pre zfs days, with volume managers, and how hard it was to grow a ufs/ffs anything, just an absolute nightmare. And backups? Ugh. Tapes. Hoping every bit was copied, but never really knowing for sure. Just ugh. The pain.

I've heard bcachefs talked about to. And as you originally stated I think these folks writing btrfs and bcachefs are talented and are doing the best they can but again FS's are hard. Look at all the garbage we've been stuck with from all the major commercial vendors until ZFS. Everything Microsoft puked up, or Apple, even the major UNIX vendors sucked at making file systems and volume management. Veritas? I'd rather stab my eyes with soldering irons than use any of that stuff ever again. Seriously ZFS compared to all of them is night and day. I'll never be able to thank the developers enough for helping me out of the pit of filesystem and volume management hell. I'll be interested to see how bcachefs ends up. But mostly I think everyone will be trying to play catch up to ZFS and more than likely doing it poorly. But I applaud their efforts to try!

Thanks for the links btw, I always enjoy reading up on various tech.

<comment><USER9> FWIW, I think there's a huge difference in approach (and humility[1]) between the Btrfs and Bcachefs developers. I'm sponsoring the latter.

[1] I tried to make this point, perhaps badly.

</comment></comment></comment></comment></comment></comment><comment><USER11> The article makes a good point but I wonder if it is an incomplete explanation. What would happen if Linus Torvalds walked away and there was no single leader to guide (or "dictate", depending on your point of view) its development? Would it begin to fragment and exhibit signs of Conway's Law?

I believe the answer is, yes, it would. While Linus is a stubborn and opinionated leader ("Benevolent Dictator For Life") it is those qualities, coupled with his extremely high standards, that have preserved the coherence of Linux's system architecture all this time.

<comment><USER12> I wonder if there are any large, successful open source projects that are leaderless and function well without a social hierarchy?

If non-hierarchical social structures are really more effective, such examples should be easy to find, no?

On the other hand, maybe their absence only indicates that online communities simply tend to mirror the social structures of offline communities, or that they're just mostly made up of people who prefer hierarchies.

<comment><USER13> Extremely relevant:

[https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessne...](https://en.wikipedia.org/wiki/The_Tyranny_of_Structurelessness)

tl;dr - hierarchies will form whether you want them to or not. If you refuse to endorse an official structure, you'll simply get an unofficial (and more often than not, unaccountable) one instead.

</comment></comment></comment><comment><USER14> I've elsewhere seen described the "Inverse Conway Manoeuvre": make the org fit the emerging architecture.

We do this at work. It mostly works, modulo "Distributed Systems Are Hard".

<comment><USER15> I have also done this at work with (what I believe) some success, w/o the distributed systems aspect.

<comment><USER16> Unless you are a company of one person, you have a distributed system.

<comment><USER15> No, not really. Now the total system is distributed, but the parts I tried this on weren't. They were Mac and iOS clients with shared code. I moved the architecture from two separate apps that have some shared libs towards a headless app that is basically the same and has two UIs (also with shared code) sitting on top.

<comment><USER16> So in what way did you change your org to reflect the software structure, re. the grandparent comment?

My reply was about orgs, not your software. Since orgs are made of people, they are distributed systems.

</comment></comment></comment></comment></comment><comment><USER17> There is an unsubstantiated ocean between the "Therefore" beginning the last paragraph and the paragraphs before it. If anything, the author's data points lead me to draw the opposite conclusion.

</comment><comment><USER18> The statistics seem to be obviously incorrect, there is no discount for the distribution of the number of files that a contributor might author/have a significant effect on. Since most contributors will have made a small number of contributions, this is a large bias.

The graph that would ultimately support the point of the article would have the difference between a simulation of a uniform distribution of contributions by the authors, and have a full 0-100% axis for scale, as opposed to the 35-65% presented in this article.

</comment><comment><USER19> > the Degree-of-Authorship (DOA) measure to define the authors of each file in > a system

But in source control, author is typically defined as the first contributor to a file, which doesn't always reflect the person who contributed the most content to the file.

<comment><USER6> The paper they linked to has a much better description of how they figure out file authors, and how they avoid issues with one-time contributors.

</comment></comment><comment><USER20> In my experience, while the statistics that the article quotes are obviously correct, the reasons have very little to do with the architecture, and they very much mimic the way that the "community" works. Linux' architecture has very little to do with why communication (and contributions) are the way they are. In fact, the architecture is largely designed precisely so that it can _withstand_ the sort of organizational pressure that the Linux kernel faces. See, for example, the recent(-ish) rejection of AMD's drivers: they got rejected because they included a HAL, which -- based on previous exeperience -- is usually a bad idea in an open system, as it tends to depend on highly organization-specific knowledge, and the volume and difficulty of maintenance work makes it difficult to manage by a non-committed community once the main owner drops it for greener pa$ture$.

The very separation that the article draws "core" vs "drivers" is actually highly representative of how the Linux community is structured. Most of the core work (including the driver subsystem's backbone) is done by long-term contributors who actually work on the Linux kernel full time. Most drivers actually come from occasional contributors.

Driver contributions are "specialized" for the same reasons why they're specialized on pretty much any non-hobby operating system, namely:

1\. The expertise required to write complex drivers mainly exists within the organization that sells the hardware. Needless to say, these people are largely paid -- by the hardware manufacturers! -- to pay drivers, not contribute to what the article calls core subsystems. There are exceptions ("trivial" devices, such as simple EEPROMs in drivers/misc, are written by people outside the organizations that sold them), but otherwise drivers are mostly one-organization shows. In fact, for some hardware devices, "generalists" don't even have access to the sort of documentation required to write the drivers in the first place. (sauce: wrote Linux drivers for devices that you and me can't get datasheets for. $manufacturer doesn't even bother to talk to you if you aren't Really Big (TM))

2\. Furthermore, there really are subsystems in the kernel that are largely a one-company show and are very obvious examples of Conway's law. IIO drivers, for instance, while started by Jonathan Cameron who, IIRC, is really an independent developer, are largely Intel' and Analog Devices' \-- to such a degree that, even though they follow the same coding conventions, if you've worked there enough, you can tell who wrote a given snippet. Same goes for most of the graphics drivers. Most of Infiniband used to be IBM, I think. If you dig down in the drivers subsystems, you'll see even funnier examples (my favourite example are ChipIdea USB controllers; a few years ago, support for USB slave mode on some Broadcom SoCs broke down because Freescale pretty much took over de facto ownership of the drivers, and some of their changesets worked fine on their ARM cores, but broke on Broadcom's funky MIPS-based cores)

Also, this is very weird to me:

> Adherence to Conway's Lay _(sic!)_ is often mentioned as one of the benefits > of microservices architecture.

Back in My Day (TM), adherence to Conway's Law was usually considered a negative trait, summarized by the mantra that, in the absence of proper technical leadership, an organization of N teams tasked with writing a compiler is going to produce an N-pass compiler.

Of course, this _is_ a most negative example, but are we really, seriously considering that adherence to Conway's law is a positive thing today? That it's actually a good idea for the architecture of a software system to reflect the "architecture" of the team that created it, rather than, you know, _the architecture that 's actually best for what it's meant to do_?

<comment><USER21> Adherence to Conway's Law _is_ regarded as a good thing, but not that way round. We want to build the teams to match the architecture of the software we're building, not vice versa. If you don't cut it that way, you're always going to be swimming upstream.

</comment></comment><comment><USER22> [https://en.wikipedia.org/wiki/Conway%27s_law](https://en.wikipedia.org/wiki/Conway%27s_law)

</comment><comment><USER23> Could this be related to the fact that all communication between Linux devs is done by email?</comment>


Ask HN: Need a TI-85 calculator? - <AUTHOR>

A while back there was a thread from someone with an old scientific calc who asked if anyone needed it. Quite a few people seemed to express interest and as such, I'm now making the same offer...
While cleaning in preparation for a move, I found an old TI-85 calculator from high school at the bottom of a box. The lid doesn't fit very tightly anymore but the calculator is in perfect working condition and I just cleared the memory.
It's not the most advanced TI in the world but if you're a student in need of one and money is tight, this will definitely get the job done. The similar post I referenced above asked people to make their case in the thread but I don't think it's necessary to ask people recount their plight in a public forum. Please just email me if you need the calc and are having trouble purchasing one on your own. First come, first served -- I'll cover shipping (US please).
I will post an update if and when the calc is spoken for. <comment><AUTHOR> Calculator is spoken for, thanks guys.</comment>


Why is my processor consuming more power than its datasheet suggests? - <AUTHOR> https://www.analog.com/en/analog-dialogue/raqs/raq-issue-146.html <comment><USER4> Reminds me of the development of a battery powered medical device I did about 7 years ago. We selected an esoteric Freescale microcontroller for that project (which was successfully used in such applications before), but for the life of me I couldn't get the power consumption in deep sleep to come anywhere near the spec (few microamps IIRC).

Eventually, after scanning the datasheet forward and backward again and again, I had this idea which turned out to be the right answer: microcontrollers usually come in several package configurations, each with a different number of pins. Freescale used the same silicon die in all of the variants of that microcontroller, and left unrouted pins floating internally. I had to write to registers which, on paper, didn't even exist on this processor variant to put all I/Os in a defined state. The power consumption then came within the spec.

</comment><comment><USER5> We had a similar issue, but with date corruption instead of just excess power usage. Always tie every input to something, don't just leave them unused.

</comment><comment><USER6> TL;DR: if you don't treat unused pins according to the datasheet recommendations, then all bets are off.

This is even true with lowly things like op-amps. If you have a dual op-amp IC, and you use only one op-amp, you should do something appropriate with the pins of the unused one.

[http://www.ti.com/lit/an/sboa204a/sboa204a.pdf](http://www.ti.com/lit/an/sboa204a/sboa204a.pdf)

</comment><comment><USER7> The Analog Dialog is a treasury of good advice going back decades. Really worth your time if you have any interest at all in electronics.

</comment><comment><USER8> Better question - where did they get a datasheet?

Ok - I haven't read the article - maybe they're talking about some processor where the manufacturer actually provides a datasheet. Most companies do. I think even AMD does; I know you can get datasheets for the ARM implementations, and most other embedded processors...

...but has anyone found any recent Intel processor datasheets (ok, maybe at this point they'd be several volume databook libraries - but you know what I mean)?

The last time I tried to find something recent from Intel, the most recent datasheet of any kind I could find (one that listed technical stuff like registers, pins, opcodes, etc - not just some basic figures and marketing junk), I think the latest I found was for the Core2 Duo/Quad series - <USER3> nothing after that?

Is there some secret trick to getting these? All I could figure at the time was that you had to be part of some program or something, maybe with an NDA - or an actual motherboard manufacturer or something? But then again, how would you write a compiler without the information about opcodes and such?

Now honestly - I don't need such datasheets. But I wanted to look at something "cutting edge" or relatively new (and really, the Core2 datasheet was good enough for this) - and compare it with old datasheets for like the 6809 or 6502 or Z-80, old-school 8-bit processors (the ones I grew up with) - just to see how things have changed (or haven't) and how "insane" things have gotten.

More like a lark for a laugh kind of thing that anything else.

It just struck me that I couldn't easily find them for recent Intel stuff...at least, not easily on the web (but again, maybe I wasn't looking in the right area, or there are other reasons at play).

<comment><USER9> _> Ok - I haven't read the article - maybe they're talking about some processor where the manufacturer actually provides a datasheet._

You don't ever need to read the article, URI is enough to know the manufacturer.

 _> The last time I tried to find something recent from Intel, the most recent datasheet of any kind I could find (one that listed technical stuff like registers, pins, opcodes, etc - not just some basic figures and marketing junk), I think the latest I found was for the Core2 Duo/Quad series - <USER3> nothing after that_

That was the last generation supported by non-Intel chipsets. It is not a coincidence.</comment></comment>


Is the NSA taking over SSL hosting services quietly? - <AUTHOR> http://www.tgdaily.com/content/view/35378/122/ <comment><USER2> This wouldn't surprise me at all -- the NSA has a large budget, and (now that strong cryptography is widely available) wants as wide an array of tools as possible. Buying access to data, stealing it by exploiting security flaws in software, snooping on it via EM emissions, obtaining encryption keys via side channel attacks, and (with the assistance of the CIA and/or FBI) capturing passphrases using keyloggers are all techniques which the NSA is believed to have used in the past.

</comment><comment><USER3> So is there a post somewhere with actual evidence? Or is it equally likely that the aliens in the employ of the US DoE's Paranormal Task Force have bought and backdoored Verisign?

10 bucks says this conspiracy theory finds its roots in some company owned by In-Q-Tel, the _gasp_ CIA's _gasp_ VC fund.

<comment><USER4> A very sane assumption is that the NSA has extensive monitoring capability that they poor an assload of money into expanding every year.

The only rediculous idea here would be to assume that this is something new.

<comment><USER3> The fun part about talking about the NSA is that you don't have to exercise critical thinking; you just propose counterfactuals, citing the NSA's "huge budget". "Of course they could be monitoring Hushmail". "Of course they could be monitoring the Internet." "Of course they could be monitoring all our phones." "Of course they could have chips implanted in our brains". I mean, after all, they're the NSA!

<comment><USER4> you do know that chances are that some of us may actually have experience with these _massive_ organizations, right?

<comment><USER3> What's your point?

</comment></comment></comment></comment></comment><comment><USER5> It doesn't sound unreasonable, but they aren't providing any data. If there's really all this money changing hands they should be able to find when the companies were sold and to what entity, and possibly even try to figure out where else the purchasing entity is involved, like seeing what other properties they own and what business they conduct.

</comment><comment><USER6> Idea! $_$</comment>