Show HN: Sourcegraph Chrome extension - review code on GitHub like in an IDE - <AUTHOR> https://chrome.google.com/webstore/detail/sourcegraph-for-github/dgjhfomjieaadpoljlnidmbgkdffpack <comment><USER2> It's cool and all I guess but now there are two "Show HN:" for the same thing on the same page by the same poster. Seems unnecessary.</comment>


Support for C, C++ native code in Windows Phone 8 - <AUTHOR> http://thenextweb.com/microsoft/2012/06/20/windows-phone-8-developers-will-have-access-to-native-code-nfc-and-more/

<comment><USER2> Now if only they would admit defeat and support OpenGL ES. If they really want more "apps" on their platform, then removing the need to port that part of applications would be a huge win.

<comment><USER3> Google apparently has a library (used in Chrome) that implements "most" of OpenGL ES 2.0 over DirectX. I wonder how much help it might provide in this context.

[http://blog.chromium.org/2010/03/introducing-angle- project.h...](http://blog.chromium.org/2010/03/introducing-angle-project.html)

</comment></comment><comment><USER4> At this point, it appears to be possible to target iOS, Android, and webOS with C and OpenGL (I haven't tried building an app this way, but it's on my to-do list). Here's hoping that this development means I can add Windows Phone to this list. :-)

<comment><USER5> This only works for games. How do you do User Interface in C on Android?

For games, windows phone doesn't support opengl es. So you still need to rewrite some code.

<comment><USER4> Build your own UI widgets with OpenGL? :-P

It does look like someone is already experimenting with an OpenGL ES implementation over XNA, so we might still have access to some form of OpenGL on WP: [http://www.straightforward.se/storyserver/opengl-es- support-...](http://www.straightforward.se/storyserver/opengl-es-support-on- windows-phone-7)

<comment><USER5> I doubt XNA based Opengl ES will be efficient. If I were a game developer, I'd rather rewrite my code.

The Game problem can be solved with game engines. But I'd like to write opengl directly.

As for UI, Qt for android is a good approach.</comment></comment></comment></comment>


PVS-Studio vs Chromium - Continuation - <AUTHOR> http://www.viva64.com/en/b/0113/

<comment><AUTHOR> About half a year ago we checked the Chromium project and wrote an article about it - <http://www.viva64.com/en/a/0074/> . The PVS-Studio analyzer naturally keeps developing, and in the new Chromium version we have found some errors undetected before. Many errors, of course, refer not to the Chromium project itself but to libraries it employs. But in this article I want to show you how the analyzer's capabilities have improved and not tell you about what we have found in this or that part of Chromium. That's why I will give messages together.</comment>


WhatsApp limits message forwarding in bid to reduce spam and misinformation - <AUTHOR> https://techcrunch.com/2018/07/19/whatsapp-limits-message-forwarding/ <comment><USER2> I am sure that it reduces fake news. I also expect that it can block real but rare mega news events like "the president was attacked" or "tsunami on its way to California".</comment>


Tesla Employees Call 'BS' on Online Sales Claims - <AUTHOR> https://jalopnik.com/tesla-employees-call-bullshit-on-online-sales-claims-am-1833201246 <comment><AUTHOR> This excerpt is particularly sad & gross on Tesla's part:

To add insult to injury, Tesla had offered employees a discount program at the end of 2018 that gave them the cars' so-called self-driving package, an $8,000 value for free, plus $5,000 off any model, for a total discount of $13,000. According to Business Insider, the company also encouraged employees to trade in accrued paid time off towards the purchase of a car.

Derek told me he was one of the only employees at his store that didn't take advantage of the offer after a fourth quarter where the store did very well and pockets were filled with compensation bonuses. Now they all have hefty car loans for expensive vehicles they're worried about paying off without a job.

</comment><comment><USER2> > Commissions were cut, slashing many salaries 50 percent or more with no > notice. Employees weren't allowed to take paid time off out of concern > everyone would use it to look for other jobs.

Boy, that's a dick move. Tesla decides to lay off it's works, so it cuts their pay and attempts to sabotage their efforts to find other work?

Seriously, professionally run companies offer _extra pay_ (e.g. severance) to employees they need temporarily but plan to lay off.

<comment><AUTHOR> Tesla is attempting constructive dismissal, trying to get employees to quit "voluntarily" so the company doesn't have to deal with the expense and hassle of proper terminations.</comment></comment>


Ask HN: What are day to day "problems" that have verified solutions? - <AUTHOR> Especially interested in those things that keep coming up at workplaces, at home, or anywhere between.
Maybe the people with these problems have not (yet) been exposed to the solution, or maybe it runs counter to intuition and doesn't 'stick', but our collective knowledge knows. And you know. It might even drive you a little crazy that it keeps coming up.
Some examples: Date formatting ( https://xkcd.com/1179/ ) and data integrity (Reed–Solomon error correction), or even more "mundane" things like how to fairly split something up between two people (one splits, the other chooses). <comment><USER2> This is an excellent question, and I'm disappointed this hasn't received more attention.

Secretary problem - applicable to anything where you have a lot of choices, such as marriage, getting a job (not just hiring), picking a business partner, anything you have to accept/refuse.

The solution is you reject the first 37% of applicants, use that to establish a benchmark, and then pick the first one who is better than any rejected. You're 37% likely to find the best candidate. But such is life. In other words, once you marry someone out of 10 choices, there's 63% odds you'll find someone better later.

There's Amdahl's Law/Gustafson's Law, explained nicely here: [https://www.embeddedrelated.com/showarticle/1033.php](https://www.embeddedrelated.com/showarticle/1033.php)

Basically, upon first observations, Amdahl's Law seems true... even if you put 10x more effort into something, it seems like the total output is 42% higher. But this total output being 42% higher means that you can also do X, Y, and Z, 42% faster. Having Z 42% faster leads to A being 20% faster, leading to B being 8% faster, and B is a feedback back into the loop.

In more practical terms, much faster computers means software is written slightly faster, but slightly faster software allows for more complicated electronics CAD, which allows us much faster computers, which allows for even more advanced technical developments like Internet and cryptocurrency.

In short, if you're locked on Amdahl's Law (minor gains for tremendous effort), find a way to utilize Gustafson's Law (looping the gains back).</comment>


UEFI boot: how does that actually work, then? (2014) - <AUTHOR> http://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then <comment><USER2> Please add (2014) to the title.</comment>


Ask HN: Career as an Information Security Analyst - <AUTHOR> I've been working as an information security analyst for a year now. I don't find much information online for this job, beyond basic career statistics and job postings.
I graduated with comp sci, and like most I was a hobbyist programmer and passionate about making software. So this wasn't something I was especially prepared for. It's not easy.
I'm looking to learn from more experienced ISAs, or people familiar with the field, so please share your experience with the career, what kind of work you do, and how you progress. What community do you participate in? Where do you get your news/industry info from? <comment><USER2> I'm not an analyst, but I'm in the field. It's broad, and not many good targeted communities exist that I know of. Here is my current list of places to check regularly. Let me know if you know of others!

## Social [https://www.reddit.com/user/goretsky/m/security/](https://www.reddit.com/user/goretsky/m/security/) \- compliation of 90-100 security subreddits.

## Security / Tech News [https://www.darkreading.com/](https://www.darkreading.com/) [https://www.bleepingcomputer.com/](https://www.bleepingcomputer.com/) [https://news.ycombinator.com/](https://news.ycombinator.com/) [https://nakedsecurity.sophos.com/](https://nakedsecurity.sophos.com/) [https://threatpost.com/](https://threatpost.com/) [https://blog.erratasec.com/](https://blog.erratasec.com/) [https://krebsonsecurity.com/](https://krebsonsecurity.com/) [https://medium.com/mitre-attack](https://medium.com/mitre-attack) [https://threatpost.com/](https://threatpost.com/)

## Threat updates / SOC [https://www.securitywizardry.com/radar.htm](https://www.securitywizardry.com/radar.htm) \- dashboard - virus news, latest alert feeds [https://www.talosintelligence.com/](https://www.talosintelligence.com/) \- reputation lookup for networks & vuln reports

## Podcasts [http://defensivesecurity.org/](http://defensivesecurity.org/) [https://securityledger.com/](https://securityledger.com/) [https://securityweekly.com/](https://securityweekly.com/) [https://risky.biz](https://risky.biz)

## Slack Communities OWASP - owasp.slack.com DFIR IR - dfircommunity.slack.com - mostly around the Demisto products, but some other discussion as well Hangops Infosec - hangops.slack.com - infosec channel</comment>


Evolution of a dashboard design - <AUTHOR> http://www.contrast.ie/blog/evolution-of-a-dashboard-design

<comment><USER3> This looks like great info to have and we've been building out similar tools for both internal use and some tailored ones for our customers, but I won't know until later because the site's leading is so awful as to be unreadable and I had to throw it in instapaper instead to read later. You could drive a truck through the space in between the lines. So many sites mess this up and I don't know where the trend of insanely high line-height values are coming from, since I'm guessing it's usually not part of the default template styles.

It's really simple - keep the line-height down to about 120-140%. And the shorter the line length - like with this article - the less distance you need because the eye is wrapping back around from the right edge at quicker intervals, so it doesn't lose it's place on the left.

</comment><comment><USER4> Very nice post, and the dashboards look great, but one thing seems to be missing: the actionable metrics. Metrics for metrics' sake can be dangerous and not necessarily all that helpful. You shouldn't guess why the conversion rate went up, you should know because you a/b tested it...

More detail about this argument here: [http://swombat.com/2011/1/13/dashboard- evolution-vanity-metr...](http://swombat.com/2011/1/13/dashboard-evolution- vanity-metrics)

</comment><comment><USER5> We're developing simple technology that will allow non-technical users to start building shared dashboards in a native web spreadsheet.

We would love to speak to anyone with a strong interest in this area - <USER2> give me a bell.</comment>


How That Vicious Inner Critic Can Be Your Closest Ally - <AUTHOR> http://themodernteam.com/how-that-vicious-inner-critic-can-be-your-closest-ally/ <comment><USER2> When I loaded this page, upon the slightest movement of the cursor, I got a popup ("We'd be crazy to let you leave without asking...") that _would. not. dismiss._

The behavior is limited to incognito windows, but it's still obnoxious.</comment>


Show HN: NimbleSign – The quickest way to digitally sign your documents - <AUTHOR> https://www.nimblesign.com/ <comment><USER2> It would be nice if there was some sort of example on the landing page, so people could get a better idea of what the output is going to look like.</comment>


Seattle uses Datacenters to heat buildings - <AUTHOR> http://money.cnn.com/2014/04/07/technology/innovation/data-centers-heat/index.html?iid=HP_LN

<comment><USER2> Thanks for sharing this! I love examples of capturing the myriad forms of free, "waste" energy.

Another oldie: a nightclub that uses the kinetic energy of dancers' feet to generate electricity.

[http://www.dailymail.co.uk/sciencetech/article-1027362/Brita...](http://www.dailymail.co.uk/sciencetech/article-1027362/Britains- eco-nightclub-powered-pounding-feet-opens-doors.html)</comment>


ActivityPub, the secret weapon of the Fediverse - <AUTHOR> https://homehack.nl/activitypub-the-secret-weapon-of-the-fediverse/ <comment><USER2> I really think that open source federated services are the future. There are now a bunch of these services all using the same protocol called ActivityPub. PeetTube is a YouTube alternative, PixelFed replaces instagram, Lemmy is an alternative to Reddit, and Plume is like medium. There are a few other projects as well. All of these services are able to talk to each other and allow users to share data across them creating one large federated platform. Meanwhile, traditional commercial platforms like Fb, Twitter, and Youtube have zero incentive to allow users to move data between them.

Another important aspect of the Fediverse is that it's much harder to censor and manipulate than centralized networks. There is no single company deciding what content can go on the network, and servers are hosted by regular people across many different countries.

A federated network that's developed in the open and largely hosted non-profit is the way internet was intended to work in the first place before it was hijacked by corporations. I'm very glad to see that decentralized networks are finally starting to get popular again.

<comment><USER3> What's the difference between Plume and Mastodon?

edit: nvm I see that Mastodon is more like twitter. I don't think I really understand why I'm having to create separate accounts on each instance if they can all communicate with each other?

<comment><USER4> ActivityPub is a protocol that does very little with a whole lot of words in the spec.

Accounts are not federated, there's no reasonable way of automating your switch to another server assuming yours dies, so forth, so on. Mastodon has a feature claiming to do the last one, but it doesn't actually work, because it's not backwards compatible and only works with relatively modern Mastodon instances (which most are not).

Also, you don't really a heavy expectation of privacy using ActivityPub. It's very trust-based, and not in the good way.

A lot of the function of ActivityPub would be better served by RSS feeds, the rest would probably be better served on a protocol like Zot; Diaspora would also give you a better expectation of privacy than ActivityPub.

Zot, though, fixes basically all of those problems, and is really pretty cool. You have one identity that you can use everywhere, all of your followers come with you because it wasn't an afterthought, access control actually does control access, so on, so on.

<comment><USER5> It's precisely like e-mail. Would you say email's not federated?

<comment><USER6> The way it works with email is that I create an MX record on the DNS server to tell people where mail for *@mydomain.com should go.

When I switch email hosters, I change that MX record. The downside is that it only works for the domain as a whole but not for individual email addresses.

Does ActivityPub have something like this as well?

<comment><USER5> There's no support for messages addressed to @mastodon.xyz to really point to @social.me directly, unless you do some server-side tricks yourself.

But the similarity to email is in that accounts are not federated. firstname.lastname@example.com is an independent email, including storage, from firstname.lastname@example.com - might be a different person entirely.

The 'federated' part of email is that firstname.lastname@example.com can send email to firstname.lastname@example.com, practically as if both were on the same server.

This is what ActivityPub does for social networking.

<comment><USER6> Right, so I think there are actually two separate issues here. One is federation, which is similar between email and ActivityPub as you point out.

The other is user identity. That's the part where email appears to be more flexible by relying on DNS to seperate user identity from email hosting (for the small minority of users who own their domain name).

Section 3.1 of the ActivityPub spec says that objects (I think this includes users) are identified by "publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server" [1].

Now, I wonder if an "originating server" is actually required or if it's sufficient to control the domain to which this URI belongs. It seems to me that it should be rather simple for ActivityPub implementations to support a mechanism similar to MX records. For instance, TXT records could be used to achieve the same thing.

[1] [https://www.w3.org/TR/2018/REC-activitypub-20180123/#obj- id](https://www.w3.org/TR/2018/REC-activitypub-20180123/#obj-id)

<comment><USER5> Yes, you're right that email is more flexible here, however the issue is that lets say you have your own domain name, but use fastmail. If you loose your fastmail for whatever reason and didn't have backups, you get to keep your email identity if you point your MX to a new provider, which means people can still contact you, but you won't have any of your old email.

ActivityPub servers could do something similar here and in fact Mastodon in a sense supports this, (as you point out, the Actor's identity is essentially the URL of their profile, which could change host), but the problem then becomes that old interactions with the user will have 'ghost replies'. Understandably, as far as I know to save on storage and improve response times, not every interaction a user has on the fediverse with different users is copied to his/her server, that is replies in a thread from different users on different servers are still stored on their servers. Therefore if someone in a thread deletes their server, their responses/interactions will essentially disappear to anyone viewing that thread, so I might be replying to something a user said, but you won't be able to see what I am replying to etc.

Mastodon supports import/export, so that an Actor/user should be able to move servers and as long as they import their toots+followers + use the same domain, you shouldn't notice a difference, but I don't believe this is supported by the protocol directly.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Also see PeerTube which is an attempt to provide a federated youtube based on activitypub. What I like about peertube vs others is that the primary development focus is on video and not monetisation althought there is a plugin system which would allow something in the future.

Full disclosure. I am the dev of Thorium an android PeerTube client. If anyone wants to help with development please let me know

<comment><USER8> Peertube is really cool in theory buy they are pushing torrent crap that displays the viewers public IP to all the other viewers and that is a major deal breaker for me.

I've never understood why they set it up this way instead of just letting you host the videos normally.

<comment><USER9> Why is displaying your public IP (prefix?) is an issue?

If this bothers you, shouldn't you use a VPN ?

What do you mean by "normally" ? Torrent _is_ the normal way to host large files in a distributed manner!

</comment></comment></comment><comment><USER10> ActivityPub is important. We need it to be more widely appreciated. I'm glad to see it on Hacker News.

Chris Webber, one of ActivityPub's creators, suggests next steps in "OcapPub: Towards networks of consent" [https://gitlab.com/spritely/ocappub/blob/master/README.org](https://gitlab.com/spritely/ocappub/blob/master/README.org)

Chris and I gave keynotes at ActivityPub 2019:

"ActivityPub: past, present, future" by Chris [https://www.youtube.com/watch?v=Tgq0lqZ1Mvw](https://www.youtube.com/watch?v=Tgq0lqZ1Mvw)

"Architectures of Open Robustness" by me [https://www.youtube.com/watch?v=NAfjEnu6R2g&list=PLzDw4TTug5...](https://www.youtube.com/watch?v=NAfjEnu6R2g&list=PLzDw4TTug5O0ywHrOz4VevVTYr6Kj_KtW)

</comment><comment><USER11> Pleroma guy here. Look into pleroma! It's very lite weight, coded in elixir, and full of excellent hackers

<comment><USER12> Hi, you are using the right stack for this kind of project, very promising!

I have only two questions I could not answer myself by reading the docs, it would be great if you would like to answer these:

A) Groups: for many use cases of "social softwares" groups are a very basic requirement - I can not see any way to have a group inside an instance or a way to simulate groups by using Pleroma in a multi-tenant way, like one Pleroma instance for each group served from the same code installation (ecto has a db prefix feature, maybe this could help with a quick path for a "multi- tenancy-as-groups" feature?). Am I missing something or are groups simply not there yet?

B) EU data protection: would you say that Pleroma is safe for (naive) users to install in the sense of EU conformity or is it a risk currently for a single person to offer a Pleroma instance in EU? I could not find any information about this very important topic - what again made me wonder if developers are realizing the importance of this issue at all?

Would be very interesting to read your ideas about these issues!

BTW the docs at [https://docs.pleroma.social/readme.html](https://docs.pleroma.social/readme.html) would be more readable if the sidebar could be adjusted to the width of the containing text - HTML + CSS allows that, it should be used! Also having "Top" \- a navigation directive - listed as an actual chapter name seems a little strange.

<comment><USER9> I'm wondering if EU data protection rules are fully supposed to be applied by small businesses. Because then it has very hard to properly follow consequences for contact list management (smartphone and paper phonebooks, etc.)

<comment><USER13> If not it's a loophole that would allow a large data farm to split itself into myriad "small businesses" that all share with each other.

<comment><USER9> That would either add enough friction to be too expensive, or be too easy for the anti-fraud services to figure out ?

</comment></comment></comment></comment></comment><comment><USER14> How does this deal with spam? Feels like it would be very easy to create bots on all sorts of nodes in this "fediverse" that start spamming folks with garbage

I've been curious for a while and have tried Mastodon, but am always left with... ok, now what?

<comment><USER15> "Would be"? There are already way too many bots on Mastodon, many of them do unpaid advertising for commercial news outlets (reposting their RSS feeds). I guess people who run them think they're doing "fediverse" a favour, but they're only getting more eyeballs and ad views for those outlets.

The solution is liberal and frequent use of blocking, but it's a solution that does not scale well.

<comment><USER16> actually, it's a solution that scales pretty well. I help run an medium sized mastodon instance, and I managed to silence every spammy news aggregator with a couple hours of effort, It only takes a few seconds to respond to reports of new ones, and now the couple hundred people who use my server don't need to worry about RSS spam at all. Small communities allow for more effecient moderation.

<comment><USER15> Sorry for being unclear - I was referring to blocking on user level, where everyone can decide for themselves what they consider spam, instead of leaving it "for the admin".

<comment><USER17> On user level, people could cooperate and make lists of spam accounts. There could be various lists with different values that determine who belongs on the list. People could subscribe to the lists that suit them and add all users on those lists to their block list.

</comment></comment></comment></comment></comment><comment><USER18> The entire model is flawed. You don't want federation (small tribes). That's not why people use FB, IG, Twitter. They use it because that's where the people are--network effects. The only reason I'm posting here is because this is where your message can reach people. Federation means you will never ever get network effects. Dead on arrival.

It's possible to have decentralization with network effects. Just have one canonical network. Tor and Bitcoin are good examples.

Downside (or upside?) is that you can't have moderation or else whoever does the moderation becomes the new jack and it's not decentralized anymore.

<comment><USER19> Why do people use email then?

Network effects can be achieved with or without federation. They aren't mutually exclusive.

<comment><USER18> Email is federated at a lower layer. At the UX layer, it is not federated. Fully qualified email addresses are like usernames. If you ask a random email user, they would think it works like this. If you ask a random Mastodon user, they know that they have to join a relatively isolated silo. Also most uses of email are peer-to-peer. In the case of two people emailing each other, the number of peers is 2. This is not directly comparable to public social networks.

Email was once the main way social networking was done via mailing lists. This was kind of federated, because you had to ask the listserv to add you to the list. The federated aspects of email are what caused it to die and get replaced by forums which in turn got replaced by Reddit and Twitter.

(Notice the trend? Mailing lists -> forums -> Reddit. From federated to centralized. Network effects.)

<comment><USER20> The Fediverse is federated on exactly the same layer as email. You have a username of the form user@domain,this is the same in both Mastodon and email.

You can send messages to anyone regardless of the instance they're on. This is also exactly the same on both Mastodon and email.

Precisely how are these different in any relevant way?

<comment><USER21> The fediverse has conversation streams that are mostly in public indexes, which other people can observe and interact with. In addition to these conversations comprised of statuses representing activities, it is also possible to follow the authors providing said content so that their latest posts show up in your stream, regardless of whether those posts pertained to that conversation or not.

Email, conversely, often is a limited-scope conversation that can only be observed or interacted with between the people participating in said message. Of course, this changes slightly with the use-case of mailing lists, which often provide a public archive of prior messages. But email content is generally not accessible from the web in the same manner that a status is.

<comment><USER20> Sure, but when I said "in a relevant way" I was talking about differences that are relevant in the context of the conversation.

There was nothing wrong in your description of the differences between the Fediverse and email, but none of those differences explain the previous poster's assertion that the protocols work at fundamentally different levels.

</comment></comment></comment></comment></comment></comment><comment><USER22> > _ActivityPub prevents that a social media platform becomes a silo (see > photo) that can't communicate with other platforms._

I wish that were true. In practice, server admins are more than happy to block federation with entire other domains (and all associated users, hundreds or thousands at a time) based on little more than gossip and rumor.

Imagine if email services worked this way! "subscriber@otherhost is rumored to be slightly politically oriented in a way we don't like, so we as admins have prevented everyone@thishost from mailing everyone@otherhost, and vice versa".

[https://github.com/tootsuite/mastodon/issues/12600](https://github.com/tootsuite/mastodon/issues/12600)

"the internet treats censorship like damage and something something"

I'm glad that, in practice, you can still email people who are destination- server-adjacent to users your local mailserver admin hates. (Of course, mailservers can configure to drop mail from specified MXes too—but they don't. Usually they get spam-foldered.)

PS: I'm on the fediverse at @firstname.lastname@example.com and would love more people to follow.

<comment><USER23> > In practice, server admins are more than happy to block federation with > entire other domains (and all associated users, hundreds or thousands at a > time) based on little more than gossip and rumor.

If that is easily possible this is doomed from the start, IMO.

You get into situations where you are at the mercy of a single person.

The linked issue's closing comment is even more backward. The issue opener did not asked for talking to people which do not want talk to him. Blocking between users is one thing, and can be good to have. Their issue was that the whole federate instance doesn't peers with him, out of theirs or the federated instance in questions people choice or support.

Peering needs to be done unconditionally, even over edges, IMO. Blocking needs to be in the sole control of the user, not the admin of a federation server. All else doesn't makes this better than Facebook, or any other single server instance without federation.

<comment><USER24> > You get into situations where you are at the mercy of a single person.

How is it worse than Twitter, which can also ban you?

At least on the Fediverse you can choose who that person is, and it can even be yourself if you host your own instance.

> Peering needs to be done unconditionally, even over edges, IMO.

What about instances that are mostly spam? What about instances that are dedicated to harassment (eg. Kiwifarms)?

Besides, you're free to use an instance with a block policy that aligns with your opinion.

<comment><USER23> > How is it worse than Twitter, which can also ban you?

Who said anything about twitter and worse?? Shouldn't this be better than Twitter?

> What about instances that are mostly spam? What about instances that are > dedicated to harassment (eg. Kiwifarms)?

Why is that an issue? You do not get spewed their spam in your face as long as you do not follow anybody? It has to be the users decision, anything else is doomed to be abused against users.

And if this would become an issue, and one want's to have a more drastic approach to handle bad apples a decision of the a federates instances users, i.e., a conses or quorum, needs to decide.

> you're free to use an instance with a block policy that aligns with your > opinion

No, you do not understand the basic issue here. Not only the block policy of the instance I'm on is the issue, but all the others. So how does your proposal solves this?

<comment><USER24> > Who said anything about twitter and worse?? Shouldn't this be better than > Twitter?

I personally believe the Fediverse is better than Twitter in that regard, but everyone should agree that it's at least not worse.

> a conses or quorum, needs to decide.

Some instances do that, eg. [https://social.coop/](https://social.coop/)

> So how does your proposal solves this?

I didn't make a proposal, just explained what I see as an early Mastodon user.

> Not only the block policy of the instance I'm on is the issue, but all the > others.

Again, Fediverse users choosing instances is like Twitter users choosing blocklists. If they are on an instance which blocks yours, then either:

1\. they are aware of their instance's policy, so they indirectly agree with the decision of not seeing your toots

2\. they are unaware of their instance's policy, which is a bad decision on their part.

</comment></comment></comment></comment></comment><comment><USER25> Question concerning a potential impl I'm pondering: Are there any realtime/streaming approaches with ActivityPub? Can a chat application be reasonably implemented on it today or is the inbox/outbox federation concept too limiting? Are there any examples of such services out there and how reusable/generic are their approaches?

<comment> vertex-four In the next version of my ActivityPub system which integrates chat, I'm using XMPP, with a reference to the user's XMPP JID from the user's ActivityPub actor.

The upside is that everyone can use standard XMPP clients like Dino or Gajim to chat. As I'm doing video streaming over HLS, they can also use VLC or similar to watch videos - the rest of it is then just standard ActivityPub. The web application is built on Converse.JS and Video.JS.

<comment><USER9> Hmm, doesn't HLS have built-in DRM ?

<comment> vertex-four Nope. HLS is an open standard without DRM - it's basically just an extended playlist of MPEG Transport Stream files, which the client repeatedly requests to find the next part of the stream. These can be generated with e.g. gstreamer; at the moment I'm using nginx-rtmp-module to generate them but intend to replace that with a more flexible/tailored option.

It can be used to transport streams with DRM, though, but there's nothing special about that - it'll transport anything that goes in a MPEG Transport Stream.

</comment></comment></comment></comment><comment><USER26> Why isn't Twitter using and backing ActivityPub?

It sounds pretty much what Facebook has done with login with Facebook for developers. Except that the network effects aren't controlled by 1 commercial company but is an open source effort.

<comment><USER18> Jack said he hired a team to build a NIH version of decentralized social networking.

<comment><USER27> That's misleading. They talked about considering the problem and creating a team to investigate solutions.They were clear about the fact that they would consider existing projects if they match their requirements.

<comment><USER20> And that's all we've heard about it. I think ActvityPub definitely does not match their requirements, and also, I doubt any federation system does.

I'm saying this because their primary requirement is clearly to have strict control over their own^H^H^Huser's content.

</comment></comment></comment></comment><comment><USER28> I think the truth lies between federated and p2p. Personal or at least very small instances only.

Would be cool if we could get something like remoteStorage going, but with a one-click-way of getting your personal instance up and running and also a simple way to transfer that from provider to provider.

<comment><USER29> Is remoteStorage still going? Seemed pretty dead when I evaluated it a few weeks ago, which is really unfortunate. Seems like a decent protocol.

</comment></comment><comment><USER30> I had this epiphany the other day, any distributed application was actually a messenging system. (I can hear Alan Kay scream afar). Wasn't there a project like this ? a guy making some whatsapp revolution turning it into a generic app platform ? I forgot.

<comment><USER31> You are probably thinking of Movim, which is a social network built on top of XMPP.

<comment><USER30> it was something with a simple name like nextapp

<comment><USER32> app.net

<comment><USER30> most probably, I dismissed it because it sounded too Microsofty :)

<comment><USER31> App.net has been dead for years already, are you sure that is the one?

<comment><USER30> Not entirely but so far that's the best match. Also I didn't mean something current, just that this dude pivoted a message exchange app into a generic application platform, which is what activitypub feels like (and good ol' message passing distributed programming too)

</comment></comment></comment></comment></comment></comment></comment><comment><USER33> Can anyone recommend a good and current guide on setting up and maintaining your own mastodon instance?

<comment><USER24> The official docs at [https://docs.joinmastodon.org/](https://docs.joinmastodon.org/) should do

<comment><USER33> It appears "Installing from source" is the only option?

Are there no distributions packaging mastodon and its dependencies such that I don't need to have gcc/build-essential and piles of -dev packages installed to run it?

<comment><USER24> Mastodon has hundreds of Nodejs and Ruby dependencies, so it would be a huge amount of work for distributions to package it. See [https://github.com/tootsuite/mastodon/issues/3576](https://github.com/tootsuite/mastodon/issues/3576)

FreeBSD's ports used to have Mastodon, but they gave up because it kept breaking [https://www.freshports.org/net- im/mastodon/](https://www.freshports.org/net-im/mastodon/)

You can however run Mastodon with docker, many people use the official docker- compose.yml config.

<comment><USER33> Yikes, do you know of any activitypub-compatible implementations actually packaged by distros? gnu social perhaps? diaspora?

I checked out Pleroma after seeing it mentioned on that freshports mastodon page, which seemed a bit less onerous with just the OTP component but they don't distribute an i686 build, that's unfortunately what the dusty old colo I'm looking to run this on has.

<comment><USER24> Debian Sid has Diaspora: [https://packages.debian.org/unstable/diaspora](https://packages.debian.org/unstable/diaspora) , but Diaspora doesn't support ActivityPub: [https://github.com/diaspora/diaspora/issues/7422#issuecommen...](https://github.com/diaspora/diaspora/issues/7422#issuecomment-546742655)

As for GNU Social, well... [https://wiki.debian.org/FreedomBox/Manual/GNUSocial](https://wiki.debian.org/FreedomBox/Manual/GNUSocial)

You might be interested in Yunohost, which is a Debian-based distro packaging popular server applications (also with an easy installer, aimed at non- technical people): [https://yunohost.org/](https://yunohost.org/)

<comment><USER33> > Debian Sid has Diaspora: > [https://packages.debian.org/unstable/diaspora](https://packages.debian.org/unstable/diaspora) > , but Diaspora doesn't support ActivityPub: > [https://github.com/diaspora/diaspora/issues/7422#issuecommen...](https://github.com/diaspora/diaspora/issues/7422#issuecommen..).

For posterity sake:

I just spent an hour trying to get that package happily installed in a fresh debian sid debootstrap running in nspawn and it seems to be broken. They're requiring an old 1.2.x ruby-zip version, and sid seems to only have 2.0. Even after kludging past that, things break down again on unmet sass version requirements.

So true to the 'unstable' name, this package isn't currently usable.

<comment><USER24> You may want to submit a bug report: [https://www.debian.org/Bugs/Reporting](https://www.debian.org/Bugs/Reporting)

This will more likely result in the package being removed rather than fixed, but at least someone else won't get false hope.

<comment><USER33> I emailed firstname.lastname@example.com FWIW

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER34> the rating system could be circular (by lack of beter name)

users would up and down vote things they like or not. value is them extracted from contradiction(!) if user A liked content X while B does not and user B liked Y we assume A does not like Y. with lots of fine gradients like that I assume the high noise will eventually be drowned out by the signal.

</comment><comment><USER35> I had a mastodon.social account but deleted it after the admin power tripped and started to ban instances he didn't like.

<comment><USER36> The great thing about the fediverse is if you still want to use mastodon, you can find a better instance that suits your needs, or run your own instance.

<comment><USER37> > you can find a better instance that suits your needs, or run your own > instance

I understand that this is the concept, but in practice, it's a laughable recommendation.

Accounts aren't portable and running your own instance is an insurmountable task for most and the cost of it is not nearly worth it.

<comment><USER38> you can export all of your account data, and you can host mastrodon on a raspberry pie, what are you talking about

<comment><USER39> But you can't yet import that data in your new instance and have it seamlessly continue to work from there, because your identifier obviously changed.

<comment><USER40> Moving accounts is supported; your old account posts a machine-readable "moved to x@y" message, which tells your followers to automatically switch to the new location.

[https://docs.joinmastodon.org/user/moving/](https://docs.joinmastodon.org/user/moving/)

<comment><USER39> Oh cool, missed that being added. That covers a good chunk of the issue.

</comment></comment></comment></comment></comment></comment></comment><comment><USER41> I like the idea of federated network but I'd rather see a virtual implementation.

<comment><USER42> What do you mean by virtual?</comment></comment>


Ask HN: What are some of the better tech magazines or online publications? - <AUTHOR> <comment><USER2> Though I don't read it regularly, I often find myself following links to what turn out to be good articles at Smashing Magazine. It's not exactly what I'd call a tech magazine - the focus is web development and design.

For something more broadly IT related, there is The Register. You'll have to forgive their intentionally over the top, tongue-in-cheek, british tabloid writing style (I've noticed a bit of this has rubbed off on Ars lately). If you can look past that you'll find that they do a really good job of staying up to date with industry news.

</comment><comment><AUTHOR> Some of my favorites are Technology Review and Ars Technica but I'm always open to new ones.

<comment><USER3> Ars is good for high level stuff and to get a recap of the major keynote speeches.

Technology Review is nice, but having a hard cap on the number of articles I can read per month for free is just a huge no-go though. I get the Wired approach of blocking blockers (even if that is triggered by every company firewall I have ever been behind...) as that still provides content for free. Whereas these approaches strongly encourage catering to a specific demographic which tends to drastically limit the kind of critiques and coverage.</comment></comment>


Misogyny isn't caused by male horniness - <AUTHOR> http://pandagon.net/index.php/site/misogyny-isnt-caused-by-male-horniness

<comment><USER2> Lots of good stuff there. But I take offense to the notion that all porn is directed at women. In fact the small minority is. Most of publishing is directed at women's fantasies - romance novels principal among them.

Because women like their porn as language, and men as pictures, does not prove men invented porn, or benefit more by it, or anything really.</comment>


Banking Isn't Evil: software dev's view of how banking works and what went wrong - <AUTHOR> http://www.lifebeyondfife.com/86-banking.html

<comment><USER2> We allow and expect corporations to be amoral because of Adam Smith's guiding hand: if you make a profit it's because somebody thought that your product was worth at least as much as they paid for the product, probably even more. In other words, win-win.

When a transaction isn't win-win, it's time for regulation to step in. That's why there are limitations (but not bans) on monopolies.

The most common case of a transaction not being win-win is when the information is asymmetrical. That's why selling a "pig in a poke" is illegal.

Banks and traders operate in this "asymmetrical information" grey area. Arbitrage is allowed and is useful because it brings prices to their correct level and provides liquidity to a market. But high-frequency trading is clearly not useful to society. Who cares if it takes prices 10ms or 1 second to complete a sale and get prices to the correct level? HFT takes money out of the system and provides no benefit to society or the other party, and therefore is "evil".

HFT should therefore be outlawed. But you have to be very careful. Such a law would be very difficult to write correctly, and due to the law of unintended consequences and the pace of change and the cost of regulatory burden, we're probably better off without such a law.

HFT is evil. But companies that practice HFT are simply being amoral, not immoral. So perhaps the fault lies with the government for improper regulation, not necessarily with the companies for practicing it.

HFT is only one of the 'evil' practices that banks and large investors use. The linked article touches others, some of which are 'evil' and some of which aren't.

<comment><USER3> What is the alternative to permitting HFT? If we ban direct communication between the algorithms and the exchanges, we will merely create a great deal of busywork for the thousands of people who will be hired to manually enter the orders produced by the algorithms. If we ban the use of algorithms altogether, we will be legislating inefficiency into the market, to the extent that there can be inefficiencies that are not worth the man-hours to manually discover. We may also have a hard time enforcing either of these approaches. I wonder how much it would cost us?

</comment></comment><comment><USER4> The idea that business is or should be amoral is wrong. Business, and corporations in particular, exist and have the leeway they do because it is generally believed the good outweighs the bad, on the balance. By saying "we have no reason to have any scruples" you are veering into "no longer beneficial to society on the whole" territory. While I believe there is definitely value provided by finance (duh), some things they engage in clearly are self serving and detrimental to an orderly society. Bundling toxic mortgages and selling them to people under the guise "if they're stupid enough to buy them then it's their own fault" is wrong really no matter how much one waves his hands, yells "capitalism" and tries to act like they are doing it for some legitimate reason.

<comment><AUTHOR> I don't think business _should_ be amoral but I think it is. Businesses can do great things, help charities, help their employees, reduce carbon footprints - but anytime they do any of these things they squeeze all the good press they can out of it i.e. turn it into free positive advertising.

When times are tight those are the things that businesses cut first because they are concerned solely with money. I agree with you the toxic mortgages were an appalling thing to offer people who don't understand about, say, the effects of potential raised interest rates and how that might affect them. But that's why I say businesses (all businesses) are amoral - they don't care. So if we spot a bad business practice, like the toxic mortgages, we have to understand that we're going to have to rely on either the government or ourselves as consumers to fix it because business won't stop themselves from trying to make that buck.

I'm not saying I like this being the case but that how I see it.

<comment><USER3> The profitability of unsound lending is mainly an artifact of fairly recent policy. Historically, if you were to give out loans that you knew could not be paid, you would lose money. That does not seem to be the case any more.

If you were at a casino and wanted to make money, you might go count cards at blackjack or try to beat the other gamblers at poker. But, if you knew that the casino would fully reimburse you any losses, you would probably just sit down at a roulette table and bet the house on double zero. This may or may not be an evil thing to do, but certainly it is a rational thing to do. If millions of Americans are harmed as a result of your policy of consistently betting the house on double zero, perhaps they should take it up with the casino who encourages this behavior by consistently compensating you for your losses using money taken from the pockets of millions of Americans.

</comment></comment></comment><comment><USER5> I find the writer's explanation of the main cause of the financial crisis too simplistic and dangerously naive: "interest rates were historically low which made lending cheap, [so] banks had more money to lend than there were responsible borrowers. This created a credit bubble that once over, resulted in banks suffering large monetary losses and an atmosphere of being scared to lend to each other."

IMHO, the structure and behavior of financial firms was a major destabilizing force leading to the crisis.

In the years preceding the crisis, financial firms created a vast network of complex financial claims and obligations _of their own_ that greatly exceeded the real economy's needs. These financial claims and obligations were at the center of the financial crisis.

A recent working paper at the Bank of International Settlements shows that financial flows exceeded the real economy's needs by a factor of at least 60 (!): <http://www.bis.org/publ/work346.pdf> \-- an irreverent translation of the paper in easy-to-understand lay language is available here: [http://www.nakedcapitalism.com/2011/09/the-very-important- an...](http://www.nakedcapitalism.com/2011/09/the-very-important-and-of- course-blacklisted-bis-paper-about-the-crisis.html) .

Instead of just providing a mundane but critical service to the real economy (interconnecting the real economy's savers with its borrowers), the financial system was _driving_ the real economy – for instance, by pushing up the prices of many assets, particularly residential properties, simultaneously feeding on and magnifying a housing bubble of historic proportions.

IMHO, these nonlinear feedback loops and network-amplification effects -- typical of complex, tightly interconnected, dynamic systems -- were important root causes.

</comment><comment><USER6> One the thing that is missing in the discussion of whether banks are evil or not is a better dichotomy: what he describes in this entry is primarily about transaction banking (and more particularly cash management), which one can argue is not evil as it allows for the free flow of capital through the financial system.

On the other hand, when banks start trading against their own book (ie. creating financial transactions that are used to leverage the bank's own money), then things can go wrong.

Ultimately, what failed in this crisis is that 1\. The risk around mortgage distribution got to be so removed from the actual mortgages that it increased carelessness. 2\. Confidence in the system was shaken, leading to a "run on the bank" for broker-dealer banks, creating a substantial crisis of confidence in the banking system as a whole.

Anyone interested in how the crisis came about should read "The Big Short", by Michael Lewis, and "Too Big to Fail" by Andrew Ross Sorkin. Those two books provide a lot of perspective on what happened in the months leading up to and the days during the crisis.

<comment><USER3> I'm not sure that "crisis of confidence" is the right turn of phrase in a situation in which there was a real lack of ability to pay. If there is a "crisis of confidence" and an institution's balance sheet is actually as it says it is, it can wait until people start behaving rationally. If there is a "crisis of being materially insolvent," and its own solvency is dependent on the solvency of counterparties who are materially insolvent, then it is not a victim of a lack of confidence as much as a victim of its own lack of diligence. Perhaps if the institution is sufficiently sophisticated then we should consider the possibility that it knew that its counterparties could not pay and lied about that knowledge.

</comment></comment><comment><AUTHOR> Apparently this blog post reminded a friend of mine about an article he read in the nineties called The Hybrid Manager. Essentially, we as developers love technology as it really interests us. But unless we're writing tools to aid development we need to understand at least one other business i.e. the business we write code for.

I don't think enough coders know how the high-end financial world works or what opportunities and interesting work it has. More computer scientists in my industry please, we need your pragmatism!

</comment><comment><USER7> I read the entire thing and not once did the author even touch CDSs or even where the banks got 40 trillion dollars from[1].

Most people don't believe banks are inherently evil. Just in this case in the last decade they spent so much time screwing each other they ended up screwing every one of us.

[1] For those that don't know, from 2000 until 2008 the global money supply went from 36 trillion to over 70 trillion. Listen to NPRs "Giant Pool of Money"</comment>


What being a journalist in the Middle East taught me about how censorship works - <AUTHOR> http://www.vox.com/2016/2/18/10887776/middle-east-censorship <comment><USER2> Fascinating and practical look at the concept and actual execution of censorship. Honestly I can relate quite a bit, having worked in Fortune-level business (with a similar Rule #1 which could be called "Never admit a company weakness") but there must be a lot more fear involved when the basic stakes are as high as the article describes - as in, freedom of movement. I think this type of reporting is helpful. Censored journalists or ones trying to curry favor (Tiger Woods) or ones just being inexcusably lazy or incompetent (Iraq War run-up) aren't really journalists, and that's unfortunate because they do a lot of significant public service.

</comment><comment><USER3> Censorship, unfortunatey, happens even at the places you wouldn't associate with censorship.</comment>


If You Love Something, Set It Sort-Of Free: Condé Nast Mulling Reddit Spin-Off - <AUTHOR> http://mediamemo.allthingsd.com/20110321/if-you-love-something-set-it-sort-of-free-cond-nast-mulling-reddit-spin-off/

<comment><USER2> Straight from jedberg's mouth: "This article is a complete fabrication. He should be ashamed to call himself a journalist."

[http://www.reddit.com/r/reddit.com/comments/g8ht8/cond%C3%A9...](http://www.reddit.com/r/reddit.com/comments/g8ht8/cond%C3%A9_nast_mulling_reddit_spinoff/c1lpgz7)</comment>


Learning to Program - <AUTHOR> http://lenz.unl.edu/2012/06/10/learning-to-program.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+StephenRamsay+%28Stephen+Ramsay%29

<comment><USER2> Boom, nailed it.

What a joy to read, this article was.</comment>


DOMA is unconstitutional - <AUTHOR> http://www.scotusblog.com/

<comment><AUTHOR> Link to the opinion: [http://www.supremecourt.gov/opinions/12pdf/12-307_g2bh.pdf](http://www.supremecourt.gov/opinions/12pdf/12-307_g2bh.pdf)</comment>


Technology moves fast, art slower. - <AUTHOR> http://www.nytimes.com/2010/04/27/arts/design/27muybridge.html <comment><USER2> Of course. Bach, Shakespeare, and Michelangelo can hold their own with the best that have ever existed.

</comment><comment><USER3> How fast technology moves depends on how you look at it ...

<comment><USER4> The exponential growth of technology we have experienced in recent decades (WWII+) would lead us to believe that technology is indeed advancing at a very fast rate. I think most people especially adults and young adults can relate to the fast advancement of technology.

P.S. I still remember dial-up (not that my current DSL service is all that better).</comment></comment>


Typing The Letters A-E-S Into Your Code? You're Doing It Wrong - <AUTHOR> http://www.matasano.com/log/1749/typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/ <comment><USER2> It's probably worth pointing out: you have the same problems if you're using CFB, OFB, or CTR mode (these are the "stream cipher" modes for DES/AES/whatever that encrypt one byte at a time). There's apocrypha about these modes not being vulnerable to the attack. Bad apocrypha:

Set up an encryptor:

      irb> e = OpenSSL::Cipher::Cipher.new('aes-256-ofb')
      => #<OpenSSL::Cipher::Cipher:0x647100>
      irb> e.key = "\x11" * 32
      irb> e.iv = "\x00" * 16

A decryptor:

      irb> d = OpenSSL::Cipher::Cipher.new('aes-256-ofb')
      => #<OpenSSL::Cipher::Cipher:0x647120>
      irb> d.decrypt
      irb> d.key = "\x11" * 32
      irb> d.iv = "\x00" * 16

Encrypt something:

      irb> ciphertext = (e << "A * 40")
      => "a\255N\211XEn\001\347$\275)\311%Ht\2356\254m\b\234z\375\311\006\335\305F\231~\201\243\236\3628w\267\3454"

Make an XOR mask:

      irb> mask = ("187 she wrote".to_bignum ^ ("A" * 13).to_bignum).to_rawstring
      => "pyva2)$a63.5$"

XOR it into the ciphertext:

      irb> new_ciphertext = (ciphertext.to_bignum ^ mask.to_bignum).to_rawstring

NOW decrypt it:

      irb> d << nct
      => "AAAAAAAAAAAAAAAAAAAAAAAAAAA187 she wrote"

</comment><comment><USER2> Hm. I wrote this for our normal blog readers, who live and breathe security stuff, so I don't know how well it'll carry here.

<comment><USER3> You blogged the shit outta that post!

Definitely an interesting read even for crypto dilettantes. Perhaps, _especially_ for crypto dilettantes.

I took Rivest's Computer and Network Security class in college and the most important takeaway for me, far outstripping all of the interesting technical content, was "Don't implement crypto."

<comment><USER2> Man, you had "don't implement crypto" and I was all, that kicks ass. Then you edited it to say "in general", and now I'm sad.

<comment><USER3> Ha! Good point. Edit undone. :)

</comment></comment></comment></comment><comment><USER4> I didn't buy the GPG/TLS thing before. After reading this I do. I just realized how completely out of my depth I am for crypto stuff. At least now I know ...

</comment><comment><USER5> Great post! I'd love to see more of this kind of thing; approachable explanations of the right way to do security and how easy it is to do it wrong.

Unfortunately, there's seems to be a _huge_ gap between the average working programmer, who often has little idea how to do security, and the security guru's who are often barely intelligible to the rest of us. :-)

Sadly, the result of most programmer's poor understanding of security is even worse than the bad crypto implementation in the article. It's often something as basic as thinking it's O.K. to store user passwords un-hashed. (<http://news.ycombinator.com/item?id=628680>)

</comment><comment><USER6> Is there a shorthand name for "the industry standard answer; the cookie both apps honor to let you in, encrypted so users can't change their account to someone else's" pattern, especially that pattern 'done right'?

What's the best battle-tested library (and call) for implementing exactly that, without making any of the common mistakes?

<comment><USER7> yeah I think the standard answer is "don't store credentials i the cookie". session key only and central session storage.

<comment><USER2> That works great when apps can find each other, talk directly to each other, or share storage.

</comment></comment></comment><comment><USER2> I would just like to point out that in 13 hours nobody has posted a comment here that even bothered me a little, whereas it took less than 3 hours for Reddit to bust out the one-time pads.

</comment><comment><USER8> Thanks, Thomas. I just finished implementing my own crypto in a webapp I am working on. (AES, with Diffie Hellman for a shared secret we needed)

You've made me so nervous about everything I thought was true that I did a hg revert and am looking at gpgme bindings.

You've done a good deed, I think.

<comment><USER2> Diffie Hellman is also remarkably easy to screw up. Here's an old post of mine I don't think ever made it on to Hacker News:

[http://www.matasano.com/log/962/adam-bozanovich-did-not- unco...](http://www.matasano.com/log/962/adam-bozanovich-did-not-uncover-an- nsa-ipsec-conspiracy-diffie-hellman-parameter-validation-explained/)

<comment><USER9> Off topic of the main thread, but isn't the attack mentioned in that post still problematic if you can't reliably act as a MITM for a whole session, but you can disrupt the session long enough to confuse both sides into agreeing on an insecure session key?

<comment><USER2> If you can manipulate a DH exchange, you definitely have bigger problems than forgetting to check DH parameters. It's worth noting that DH is one of those crypto building blocks that by itself provides basically no security (for instance, DH in SSL/TLS is secure because it's backed by an RSA trust anchor). It's just a tool for making other crypto primitives more flexible.

<comment><USER9> Agreed. Still, I can't decipher the IKE spec, but does it really prevent this - i.e. do any of the other building blocks actually prevent the conversation from continuing using a compromised shared key?

</comment></comment></comment></comment></comment><comment><USER10> Good read. +1 for Louis CK reference.

A question to start up founders: How do you guys handle security? Do you hire consultants/pen-testers? Do you just copy+paste code from the internet? Do you use whatever framework's components for it?

<comment><USER2> <http://news.ycombinator.com/item?id=638531>

Gotta love putting a lot of effort into an HN comment thread on a submission that ends up flagged. =)

</comment></comment><comment><USER11> _A "young, cool-people's" coffee shop on the first floor of an old office building in downtown Chicago._

A place like this exists? All I can think of is Intelligensia.

<comment><USER2> It's a Louis CK bit, and an inside joke because the bit does match up with Intelligentsia (there's actually one of those in LA, where LCK wrote the bit, so I've always wondered).

Our office is in fact a few floors up from the Intelligentsia in the Monadnock building.

<comment><USER11> Very cool. I have always wanted to start a Haskell consultancy and run it out of that building ;)

<comment><USER2> Joking about names aside: highly recommend this building. Lots of cheap offices --- incl. some very small ones --- and the building itself is gorgeous inside and out.

</comment></comment></comment></comment><comment><USER12> It seems kind of silly to write one's own code for anything, if you have access to a well-tested library that does what you want. The only reason to do otherwise is where there is no such library. Crypto is just an example of an area that's particularly hard to get right: the solution is no different than for other things.

<comment><USER2> The problem is everyone thinks they have a library that does crypto for them --- OpenSSL or CryptoAPI. But that's not what they have. They have the moral equivalent of a small pebble bed reactor, and they're strapping it to the tops of their electric cars and hoping to go for a drive.

Keyczar and cryptlib are two libraries that offer a high-level interface that is deliberately hard to screw up. But Google Keyczar is very new (it recently had a really horrible flaw) and cryptlib is not free unless you GPL your code.

<comment><USER12> Yes; I should've specified that you should use the highest-level well-tested library that does what you want. The libs you listed (in the blog post) are definitely best-in-class for that purpose.

</comment></comment></comment><comment><USER13> It was a nice read, but the screenplay delivery added a lot of confusion that I felt detracted from the point of the actual message. Maybe if it hadn't been so fragmented. Still, educational, though moderately confusing.

<comment><USER2> So I wrote out a straight prose version of this post, and even after a second draft it came out 40% longer and as dry and dense as melba toast.

But I actually kind of agree (at the very least, it's visually noisier than the prose wall of text). There's a backstory to this; I haven't blogged in almost a year, and my most infamous blog post from before that was also a screenplay, so doing this post in this style was also an in-joke:

<http://www.matasano.com/log/248/metafuzzing/>

(This post is funnier than today's post).

I'm sure you're glad you know this now.

<comment><USER14> great post. on the readability - i think the screenplay makes it more approachable but the visual formatting makes it rather hard to read. It seems like the slightly shortened, indented lines that run into the hard vertical line on the right, combined with the center aligned names, disrupts the eye flow. my eyes are drawn immediately to the center/end of line because that's where the most tension is but that's not where the line begins. i found the hex dumps to be the easiest part for my eyes to latch on to because it felt consistent.

all that is a long way of saying, in spite of the visual formatting, it's a very interesting article. and personally, i think the the screenplay itself works.

<comment><USER2> Thanks for the feedback! I thought the same thing; I think I'll mod my hacked- up version of Markdown to dim the center lines.

</comment></comment></comment></comment><comment><USER15> Isn't the whole problem in this situation that you are trusting the client with critical data? He takes possession of it, has unlimited time and opportunity to work on it, and successful falsification will be obvious for him? Why on earth trust the client with the data in the first place? I have never liked the "encrypted cookie" way of handling session storage.

Just have a server side session store and all of this cookie encryption crap just vanishes. Of course that won't help you with session fixation etc, but the post doesn't address that stuff either. Do it over TLS and you're pretty safe though.

And let's not forget the author's suggestion to pad out the cookie with 1000 bytes to make it harder to falsify. That cookie gets send with every single request. 20 images on the page, you're sending 20KB of junk up just to load the page. On a connection with slow upstream, like say ADSL, you can easily add a second or two of request latency. You might not care but some people sure do.

And come on, I read until the very end expecting to hear what "processes or threads" have to do with security, so tell us already!

<comment><USER2> I don't think you read this post carefully. The "padding out the cookie with 1000 bytes" thing is what an attacker does to break your cookie. The "processes or threads" thing is a very cryptic in-joke. Sorry. Like I said, there are aspects of this post I didn't think would carry over to HN (actually, I didn't think any of it would).

</comment></comment><comment><USER16> So, is there much to be gained from encryption anyway? If, as the candidate, I suggested sending a cookie as 'userId=39493&role=user&timestamp=1414919&hash=<sha256-of-key-with-data>' then would I lose brownie points?

I assume my hash comparison function is constant time (eg. XOR(a[x],b[x])==0), rather than comparing of char-by-char.

<comment><USER17> > hash=<sha256-of-key-with-data>

Oops, you invented your own keyed MAC and now I can append any data I want.

<comment><USER16> Sorry, I would really be using a proper RFC 2104 HMAC implementation (eg. python's hmac module).

</comment></comment></comment><comment><USER18> I always try to espouse the benefits of triple-rot13 as the cipher in interview questions about security. Key management is a breeze, for example, and it's VERY fast.

But it allows everyone to concentrate on how you're managing the secure context instead of what algorithm has been shown to cause cancer in rats.

</comment><comment><USER19> I don't understand what's so hard about encryption. There are simple, well- known rules (except the timing one that is sort of news), and if you follow them you should be safe, no?

1\. Use a blocks-size unique prefix (IV) for each message (random will do as well)

2\. SHA-256 your entire message before encryption and add the hash value at the end to prevent tampering

3\. Use AES-256 with chaining to encrypt

4\. Use SHA-256 to turn a password into a key. If your key space is small harden it with hashing 1000 times or so.

5\. The time your algorithm takes should be always the same (or at worst one time for success and one for failure)

6\. Don't use any other symmteric crypto algorithm.

<comment><USER2> Almost everything you wrote just now has problems.

1\. Has a well-known problem, which is why "Practical" suggests using a nonce.

2\. SHA-256'ing a known plaintext doesn't authenticate a messge. In fact, even simply taking a secret key and appending it to your message before you SHA-256 the message isn't secure; there's a reason HMAC is as complicated as it is.

3\. This whole blog post was about things that go wrong with CBC mode. For instance, nothing you wrote addressed padding checks --- btw, not strictly a "timing" attack.

4\. Using a password as a crypto key is bad for reasons illustrated in the post, which is why secure keystores use random bytes. Hashing 1000 times has nothing to do with your key space.

5\. This is like saying "your algorithm should be secure". Easy to say.

6\. Everything we're talking about going wrong goes wrong even when you're using AES.

So, yes, I believe you don't understand what's so hard about encryption. You're obviously smart and you've taken some time with this material, and I still don't believe you'd get this right in your first fielded version.

<comment><USER19> I am not advocating usage of passwords for encryption, I am saying that if you have to use passwords, this is how you use them. Obviously a strong random bytestring is the best key one could possibly have and should be used when possible.

Anyways, re padding - what if I hash the padding as well? surely an attacker would not get anything of value by playing with it?

Thanks

<comment><USER2> <http://www.isg.rhul.ac.uk/~kp/padding.pdf>

</comment></comment></comment></comment><comment><USER20> Great post, not that I can claim to understand all of it. One question:

 _Just put a "for" loop around SHA-1 and run it 1000 times to generate the key; that'll at least slow down a brute force attack. SHA-1 is lightning fast. By itself, it's a crappy way to generate a key._

I see the purpose of this, but doesn't it also provide 999 more opportunities for a hash collision to happen? Are you so confident in the collision resistance of SHA-1 that this isn't an issue?

My (probably naive) proposal would be to keep the result of the first hash and XOR it with the result of each subsequent hash. Bad idea?

<comment><USER21> As far as I can tell, you're confusing collisions with cycles. I don't think any of the main cryptographic hashes have problems with short cycles.

<comment><USER20> I could well be confusing the two, because I'm not sure if I even know what cycles are :-). I'm guessing from the name that cycles are when h(h(h(... h(a)))) = a? That's not quite what I'm getting at.

I'll try explaining my concern a little better. Suppose you have a hash function h. Let p be the probability that h(x) == h(y) for any unique x and y.

Now suppose you have some arbitrary inputs a and b.

      h(a) = h(b) with probability p
      h(h(a)) = h(h(b)) with probability 2p
      h(h(h(a))) = h(h(h(b))) with probability 3p
      etc.

The probability at each step increases because a collision is possible at each step, but a collision in a previous step _guarantees_ a collision in the current one.

With a good hash function, p should be astronomically low, so I guess that's why it isn't a problem in this case? Or am I completely off-base in my assumptions?

<comment><USER21> I see what you mean now. And your intuition on cycles was spot-on.

And to answer your question (I'm not a crypto expert, so take with a pinch of salt):

With SHA-1, that probability is generally accepted to be 2^(-160). 1000 is roughly 2^10, so the final probability is about 2^(-150). I guess that's still improbable enough...

But I think you do make a very valid and interesting point.

<comment><USER2> The loop has nothing to do with the probability of a collision. If your key comes out of /usr/share/dict/words, you have a 2^18 search space, not a 2^160 space. If you have a 2^18 search space, you better hope your constant factors are very high. Hence the loop.

<comment><USER20> Yeah, I get why the loop is there. But I still think it increases the probability of a collision by nearly 1000x over the probability of a collision without the loop.

Maybe a better way to explain my concern is to consider hashing something once versus twice, rather than 1000 times.

Let h be a hash function and p be the probability P(h(x) = h(y)) for randomly chosen x and y.

Say you have unique inputs a and b.

Obviously, P(h(a) = h(b)) = p.

Now consider P(h(h(a)) = h(h(b))). h(h(a)) = h(h(b)) if:

      h(a) = h(b) [probability p]
         OR
      h(a) != h(b) [probability 1-p], and
      h(h(a)) = h(h(b)) [probability p].

So the total probability when we repeat the hash is p + (1-p) * p

Since p is small, the probability of a collision has nearly doubled just by applying the hash function again.

[note: Higher up in this thread I mistakenly implied that the probability increased linearly. With a low number of iterations and realistic values for p it should be close to linear, but not exact.]

[edit:formatting]

<comment><USER2> H(m) -> SHA1(SHA1(m)) is not the same hash function as H(m) -> SHA1(m).

<comment><USER20> Right, but if SHA1(m) = SHA1(n), then SHA1(SHA1(m)) = SHA1(SHA1(n)) also.

The converse is not true. There will be cases where SHA1(SHA1(m)) = SHA1(SHA1(n)), but SHA1(m) != SHA1(n). (Or does SHA1 somehow guarantee that this will not happen?)

So it seems to follow that the chances that H(a) = H(b) when H(m) -> SHA1(SHA1(m)) must be higher than when H(m) -> SHA1(m).

Am I missing something?

<comment><USER2> I think you're going to need to better explain the logic behind graf 2 before I can answer you.

But on the off chance that we can end this thread gracefully, I'll point out that SHA256(SHA(256(m), m) is SHAd256(m), and considered by Ferguson to address security concerns in straight SHA256.

<comment><USER20> It boils down to this:

If SHA1(n) = SHA1(m), _we know_ SHA1(SHA1(n)) = SHA1(SHA1(m)). (this is a consequence of SHA1 being deterministic)

Also, even if SHA1(n) != SHA1(m), there is _still a chance_ that SHA1(SHA1(n)) = SHA1(SHA1(m)). (this is a consequence of collisions: SHA1(a) may equal SHA1(b) even if a != b.)

So the probability that SHA1(SHA1(n)) = SHA1(SHA1(m)) must be more than the probability that SHA1(n) = SHA1(m).

<comment><USER2> You realize that despite the fact that I still don't follow the logic here, SHA collisions have no meaningful impact on the security of PBKDF, right?

<comment><USER20> Actually I didn't, but that more or less answers my original question. Now I realize why you (or rather, your character) said that it didn't matter that md5 is broken in this case.

In general though, I'm still convinced that putting a hash function in a loop will increase the probability of a collision.

Or maybe I misunderstood your point about the loop? I assume by putting a loop around the hash you mean something like this:

      key = SHA1(password)
      1000 times do
        key = SHA1(key)
      return key

<comment><USER2> Look I don't want to be dense here --- and there's a good chance that's exactly what's happening --- but it sounds to me like you're talking about collisions between SHA1, SHA1(SHA1), SHA1(SHA1(SHA1)), etc.

Rename the functions. SHA1(SHA1) is now SHA1', SHA1(SHA1(SHA1)) is now SHA1''.

Explain why I care if there's an m and an n such that SHA1'(m) = SHA1''(n)?

They're two different hash functions.

<comment><USER22> No, you're still missing the point :)

He's saying that SHA1'(m) = SHA1'(n) implies that SHA1"(m) = SHA1"(n).

Let's do this with a very simple, silly hash function.

Let h(x) = (x/2)%10 (in integer arithmetic, e.g, 5/2 = 2, so h(5) = (5/2)%10 = 2%10 = 2.) So then let h2(x) = h(h(x)) = (h(x)/2)%10, and h3(x) = h(h(h(x))) = (h2(x)/2) % 10.

Here's a table:

      x:  h  h2  h3
      0   0  0   0
      1   0  0   0
      2   1  0   0
      3   1  0   0
      4   2  1   0
      5   2  1   0
      6   3  1   0
      7   3  1   0
      8   4  2   1
      9   4  2   1
      10  5  2   1
      11  5  2   1
      12  6  3   1
      13  6  3   1
      14  7  3   1
      15  7  3   1
      16  8  4   2
      17  8  4   2
      18  9  4   2
      19  9  4   2
      20  0  0   0
      21  0  0   0
      ...

Hopefully this table shows that collisions are much more likely for h2 than for h, and more likely for h3 than for h2. The range of h3 is smaller than the range of h2 which is smaller than the range of h.

<comment><USER20> Right, that's what I had in mind.

Of course, it's a bit of a jump to assume that the result is the same when you use a cryptographic hash function instead of a trivial one.

But regardless of the hash function, the same problem will occur unless there are no collisions for input between 0 and 2^160 - 1 (inclusive). From what I can tell, SHA1 can't guarantee this.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> Related to this: <http://www.codinghorror.com/blog/archives/001267.html> I assume.

<comment><USER24> Perhaps... A comment on that article: <http://news.ycombinator.com/item?id=615209>

Is the "AES" line a tptacek catchphrase? Or is he quoting someone else?

<comment><USER2> It's a me catch-phrase. I am like Poochie that way.

</comment></comment></comment><comment><USER25> As far as doing it wrong can we go back to "app 'A' set a cookie with your account ID in it" and discuss why on Earth the app works like that???

<comment><USER2> Because app A and app B can't share state directly, and can't talk directly to each other? You're basically asking why federation and single sign-on exist.</comment></comment>


Is Bootstrapping Becoming Sexy Again? - <AUTHOR> http://www.sramanamitra.com/2007/03/09/is-bootstrapping-becoming-sexy-again/ <comment><USER2> Bootstrapping is always sexy.

Revenue and profits are becoming sexy again. Hopefully dividends too.

<comment><USER3> Dividends for who? Startup investors? Even conservative/revenue-centric startups have a staggering failure rate. What kind of dividends would be necessary for surviving startups? i.e. I invest $100,000 each in 10 scrappy/revenue-centric startups. 6 die or fail to generate meaningful profit (a much better rate because they aren't "swing-for-the-fences" startups). What sort of dividends would the other 4 have to produce to seem appealing to an investor to compensate for the fact that $600k is lost forever and $400k more is sunk into the survivors. I'd love someone to lay down some math that would make investors say, "Wow-- dividends ARE sexy!"... Any takers?

If you mean traded stock dividends, then nevermind. ;-)

<comment><USER2> I meant traded stocks, as many companies who issue dividends are trading at historic lows. Makes for good yields.

Depending on the situation it could bode well for some startups...

Also, sometimes there's no where else to invest profits (within the Company) without expanding outside of what you're good at (I think MBAs call this core competencies).

</comment></comment></comment><comment><USER4> _"Gone are the days when entrepreneurs boasted at cocktail parties"_

Surely there is at least some negative correlation between "Good Ideas" and "Things Boasted at Cocktail Parties." The mythical (and hypothetical) cocktail party that pops up in everyone's mind once and a while is always a block on logical thinking.

</comment><comment><USER5> Bootstrapping was never sexy. It's not sexy now. What's going on is that most VC firms have no idea how to actually identify themes or teams in which to invest and times like this expose them.

Unlike Dan, I'd love to get funding, even as we have a revenue model that doesn't require scale to get profitability. What VC funding does is dual risk mitigation - money reduces my personal risk of paying the bills and the very _act_ of investing in the company makes the opportunity less risky by providing a cushion to try and make a few mistakes. I am, and most entrepreneurs, are grateful to bear less risk so that they can focus on making a great product.

At the end of the day, however, I'm well aware that eBay didn't need a dime of the Benchmark money they took, and that allows me to say no to the scrubs that come a-knocking.

</comment><comment><USER6> My abundance of ramen noodles, lack of $$$ to take girls out on dates and bulging belly from giving up the gym membership all point to "no" on the "sexy" question.

<comment><USER7> go outside and run. works wonders.

<comment><USER6> I do when I can. City sidewalks wreak havok on the knees etc.

<comment><USER8> Bike!

</comment></comment></comment></comment><comment><USER9> It's nice to own 100% of your company and turn a profit, especially given the current economy, but you really need to have faith in the 'less is better' philosophy.

The pace of development feels excruciatingly slow when you have to multitask on everything. I sometimes wish I had someone's else millions to speed things up a bit.

<comment><USER10> Try not being a developer and having no movement at all. Having some money to pay a programmer would be nice ;)

<comment><USER9> we only have developers

</comment></comment></comment><comment><USER11> Out of all the people that have filtered through the Hackers and Founders Meetup this past year, the only people that I know of that took funding were the 2 Y Combinator companies we had speak at an event last fall.

As far as I know, only one member has been actively looking for funding for an enterprise app. It may be selection bias. But, the rest of us are bootstrapping.

</comment><comment><USER12> March 9 2007?

</comment><comment><USER13> It really surprises me how many companies seek VC funding. I can't imagine giving away part of my business.

I understand that for some businesses to work they need to start off big, but IMHO loads of YC and other VC backed businesses just aren't in that boat.

Maybe I'm a different kind of business person though. My goal is to build a small business that will sustain me and my family and get me out of the office grind - seems like a much more realistic and attainable goal than the "go big and exit with millions" strategy :)</comment>


Replacing JQuery with Vue.js: No Build Step Necessary - <AUTHOR> https://www.smashingmagazine.com/2018/02/jquery-vue-javascript/ <comment><USER2> This is one of my favorite "features" of Vue. The system is built on straightforward JavaScript such that it works equally well in the simple, old way of just including a script tag and having all your code in the DOM, as it does with all the bells and whistles of modern build systems.

You can use a plain Vue object as a message bus, event emitter, or a simple reactive data container without any template or visual logic involved. It's a damned useful primitive to add to your toolbox.

I've found that Vue's documentation and api are clear, consistent, and well- reasoned. The core system is a set of primitives that cover about everything you would want in a web app, you can easily pick and choose just the pieces you want but they also work perfectly in the fashion of a much heavier framework if you decide to use them all together.

This is about the best open source project I've ever used. Highly recommended for anyone who is curious about it, and hats off to Evan You and the whole team for what they've built.

<comment><USER3> > I've found that Vue's documentation and api are clear, consistent, and well- > reasoned

I know right ? Everytime I have a question, I just keep reading, and it's right in the next parts. It feels like getting in a tutorial with a friend.

</comment></comment><comment><USER4> Nicely done. This is a must read for anyone stuck in "manual DOM querying and manipulation land" with jQuery looking to level-up using Vue.js as an excellent alternative.

By the time I got to the 2nd code example in this article, I was already rolling my eyes at the old jQuery approach I used for years: "Wait, is it .val() or .text() to pull the "value" out of that element?"(1)

Web devs who give Vue.js a try have to come away with a smile on their face. Sure, they may prefer React or Angular for a variety of reasons, such as team size. But Vue.js just makes it so darn easy to get started. It definitely helps to "progressively" adopt modern, model-driven approaches to web apps.

(1) [https://stackoverflow.com/questions/807867/difference- betwee...](https://stackoverflow.com/questions/807867/difference-between-val- and-text)

</comment><comment><USER5> While this is certainly good to get started, it's definitely worth transitioning to a build-based process if for no other reason that components ran through vue-loader or vueify gets precompiled into render functions, so you get both speed and file size savings. This is a great guide for those investigating different options or those not comfortable with Webpack though.

All our new front end stuff uses Vue.js now, and we've been very happy with it. No more unmaintable jQuery nightmares and much greater reusability, which goes even further when you throw renderless components into the mix.

It does have one or two rough spots; for example passing events up more than two levels gets messy quickly unless you use Vuex (sometimes overkill) or a global event bus (works but feels quite hacky), but by and large it's a very nice library, and certainly seems easier to get started with than something like React.

</comment><comment><USER6> I wouldn't mind a build tool if it didn't require a ton of JavaScript files _(looking at you Babel.js)_.

Recently I had to start a new project and decided to use Go for the back-end and Vue.js for the front-end, but I was concerned about all the tooling that I would need to integrate just to power the front-end side of the website. More so considering that my employer's business has nothing to do with web development so all this overhead would be unjustifiable. I spent several days reading and trying to understand what every tool included by Babel.js was doing until I gave up after the +20th module. It felt like a nightmare to see the gigantic dependency tree inside the "node_modules" folder.

I felt relieved when I found that Vue.js Components don't need to be compiled [1].

I also found this article interesting [2] with information on different approaches.

This is what I ended up with _(my own design)_ :

        /project/
        ├── docker-compose.yml
        ├── Dockerfile
        ├── README.md
        ├── backend
        │   ├── about.go
        │   ├── app.go
        │   ├── home.go
        │   ├── main.go
        └── frontend
            ├── public
            │   ├── app.min.js
            │   ├── bootstrap.min.css
            │   ├── favicon.ico
            │   ├── about.min.js
            │   ├── styles.min.css
            │   ├── vue.min.js
            │   └── vue-res.min.js
            └── views
                ├── base.html.tpl
                ├── home.html.tpl
                └── about.html.tpl

Where "app.min.js" contains the basic Vue.js options like this:

        var Application = function() {};
        Application.prototype.el = '#app';
        Application.prototype.delimiters = ['${', '}'];
        Application.prototype.data = {};
        Application.prototype.created = function() {};
        Application.prototype.methods = {};

And the sub-sequent pages, like "About", load a JavaScript file with this:

        Vue.component('about', {
            template: '#about',
            data: function() {
                return {…};
            },
            methods: {…}
        });

[1] [https://vuejs.org/v2/guide/components.html](https://vuejs.org/v2/guide/components.html)

[2] [https://medium.com/js-dojo/7-ways-to-define-a-component- temp...](https://medium.com/js-dojo/7-ways-to-define-a-component-template-in- vuejs-c04e0c72900d)

<comment><USER7> You should check out the vue cli.

<comment><USER6> I already tried it, but it also depends on Babel.js [1].

Here is the dependency tree upon installation [2] 144M in total.

I just created a fresh project with it, and the directory is now 134M and I just selected Eslint + Prettier for linting and formatting. I don't want to know how big the project would be if I were to choose the other available options _(Router, Vuex, Babel, etc)_. This week I spent 1-2 hours designing a lightweight project structure to use Vue.js components without the build tool, it worked pretty well and it does what I need it to do, which is simply DOM binding, Ajax requests, and minimal templating because the rest is already handled by the back-end in Go.

[1] [https://github.com/vuejs/vue- cli/blob/3193b0d/package.json#L...](https://github.com/vuejs/vue- cli/blob/3193b0d/package.json#L44-L61)

[2] [https://pastebin.com/raw/x3kJ91xP](https://pastebin.com/raw/x3kJ91xP)

<comment><USER8> But you don't have to commit or deploy the dependencies right? It's just that size for the build isn't it?

<comment><USER6> > But you don't have to commit or deploy the dependencies right?

Yes, I have, otherwise I will impose Node.js + NPM as a dependency for my co- workers who — again — are not web developers, they just want to quickly modify one or two things and deploy without my involvement, so I have to build something as standalone as possible, this means _(in this and other projects)_ that I have to commit the whole "node_modules" folder with the rest of the files.

And if anyone thinks this is a weird requirement, I can tell you that last year I did some contractor work in four web agencies in San Francisco, and they all had a policy of _" commit all the dependencies"_ because they wanted to "lock" the files to a specific version. They used to lock the dependencies using the "package.json" file, but after all the recent fiascos with NPM and their registry, they stopping relying on the constant download of these files during every deployment, something that we were considering even before the problems with NPM because downloading +200M of files for every execution of the test suite in the CI server was posing a significant cost for not reason.

If NPM and their registry were more stable, I would just put everything in the "package.json" file and ignore the +100M of code in the dependency tree, but unfortunately, the Node.js is voting for a different philosophy that has been biting them for several years now, they still haven't learnt the lesson.

<comment><USER9> Committing your node_modules folder is definitely a bad idea. To me, the right answer is to use Yarn's "offline mirror" feature to cache the package tarballs themselves in your repo. They're smaller, it's a lot fewer files, and it's platform independent.

</comment></comment></comment></comment></comment></comment><comment><USER10> JQuery is often used in popular front end components, like carousels and menus.

How do you approach something like slickjs? Or SmartMenus? Both of these are quite polished, with well thought-out APIs, and have solved for hundreds of issues and corner cases.

I'm not sure that it would be wise to go for a DIY solution in such cases.

What's your experience?

<comment><USER11> I've always just looked for one that doesn't use jQuery. Haven't had trouble finding one for at least a year. Nowadays I always find there's already a Vue component that's a wrapper for whatever library.

</comment></comment><comment><USER12> Related from yesterday: [https://news.ycombinator.com/item?id=17211283](https://news.ycombinator.com/item?id=17211283)

</comment><comment><USER13> Been doing this a lot for toy projects, or when I work with server side application frameworks like rails and phoenix.

</comment><comment><USER14> Can someone please please please explain Vue to me?

Sounds like the next iteration of Backbone / Ember / etc frameworks.

Vs

React and Angular2 = Dom Diffing.

<comment><USER6> • [Vue.js] Comparison with Other Frameworks [1]

• ReactJS vs Angular5 vs Vue.js — What to choose in 2018? [2]

• Angular 5 vs. React vs. Vue [3]

• Angular vs. React vs. Vue: A 2017 comparison [4]

[1] [https://vuejs.org/v2/guide/comparison.html](https://vuejs.org/v2/guide/comparison.html)

[2] [https://medium.com/@TechMagic/reactjs-vs-angular5-vs-vue- js-...](https://medium.com/@TechMagic/reactjs-vs-angular5-vs-vue-js-what-to- choose-in-2018-b91e028fa91d)

[3] [https://itnext.io/angular-5-vs-react-vs- vue-6b976a3f9172](https://itnext.io/angular-5-vs-react-vs-vue-6b976a3f9172)

[4] [https://medium.com/unicorn-supplies/angular-vs-react-vs- vue-...](https://medium.com/unicorn-supplies/angular-vs-react-vs- vue-a-2017-comparison-c5c52d620176)</comment></comment>


Having a Healthy Midlife Crisis (Gen-Xers Enter Middle Age) - <AUTHOR> http://online.wsj.com/article/SB10001424052748704157304574611993001573558.html?mod=WSJ_hps_sections_careerjournal

<comment><USER2> I guess this does not apply generally to the hacker community. Most of us have a mid-life crisis starting at about the age of 22 and carrying well over sixty. :)</comment>