AngularJS shopping cart demo with Stripe payments integration - <AUTHOR> http://www.airpair.com/javascript/integrating-stripe-into-angular-app

<comment><USER2> I'd be interested in an expansion of the server-side token storage step. Are there particular security-related concerns to look out for when transmitting the token, since the app is entirely client-side?

</comment><comment><USER3> a nice end to end tutorial. wondering does stripe give you a sandbox test area to work against during dev and for testing, that something I'd like to have clear at the outset.</comment>


Why Port Safari to Windows? - <AUTHOR> http://www.applematters.com/index.php/section/comments/why-port-safari-to-windows931/ <comment><USER2> In preparation for Windows developers to test their iPhone apps. Allowing Safari for Windows just opened up a whole new developer community.</comment>


Which notebook to get: MacBook, MacBook Air, MacBook Pro? - <AUTHOR> http://arstechnica.com/journals/apple.ars/2008/01/18/which-notebook-to-get-macbook-macbook-air-macbook-pro <comment><USER2> Well, I've just ordered a MacBook Air. My wife has a MacBook Pro which I love and I have held on using an old PowerBook 12". I don't like the MacBook (sorry to anyone who has one) as I find it too heavy and in a tactile way I just don't like it. The MacBook Air looks so cool and will be the light laptop that I've been waiting for. So what if it does have a few things - it has everything I need

<comment><USER3> I waited for the MacBook Air, but having seen it, I have now replaced my stolen PB 12" with a base white MacBook.

It kicks! My wife has one of the first ones sold by the Woodlands Apple Store, and it had every problem, but hopefully mine has all the bugs ironed out.

The performance with the base 1Gig is great, and the keyboard and trackpad are excellent. My only complaint is reflections on the shiny screen, but you can't have everything.

</comment></comment><comment><USER4> I like the one that comes with Linux... ;-)

</comment><comment><USER5> I've bought a 15" macbook pro (2.16GHz model) and a more recent 17" macbook pro (thanks, work!). I prefer the 17" - it's not that much bigger than the 15, and offers significantly more res even without the 1920x1200 option.

I don't think the macbook air would make a great dev machine.

<comment><USER6> Clearly the MBA is not a good development machine, you want as much screen as possible for that. I have a MBP 17" with the HD screen as my primary machine. I am very happy with it (and I've been through a lot of laptops starting way back with DOS based laptops, through all the Windows variants and with a Linux detour). MBP + VMWare is a perfect combination for me. Dual cores are really nice (have recently been doing some stuff on forgery detection in images, which I'll open source soon, and I can tie up an entire core doing image processing and not notice the difference).

</comment></comment><comment><USER7> Can I ask a more general question? Which type of notebooks are used around this readership? It's my impression that most of you use MBPs, but what about other Wintel notebooks, maybe running Linux? What computer do you use for 16 hours a day?

</comment><comment><USER8> None of the above -- get yourself an asus eeepc instead.

</comment><comment><USER9> What are doing to use it for? Dev / Scoring Chicks (like thats gonna happen) / Browsing... ?</comment>


Why Puppet Should Manage Your Infrastructure - <AUTHOR> http://www.engineyard.com/blog/2011/why-puppet-should-manage-your-infrastructure <comment><USER2> I have one big gripe about Puppet:

Puppet requires both a puppet server (Rails) and client, SSL key exchange, firewall rules for the puppet server, proper DNS records for everything, and a host of dependencies, all of which you need to set up before you can actually do anything.

Any system management solution that requires anything more than a bare machine with SSH and sudo is, in my book, not terribly practical, because these are the lowest common denominator on what you'll get from any hosting provider or OS install.

In a nutshell: I shouldn't need to configure my servers before I configure my servers.

<comment><USER3> You can use Puppet without doing all of that. At Braintree, we use Capistrano to upload a tarball of our Puppet scripts and run the puppet command.

sudo puppet --templatedir $HOME/puppet/templates --factpath $HOME/puppet/facts puppet/puppet.pp

<comment><USER4> Let me endorse both of the above posts. Having now spent many months tinkering with Puppet, I wish to god I had fully understood the value of _not_ using any of Puppet's server features but had instead just shipped the manifests via some other method and applied them locally.

If you need a super-performant version of that strategy (which you probably don't) try googling up Twitter's "murder" project. (Not as violent as it sounds! It's the crow kind of murder.)

<comment><USER2> Until I read this thread, I didn't even think of that as an option -- everything in the Puppet documentation, and the community, and in what they offer as far as training courses, indicates that Puppet's client-and-server are the light and the way to rightness.

I'll have to take a second look at the Puppet manifest system coupled with Capistrano (which I really like), but it still irks me that there isn't one tool to handle configuration management across a large number of servers.

</comment></comment></comment></comment><comment><USER5> We've been using Puppet to manage our servers for some time now. As a group of developers doing our own operations work, we've found puppet both good and bad.

Setting up puppet was relatively straight forward. We had the puppetd auto- updating our servers for a while, but ultimately decided to manually run it when deploying changes. Managing zero-downtime changes was more error prone with it running.

Some aspects of Puppet have over time proved frustrating to us. The top annoyance is we never quite figured out a good way to test our puppet changes before checking them into git to deploy them to our puppetmaster. That has lead to a number of "fixing errors" type commits. The second annoyance we've found is actually highlighted as a feature: no implicit ordering of operations. While it might sound great to be able to reorganize your configs without fear of breaking the deployment, we've found that the tradeoff is that you don't find out that your configuration doesn't define its dependencies correctly until you try to kick a new server after spending months incrementally adding to your existing servers. For us, at least, having an implicit top to bottom ordering would lessen that headache.

Despite some of these headaches, simply having our configuration in version control is a huge win for us. We can setup a box much more easily, and we have a comment trail of why changes were made.

<comment><USER6> About testing puppet changes...

If I had to do it again I would probably ditch the puppetmaster altogether and use an rsync server to distribute the entire configure repository to every server, then run puppet locally to apply changes. This way you can simply modify any local repository and run puppet to apply the desired configuration to any machine you want. When you're happy with the changes you can check them in.

Using the puppetmaster and the puppet fileserver was trickier, essentially I would use FACTER_var="value" to pass in a value to puppet that would use local files rather than central files (which came pretty close to the purely decentralized model anyway).

</comment></comment><comment><USER7> You know what I can't even express the amount of dislike I have for puppet from variables that have 4 purposes (who ever thought up :ensure that can be "latest", a version, a requirement of being available or not or if a service is running needs to be shot buried and encased in cement) to the DSL that tries to be declarative yet puppet isn't and allows for half installs due to failures. Chef isn't any better as it's extremely opinionated - AMQP have to use it, deprecated merb have to use it. Cfengine is in it's own world of suck (ever write unportable scripts with no abstractions? well you do now). I'm not being snarky, I gave each a fair shot while evaluating them by implementing a provider for a distribution.

</comment><comment><USER8> There have been a lot of suggestions (on here and other sites) to run puppet with locally-rsync-ed (rsunk?) copies of manifests, but there are a few things which won't work if you do this, unfortunately. Most importantly is the `storedconfigs' which (afaict) require the puppet server to work.

This means that you lose a large amount of the power of using puppet, by which you can use configurations across machines to do things like collect up all the services you run on a set of machines and generate a nagios config, or firewall config, or whatever. Without using stored configs for this I assume it's possible but will require more explicit configuration rather than the rather more elegant solution provided when using a puppet server.

Side note : I've used puppet on a fairly small scale of up to ~50 machines, and just started using it for VMs, and it's pretty straightforward to integrate into a bootstrap install to get ruby and puppet installed so that you can use it to install all the rest of the dependencies. But of course, the most use is for changes later on rather than at install-time when there are already a huge number of tools to set up or image machines or whatever.

Side side note : I've not used Chef to compare this with.

</comment><comment><USER9> I'm setting up a single server, and even there, puppet and chef come in very handy. I can reuse the recipes on a local vagrant-managed virtual box OS and test both the server configuration and the deployment.

At the moment I like chef-solo a bit better (because it uses an internal dsl).

Just because I beginning puppet standalone and chef-solo - are there some longer term experiences, pitfalls, etc, you can share?

<comment><USER10> I'll write up more about Chef later, but I really look at the two differently. Puppet is really great at managing infrastructure and server state. Chef is really good at integrating with your application (especially if you are using Ruby). I typically think of Chef as a framework to program your infrastructure against. Puppet is more of the middle manager. :)

Both are easy to test, with Puppet winning slightly with 'puppet apply <manifest>'. Chef-solo is nice but takes a little bit more to setup (solo.rb and node.json for example). Either way, test and see what you think will work best for you.

</comment></comment><comment><USER11> Puppet is one of those things I like in principle but is too much of a PITA to set up. Take for example the class definitions, the class definitions don't appear to offer a great deal more than a shell script, but in the example shown in TFA for the price of about 6 lines of puppet code we could've just run rsync -e ssh -avz ntpd.conf puppet@server:/etc/ntpd.conf && chown root:root /etc/ntpd.conf && chmod 644 /etc/ntpd.conf.

Of course in the real world you'd have a tarball you'd rsync over, then use SSH to extract and run the base script and robert's your father's brother. A lot simpler and the way I'd automated Solaris admin years ago. Puppet's drawback is that it doesn't offer anything sufficiently compelling for people to change from what they use, and presents an awful lot of work in it's syntax for people getting started. Once it's up and running it's brilliant, I've seen it. But it just seems like so much hard work to get there it's like a barrier to entry.

<comment><USER6> The original example is actually kind of bad and doesn't demonstrate puppet's abstraction facilities.

You can define a custom resource, for example "system_file" that provides a default "root:root, mask 444" permissions such that you just have to define a source and destination for every file, overriding the default permissions when you want.

define system_file($mode = 444, $owner = root, $group = root, $content = '', $source = '', $ensure = 'present') {

            file { $name:
                    owner => $owner,
                    group => $group,
                    mode => $mode,
                    ensure => $ensure
            }

            if $source != '' { File[$name] { source => $source } }
            if $content != '' { File[$name] { content => $content } }

     }

So in the article's example, it would look like this:

            system_file { "/etc/ntp.conf":
                source => "puppet:///ntpd/ntp.conf",
                require => Package["ntp"]
            }

Or even

            system_file { "/etc/ntp.conf":
                source => "$configfiles/ntpd/ntp.conf",
                require => Package["ntp"]
            }

Where $configfiles might be the puppet server or some other location. One of the things you get with puppet is access to any of the local host properties that can be discovered with facter, so you can dynamically configure something like a source file.

<comment><USER12> Or you could override the default file resource attributes in sites.pp:

      File {
        owner => root,
        group => root,
        mode => 644,
      }

Then you could override that again in individual file resources. If you need several file resources with the same attributes you can override them within the scope of a class:

      class postgresql {
        File {
          owner => "postgres",
          group => "postgres",
          mode => 640,
        }

        $pgsql_root = "/etc/postgresql/8.4/main"
        file { "$pgsql_root/postgresql.conf":
          content => template("postgresql/postgresql.conf.erb"),
          require => Package["postgresql"],
        }

        file { "$pgsql_root/pg_hba.conf":
          content => template("postgresql/pg_hba.conf.erb"),
          require => Package["postgresql"],
        }
      }

</comment></comment></comment><comment><USER13> The real point that should be made about Chef and Puppet is that they are so similar, it really doesn't matter which you use. Using one or the other is a much more important choice than which one you use.

I don't know the best way to express this sentiment (feels like there should be a word for it). But really, just use something to automate your infrastructure and your life will be measurably better.

</comment><comment><USER14> It's been extremely interesting to watch these meta server tools evolve. We're reaching the point where there's not too much of a difference between a scripted network graph and a suite of VMs and cloning abilities. Each technique would have it's advantages, though. Perhaps somebody with large scale infrastructure experience could do a side-by-side comparison?

</comment><comment><USER15> We configure our production servers and push new releases there with Puppet. I like Puppet: its fail-safe and reliable.

There is, however, one thing I don't fancy in it. Puppet does not support insecure client–master communication. Requiring SSL communication is OK, but one should be able to switch it off if it brings no value.

We are running our our servers on AWS, and we rely solely on AWS security groups to grant and deny accesses. Puppet's SSL traffic brings no additional security to us; it only complicates matters. For example: we would like to shut down the Puppet master EC2 instances when they are not needed. However, this is not possible, since after start-up the EC2 instances have new IPs, and this breaks the Puppet-signed SSL certificates.

<comment><USER8> > after startup the EC2 instances have new IPs

They have static ("Elastic") IP addresses:

[http://aws.amazon.com/articles/1346?_encoding=UTF8&jiveR...](http://aws.amazon.com/articles/1346?_encoding=UTF8&jiveRedirect=1)

..don't these let you keep the same IP for your Puppet master instance?

<comment><USER15> That's correct. The problem is that the EC2 internal IPs change even though the instance would have an Elastic IP. EC2 instances use internal IPs when communicating with other EC2 instances (this is a feature of AWS DNS). As a consequence, Puppet clients cannot access the master by using the master's Elastic IP.

<comment><USER8> That sounds rather inconvenient. Are the external elastic IPs non-routable internally? I mean, if you add the IPs explicitly to hosts files then will traffic to those IPs not work?

</comment></comment></comment></comment><comment><USER16> If you want a dead simple way to use Puppet with Rails, check out Moonshine. I did an overview of it at SD Ruby:

[http://jarinheit.posterous.com/a-talk-i-gave-at-sd-ruby- depl...](http://jarinheit.posterous.com/a-talk-i-gave-at-sd-ruby-deploying- rails-apps)

</comment><comment><USER17> A small question:

Assuming you use a single type and version of the OS (say ubuntu vXXX) -- Does it make sense to use the OS native packaging system instead of something like Puppet?

I.e., maintain a private packages repository where you add your custom packages, and have the various servers pull from that repository?

Obviously, this doesn't work if you have different types of servers - but for many servers configured identically, it should work.

<comment><USER6> Of course, for many different servers configured identically, you could use systemimager instead, which is OS-agnostic.

</comment></comment><comment><USER18> The Foreman project takes care of managing a whole bunch of puppet related things for you:

<http://theforeman.org/projects/foreman/wiki/Features></comment>


The Accidental Lobster Farmers - <AUTHOR> http://modernfarmer.com/2014/12/maines-accidental-lobster-farmers/

<comment><USER2> I don't think we need to resort to analogies like 'Herring was acting as a sort of Miracle-Gro' to understand that feeding wild animals makes them grow faster.

<comment><USER3> Oh but the analogy is applicable, since herring "falls" of the magnitude provided by the lobster farmers are quite rare in nature. Its not often that you get an abundance of packed herring as provided in your modern lobster basket, and more to the point provided in a manner which prevents other predators - fish and other basket-navigation incapable species - from joining the feast.

So I think you should take back your glib criticism. Indeed, the conditions induced by your average lobster farmer are rare in the natural world, indeed. It is an important distinction.

<comment><USER2> We don't need to use a plant food analogy to understand that animals grow when fed.

The comparison is strained considering these are wild animals, also. Is spraying a vast wilderness area with Miracle Gro to bolster plant populations some sort of well understood common practice?

It seems to me that this is not at all comparable to typical uses of fertilizer. It would be adequate to say that the herring is providing extra source of nutrient rich, human provided food for the lobsters. There is no need to bizarrely compare them to farmed plants.</comment></comment></comment>


Talkin' Treble: How Android engineers are winning the war on fragmentation - <AUTHOR> https://arstechnica.com/gadgets/2018/06/talkin-treble-how-android-engineers-are-winning-the-war-on-fragmentation/ <comment><USER2> How can this talk about the Essential phone being the best case scenario for OS updates when they just went out of business - did they write this last month and never edit it before publishing this?

<comment><USER3> They never announced they retired.

<comment><USER2> OK, I misunderstood that from the announcement that their next phone was cancelled.</comment></comment></comment>


LastPass Finds Security Holes In Its Online Password Manager - <AUTHOR> http://blog.lastpass.com/2014/07/a-note-from-lastpass.html

<comment><USER2> While this news is a little worrisome, I view LastPass as a "better than what I'd do otherwise" solution, not a "perfect" solution. I no longer use my small set of short, easy-to-remember passwords over and over again across multiple sites. Now most of my passwords are long random strings that I don't even know. The overall increase to my average security offsets the downsides of having a centralized target for attackers, I think.

<comment><USER3> > I view LastPass as a "better than what I'd do otherwise" solution

Do you think it's better than, say, using a desktop-based password manager to save passwords to an encrypted file, and then syncing that file to all your machines via Dropbox?

<comment><USER4> Used to use lastpass but I've found KeePass & KeeFox (firefox Addon) to be just as sufficient for daily use. Just as usable as lastpass and you have much more options for syncing data you know you own and isn't apart of a juicy targeted password database.

</comment></comment></comment><comment><USER5> Any security hole is of course concerning, but as a LastPass user, I'm not at all concerned about the two issues mentioned in this article. The two features in question are, IMHO, not part of a typical use case for the product.

</comment><comment><USER6> Somehow, this poor writeup of LastPass's disclosure is ranking higher than the original post, which predates it on the site:

[https://news.ycombinator.com/item?id=8022543](https://news.ycombinator.com/item?id=8022543)

<comment><USER7> Yes. We'll change the url from [1], which points to this. Unfortunately, we don't yet have a way to do any better than that. But see [2] for two things we're working on that will help in these situations.

1\. [http://techcrunch.com/2014/07/11/lastpass-finds-security- hol...](http://techcrunch.com/2014/07/11/lastpass-finds-security-holes-in-its- online-password-manager-doesnt-think-anyone-exploited-them/)

2\. [https://news.ycombinator.com/item?id=8016584](https://news.ycombinator.com/item?id=8016584)

</comment></comment><comment><USER8> The headline is fearmongery: While the security holes are real, they concern not the security of persistent site-specific passwords but of a) bookmarklets, used by less than 1% of their user base, and b) of one-time passwords (OTPs).

I've been using LastPass for over a year on multiple platforms and many, many sites and didn't even know those features existed....

As written, the headline makes it seem that perhaps, just perhaps, persistent password storage is at risk. Now THAT would freak me out.

But the current news is, for me and many users, nothing to see here, please move along.

Responsible disclosure yes, excellence in headline writing not so much.

</comment><comment><USER9> What do you guys use to store GPG and SSH keys passphrases? Your GPG can be your most valuable stuff. Remembering passphrase of several subkeys seems impossible. The only two passwords I remember are Google Account and LastPass. I could probably remember GPG Master key passphrase but do you think it could also be saved in LastPass.

</comment><comment><USER10> I wonder if they had any way to reasonably detect these being used maliciously after they'd fixed it, since they fixed this as long ago as September 2013.

It'd be a neat sort of non-honeypot.

</comment><comment><USER11> s/Finds/Discloses/</comment>


Towards a Scalable Modular QUIC Server - <AUTHOR> http://dl.acm.org/citation.cfm?id=3098587 <comment><USER2> Link is broken for me. Maybe [http://dl.acm.org/citation.cfm?id=3098587](http://dl.acm.org/citation.cfm?id=3098587) instead?

<comment><USER3> Thanks! Changed from [http://delivery.acm.org/10.1145/3100000/3098587/p19-Duan.pdf...](http://delivery.acm.org/10.1145/3100000/3098587/p19-Duan.pdf?ip=22.214.171.124&id=3098587&acc=OPEN&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E6D218144511F3437&CFID=975084585&CFTOKEN=17008780&__acm__=1503349734_3cf327e1b566a4d6a1864ba645c57975).</comment></comment>


Bernie's plan to hike taxes on some startup employees - <AUTHOR> https://www.axios.com/bernie-sanders-tax-proposal-973ef0b3-06e8-4a76-b15b-5ecbe1bb2a80.html <comment><AUTHOR> These federal policies that don't account for regional differences in income are a problem. The salary level where this kicks in is $130k. On the peninsula in the Bay Area where many people will be effected, the average price of a home is about 7X the national average. $130k might be a lot where home prices are $300k, but around here it's barely a living wage. If your taxed an additional 40% on a possible $100k that you may never see, then it becomes poverty level in this area.

Maybe this guy does not know what he is doing?

<comment><USER2> $100k in stock _at vest time valuation_ is an huge amount.

If your are an employee with a quite large 0.05% equity grant _per year_ , that's a $2Billion unicorn already that is ready to IPO or buy back shares from employees.

> around here it's barely a living wage

I dare you to say that to your janitor or receptionist.

<comment><USER3> Janitors in SF doing pretty well: [https://www.cnbc.com/2016/11/04/how-one- bay-area-janitor-mad...](https://www.cnbc.com/2016/11/04/how-one-bay-area- janitor-made-276000-last-year.html)

<comment><USER4> That guy has some level of seniority so he can work an average of 11 hours a day, 365 days a year. If you lower that to averaging not working 5 days every 2 months (so still working 56 of 61 days every 2 months), he'd be averaging 12 hours a day.

This possibly makes the case even worse for janitors than help showing how they fare.

Roughly estimating. If a person has 2 days off per week (weekends) and either 12 or 24 total days off a year from federal holidays, sick days, vacation days, that is an average of 20 or 21 working days a month.

</comment></comment></comment></comment><comment><USER5> It's already horseshit that the income is taxed on exercise. Just treat capital gains as normal income and tax it when the gains are realized as cash.

I hope this doesn't apply to options without liquidity. Otherwise we should just go ahead and tax scratchers on their potential prize value at purchase.

If this goes through I guess I can't work for a startup anymore. I'm already paying too much in taxes and rent to build wealth, might as well give up on innovating for a small company and work someplace that can pay me and give me options on stocks that I can sell. What a dumb idea Bernie, and I want to vote for you.

<comment><USER6> If it goes through, startups will need to change their employee incentives to compensate, and companies who don't will find that they're now way below market rate.

For example: [https://danluu.com/startup-options/](https://danluu.com/startup- options/)

<comment><USER7> Startups are already way below market rate if the market includes public companies, and you only count liquid stock compensation. The only startups that even come close are ones that are about to IPO.

</comment></comment></comment><comment><USER8> From the article:

      > Sources familiar with the legislation tell me that there
      > could still be tweaks to the language, so don't be
      > surprised if all of this gets addressed. *Particularly
      > given that a top Sanders campaign advisor is Rep. Ro
      > Khanna (D-CA), whose district includes such Silicon
      > Valley burgs as Cupertino and Sunnyvale.*

I.e., gossip.

</comment><comment><USER9> If I was founding a new country today, I'd put in the constitution that governments shall not impose tax more than 33% aggregated in all forms on any person. Between federal tax, sales tax, social security, tolls, sales tax, property tax, registration fees, identity fees, license fees etc etc, governments all over the world have become one money-hungry institution that have failed to provide proportionally economically efficient services.

<comment><USER10> > have failed to provide proportionally economically efficient services

This myth appealing to some automagical optimality of "free markets" has been disproved in real conditions time and time again in domains like healthcare, transports, telecoms or urban planning. Please don't pull that science string when discussing societal choices, especially out here where there will be people contradicting you that probably share your technical knowledge.

<comment><USER9> Even in the developed world, governments have an enormous amount of process overheads and forgo optimizations that are otherwise obvious in places like a startup. This is for a reason aka very high functional guarantees which require extensive peer-reviews and associated approvals by a long hierarchy of authority in order to avoid corruption and abuse of its monopoly. This is the stuff free markets don't have to worry about. This is not a myth and no need to pull any strings. Anyone trying to prove that governments are economically efficient agency has a far harder task in theory and practice. This is why countries that limit government functions to things like defense and infrastructure often achieve faster and better economic efficiency. The countries which have expected the government to function like business to provide any and all services in return of payment called taxes have performed much worse.

<comment><USER10> I think it's pretty obvious that we have deeply differing opinions about social organizations, as such we both have to take care not to resort to axioms of our respective ideology if we want to talk to each other. In particular, i repeat my previous point: i do not accept your use of "economic efficiency" (for me the material well-being is only a part of the goal). Again, "monopoly [..] the stuff free markets don't have to worry about": no, free markets tend to monopolies in real-life scenarios. Indeed since wealth and power distribution is already highly unequal, any kind of structure will be abusive, with incentives to use its leverage to grow an even bigger share.

> The countries which have expected the government to function like business > to provide any and all services in return of payment called taxes have > performed much worse.

Again this i do not accept. For one such a government (which is usually called socialist) is very far from a business since it is strongly limited in scope (shouldn't particularly seek expansion) and doesn't seek to extract marginal profit. Two characteristics which are in contradiction with a consensual definition of "business". It would be more accurate to describe it as a cooperative which is very much anti-capitalistic in nature (i assume you agree that "business" is a capitalistic concept).

<comment><USER9> You are conflating different issues here. Income equality is not actually due to free markets. Monopolies in free markets do emerge but in the socialist system (defined as government providing services in return of taxes other than infrastructure, defense and health+education safety nets) the government is defacto army-enforced monopoly. And yes, no system is perfect.

You have perhaps not heard about how governments all over the world have enriched themselves by monopolizing everything from entire industries, natural resources to sports teams while promising better services to the public (spoiler: didn't work out for vast majority except for Norway). You have perhaps also never been involved in government grants and contracts to see first hand how extraordinarily inefficient, bureaucratic, slow, irresponsive, unmaliable, frustrating, insensitive and far behind the time these entities are top to the bottom.

To anyone dreaming of a socialist system as salvation, I would highly recommend taking up a year or two of a government job to see how it actually functions and what are your chances to improve it even a tiny little bit.

</comment></comment></comment></comment></comment><comment><USER11> This would only further income inequality. Those with family funds to exercise their options and pay the taxes immediately will be at an advantage.

<comment><USER12> You've badly misunderstood the article. (Maybe the article is wrong tho, and it's you that got it right. I didn't read the bill.)

This bill changes when taxes are due for non-quals.

You already pay taxes upon _exercise_ of non-quals. So the ability to pay at exercise does almost nothing to further inequality. In fact it's hugely risky and in almost all cases, a bad idea that leads to lots of money lost. In that sense, having the money to pay the taxes (anyway) improves inequality to the degree that it saps the assets of those with family funds and distributes it (via programs paid for via taxes) to the less fortunate. The opposite of what you're claiming, and what is the case today.

This bill changes the tax to become due at _vesting_. It will either not pass, or will become immediately ineffective as vesting schedules change to a 10 year cliff, with a single [4-year] pro-rata vest upon termination. IOW, for tax purposes you won't vest-as-you-go anymore. You'll vest all at once upon termination. If you choose to not buy your options the company will cancel the option agreement. If you do choose to buy them, the tax consequences are identical as today. Such a thing would be awful for ISOs but for non-quals it doesn't matter. For ISOs you want to buy them early as you can. For non-quals you pay tax upon exercise, so you don't want to buy them as-you-vest anyway.

It's very poorly thought out.

<comment><USER13> It's also hilarious when you think about it. For almost all startup employees, a long enough time scale reveals that the real value of those stock options is exactly zero dollars.

This would have people paying taxes on fictional or purported wealth. As dumb as the tax code is, this isn't even reform.

<comment><USER14> My understanding of the bill is that the tax would apply to the strike price value. $100,000 in strike price is quite a lot more than what your typical startup employee has, and that first $100,000 per year isn't even taxed. For this to apply to you, you'd have to be receiving a ton of options.

</comment></comment></comment></comment><comment><USER15> "The bottom line: This isn't about how much people pay in taxes. It's about when they pay it. It would make more sense for the timing to match the receipt."

It may be worse than that, and it may be about how much people pay in taxes. It's the same logic as tax deferred retirement accounts. The federal government is either going to spend capital immediately (no gains) or they're going to make very constrained gains. Which makes a ton of sense, for a government. But if you let wealth sit in the private sector for a period of time, you can let it grow at rates that vastly exceed, compounded especially, what the government can pull. The taxpayer will pay more taxes in raw dollars, but they're going to end up with more money, both sides are winning.

</comment><comment><USER16> So, removing incentives and expecting the same results?

<comment><USER17> Incentives augment the motivation to achieve, not determine it.

</comment></comment><comment><USER18> Get rid of corporate taxes, get rid of Roth funds, and treat all capital gains as ordinary income at the time the gains are realized.

Problem solved.

<comment><USER19> Why get rid of roth funds? I'm guessing you're super against progressive taxes?

<comment><USER18> Roth funds are the opposite of progressive. It's possible to accumulate millions in roth funds where the eventual net effective tax rate is close to 0%. We already put income caps on roth funds for this reason but it's just too easy to game.

More important than that is just normalizing taxes to something people pay when they realize income instead of this convoluted system we have now.

</comment></comment></comment><comment><USER20> > That means it would be most likely affect employees at later-stage startups, > where the strike prices are higher.

Putting aside whether or not this is a good idea (I'm sure most of us think it is not), it surely ought to be measured on fair value MINUS strike price?

<comment><USER21> The fair value of options is heavily dependent on the strike price to begin with (see [0]). The wording you quoted from TFA is strange at best, and it's inaccurate if interpreted literally - an option with a higher strike price is less valuable than an otherwise equivalent option with a lower strike price. If anything, I'd expect later-stage startups to issue options with _lower_ strike prices relative to their current valuation (since they have less remaining growth potential than early-stage startups), which does mean employees at later-stage startups would be more likely to be impacted.

For what it's worth, you can get far more upside exposure from $100k worth of options (the maximum tax-free amount per year under this plan) than you'd get from $100k worth of equity if the options are far out of the money. I'm not familiar with the specifics of how option values are calculated for early- stage startups, but I'd expect that a startup worth $20M can issue options with a strike of $100M and report those options at a fair value very close to $0.

[0] [https://en.wikipedia.org/wiki/Black–Scholes_model#Black–Scho...](https://en.wikipedia.org/wiki/Black–Scholes_model#Black–Scholes_formula)

</comment></comment><comment><USER22> Sounds like a non-issue

> Sources familiar with the legislation tell me that there could still be > tweaks to the language, so don't be surprised if all of this gets addressed. > Particularly given that a top Sanders campaign advisor is Rep. Ro Khanna > (D-CA), whose district includes such Silicon Valley burgs as Cupertino and > Sunnyvale.

> The bottom line: This isn't about how much people pay in taxes. It's about > when they pay it. It would make more sense for the timing to match the > receipt.</comment>


Viral Pockets - <AUTHOR> http://www.gabrielweinberg.com/blog/2010/12/viral-pockets.html

<comment><USER2> I've seen this phenomenon before and it really is fascinating. I was not able to ever capitalize on it, but I hope someone else is is able to better dissect it, study it, and post about it.

<comment><USER3> Duncan Watts ([http://www.amazon.com/Six-Degrees-Science-Connected- Age/dp/0...](http://www.amazon.com/Six-Degrees-Science-Connected- Age/dp/0393041425)) wrote about this kind of thing in a clear and interesting way.

</comment></comment><comment><USER4> Wouldn't individuals with 'hi' Karma on Hacker News count?</comment>


New Evidence for the Necessity of Loneliness - <AUTHOR> https://www.quantamagazine.org/20160510-loneliness-center-in-the-brain/ <comment><USER2> So MIT researchers had to fiddle with brain cells of mice to find out that _loneliness makes you seek others_?</comment>


Google sets billing rates for App Engine - <AUTHOR> http://www.infoworld.com/article/09/02/24/Google-sets-billing-rates-for-App-Engine_1.html

<comment><USER2> Link dead. Fortunately computerworld derived from it...

[http://www.computerworld.com/action/article.do?command=viewA...](http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=11&articleId=9128533&intsrc=hm_topic)

All of free is still there, but if you want more...

$0.10 per CPU hour[1]

$0.10 per gigabyte transferred in

$0.12 per gigabyte transferred out

$0.15 per gigabyte stored per month

$1.00 to be able to send 10k emails per day instead of 2k

There follows some confusing discussion of reducing free quotas and doubling the free storage quota. I think what they are getting at is tuning so a well written app will fit snugly in the quotas at 5M page views per month.

[1] pg, can I please have some sort of UL or OL formatting? I promise to still try to write literately, but I like lists too.

</comment><comment><USER3> Priced competitively with AWS, will be interesting to see how many people adopt this considering the fact they are locked-in on the google stack.</comment>


A little bit of plain JavaScript can do a lot - <AUTHOR> https://jvns.ca/blog/2020/06/19/a-little-bit-of-plain-javascript-can-do-a-lot/ <comment><USER2> I agree about the nuisance of creating DOM elements. innerHTML is OK if you're doing static content, but for anything that needs to be dynamic (untrusted input, event handlers, etc.) I have a little tiny helper library that I carry around in my head and write into projects that need it:

        const $T = text => document.createTextNode(text)

        function $E(tag, props, kids) {
            const elem = document.createElement(tag)
            for (const k in props) {
                elem[k] = props[k]
            }
            for (const kid of kids) {
                elem.appendChild(kid)
            }
            return elem
        }

(Add flourishes as necessary for things like optional arguments and allowing falsey kids.)

This isn't as nice as JSX, but it makes a reasonably ergonomic API for quick little projects. Here's what the example in the article would look like (admittedly it's a bit easier to follow with syntax highlighting):

        const button = $E('button', {}, [
            $E('i', {className: 'icon-lightbulb'}, []),
            $T('I learned something!'),
            $E('object', {data: '/confetti.svg', width: 30, height: 30}, []),
        ]);

<comment><USER3> A bit more minified/modern version of this that I'm using:

        function $e(t='div',p={},c=[]){
          let el=document.createElement(t);
          Object.assign(el,p);
          el.append(...c);
          return el;
        }

        var $t=document.createTextNode.bind(document);

That's 173 bytes not minified, might be useful for someone.

Interestingly, the function names are exactly the same - I guess people think similarly :-)

<comment><USER4> Isn't clarity better than bytes. We can always running through a minifier at build time.

<comment><USER3> A minifier is better, but I find that snippet of code clear enough for personal use (el is element, t is tag, p is props, and c is children).

The small bytes also mean that for simple sites I can just copy paste it before transitioning to a real setup.

</comment></comment></comment></comment><comment><USER5> _I've never worked as a professional frontend developer, so even though I've been writing HTML /CSS/JS for 15 years for little side projects, all of the projects have been pretty small_

I'm pretty much the same, and one thing I've noticed which continues to both amuse and sadden me is the fact that those whose main focus is _not_ web development often make better sites/pages than "professional" developers. I once rewrote, in a few hours, an internal site that had been developed by another team over a few weeks but with many problems (it was an enormous SPA), and made it so much faster and easier to use that once my coworkers found out, they all switched to using mine. That didn't go over well with the team who built the original...

Another experience I've had with a dedicated frontend developer: [https://news.ycombinator.com/item?id=18486124](https://news.ycombinator.com/item?id=18486124)

<comment><USER6> The only way your comparison works is if your point is "Framework driven apps are _never_ good". I've lost count of the number of times I've pointed out that a good vanilla JS is _always_ going to be better than a bad framework driven app. One is a good app and the other is a bad app. It's obvious, and therefore not a useful comparison.

The valid, _useful_ test is whether or not a good vanilla JS app can be better than a good framework driven app.

<comment><USER7> Yes, but the choice of approach isn't outcome-neutral.

There is also the question of whether going-vanilla more often results in good apps.

I'd go so far as to say the "naive approach" for most things, whenever it delivers on all the requirements, is always the best approach.

Be it relational (vs., nosql); grep vs elasticsearch; etc.

<comment><USER6> The naive approach if you're a developer who knows React is to use React for everything.

</comment></comment></comment></comment><comment><USER8> I'm an experienced React developer.

I wanted to try out writing a plain vanilla JavaScript application - I enjoy plain JavaScript, it feels close to the metal.

It wasn't long before I was craving an application framework that allowed me to cleanly organise and structure my application instead of it rapidly becoming a spaghetti.

I also craved the ability to write small simple functions for making components.

And I wanted a sensible way to organise data flow through the application.

And I really, really wanted to be able to write in a declarative programming style instead of imperative - this is something you don't come to appreciate fully until you've lived it.

And I don't care what anyone else says - I love JSX - it's totally makes sense to me.

So despite a solid effort to try to go to vanilla JavaScript I've decided that a really good JavaScript application framework - whatever one you like - is a good thing. I'll leave vanilla JavaScript to the birds.

<comment><USER9> > it feels close to the metal.

Please tell me you're joking?

<comment><USER10> I mean he is a React developer after all, less than 3 levels of abstraction is greased lightning.

<comment><USER8> As a React developer I have the strictest policy to never go lower level than the browser and I _never_ touch other fields of computing. I started my computing career in 1986 knowing only React and I'll get to the end of it knowing nothing else.

<comment><USER11> Damn, you must be the one scooping up all those 10+ years React experience jobs :)

<comment><USER12> I'm giving GP credit for the joke :) it's hard to mistype 201X as 1986.

</comment></comment></comment></comment></comment></comment><comment><USER13> When starting to learn/write JS, I found a few of these basic name-shortening functions from HN's own JS very useful, and well-named:

        function $(id) { return document.getElementById(id); }
        function byClass (el, cl) { return el ? el.getElementsByClassName(cl) : [] }
        function byTag (el, tg) { return el ? el.getElementsByTagName(tg) : [] }
        function allof (cl) { return byClass(document, cl) }
        function hasClass (el, cl) { var a = el.className.split(' '); return afind(cl, a) }
        function addClass (el, cl) { if (el) { var a = el.className.split(' '); if (!afind(cl, a)) { a.unshift(cl); el.className = a.join(' ')}} }
        function remClass (el, cl) { if (el) { var a = el.className.split(' '); arem(a, cl); el.className = a.join(' ') } }
        function html (el) { return el ? el.innerHTML : null; }
        function attr (el, name) { return el.getAttribute(name) }
        function tonum (x) { var n = parseFloat(x); return isNaN(n) ? null : n }
        function remEl (el) { el.parentNode.removeChild(el) }
        function posf (f, a) { for (var i=0; i < a.length; i++) { if (f(a[i])) return i; } return -1; }
        function apos (x, a) { return (typeof x == 'function') ? posf(x,a) : Array.prototype.indexOf.call(a,x) }
        function afind (x, a) { var i = apos(x, a); return (i >= 0) ? a[i] : null; }
        function acut (a, m, n) { return Array.prototype.slice.call(a, m, n) }
        function aeach (fn, a) { return Array.prototype.forEach.call(a, fn) }
        function arem (a, x) { var i = apos(x, a); if (i >= 0) { a.splice(i, 1); } return a; }
        function alast (a) { return a[a.length - 1] }
        function vis(el, on) { if (el) { (on ? remClass : addClass)(el, 'nosee') } }
        function noshow (el) { addClass(el, 'noshow') }
        function elShow (el) { remClass(el, 'noshow') }
        function ind (el) { return (byTag(el, 'img')[0] || {}).width }

[https://news.ycombinator.com/hn.js](https://news.ycombinator.com/hn.js)

<comment><USER14> The class related functions have been made native by the classList property of elements.

        element.classList.has('someClass') //true if present
        element.classList.add('someClass') //add to element
        element.classList.remove('someClass') //remove from element
        element.classList.toggle('someClass') //remove if present, add if not present

I would also argue element.querySelector and element.querySelectorAll are plenty shorthand to replace the selector helpers!

Not saying HN should rewrite their JS obviously, just for anyone reading this and wondering if there are native equivalents.

<comment><USER10> querySelectorAll is a lot slower than old school functions. You would be tempted to say who cares, but then you load Gmail and wait 2 seconds for UI to render.

<comment><USER15> Do you have any references for this? I would be flabbergasted if the simple case of #id and .class weren't optimized to be basically identical. (the only difference being that they had to do a quick "parse" before jumping into the optimized path)

<comment><USER10> [https://jsperf.com/getelementbyid-vs- queryselector/25](https://jsperf.com/getelementbyid-vs-queryselector/25)

tldr just looking for class x10 slower.

<comment><USER15> Trying that on Firefox mobile and they are all within 5%. The direct calls are faster but that could conceivably be the time to check for special cases with a DOM that small.

</comment></comment></comment></comment></comment></comment><comment><USER16> Nice work! The only advice I'd give is don't use patterns like

        div.parentElement.parentElement.foo()

It's inflexible and will break if you ever make dom changes. Use the .closest() selector instead. It's like a reverse .querySelector (.closest selects ancestors, .querySelector selects descendents) which means you'll have more specific code.

<comment><USER17> TIL about .closest!

From the article.

</comment></comment><comment><USER18> It's a little funny seeing vue/angular/react/whatever people discover vanilla JS. I thought classList, innerHTML, and querySelectorAll were all extremely common knowledge.

<comment><USER19> If I'm not mistaken, she's a systems programmer. More low-level stuff. She's definitely not a frontend/React/vue.js dev, as she says in the article.

She's written some excellent articles on lower-level programming.

But I agree that VanillaJS is not appreciated by a large number of web developers.

<comment><USER20> That's because in order to build anything of any remote sophistication, you _need_ a framework, otherwise you are committing to maintaining an unmaintainable spaghetti mess. Just like nobody actually built Windows applications with just the Windows API -- they all used frameworks like MFC or reimplemented those frameworks in-house.

<comment><USER21> > in order to build anything of any remote sophistication, you need a > framework

Sure. But does the project/requirement described in the original article sound particularly sophisticated?

I note that HN loads less that 150 lines of js and no framework. While there's an argument to be made that this place's frontend code is "not remotely sophisticated", it without doubt provides a huge amount of value anyway.

While I agree with everybody here about the requirements for good frameworks (and good development practices) for complex or sophisticated web applications, to me at least it's abundantly clear the author of the article made the correct choice for her problem domain.

Some things should resist every effort to make them more complex or more sophisticated than they need to be. Most things probably.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." \-- Antoine de Saint-Exupery

I strongly believe that, while he did not know it at the time, he was totally talking there about lines of code.

Bill Atkinson clearly took that philosophy to heart:

"He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000."

from: [https://www.folklore.org/StoryView.py?story=Negative_2000_Li...](https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)

<comment><USER22> The issue is that on regular projects/products, you are trying to hone on perfection by adding and removing a bunch of things and trying different stuff. This repeats for a longer period of time, say 6 months to a year.

The codebase has got to be able to survive that churn in a sensible way, and certain tools like (ES6) modules, types and declarative UI descriptions that automatically update to reflect the changes really help with this process.

Why does this declarative approach help? Because the more features you add, the more places can generate events that cause updates to the same DOM, and the number of possible transitions between those DOM states grows a lot larger. If the number of possible states that the DOM can end up in is N, the number of possible transitions is N^2.

To a first approximation, declarative frameworks scale linearly with the number of interacting features, while imperative (the vanilla DOM API) scale quadratically.

</comment></comment></comment></comment></comment><comment><USER23> Of course you can do quite a bit with JS. Some of the projects I've made

You can swap CSS classes in JS. But how do you know which classes are available?

You can target HTML elements in JS. But how do you know which elements are available?

You can set ".innerHTML". But how do you save the state of the application?

As soon as the app grows a little bit in complexity, you'll end up building functions to keep track of things and functions to perform repeated actions. You end up building a tiny framework that only you know how to use. When it's time to debug and grow, you'll need a proper JS framework anyway.

The thing I would say about popular JS frameworks, and which I'm surprised about, is how they favour single page app structures rather than "drop-ins" to enhance a page. I've yet to see React or Angular be used as part of a page, which is crazy because they would enhance the developer experience so much, without disturbing the classic way of delivering pages server-side with classic routing and classic user experience.

<comment><USER14> There are other frameworks that do favour a "drop in" style of development, with native Web Components being one of them. I used Riot for this for a while, and tried native Web Components as well.

My current approach for zero dependency/build, one off UI components is:

        <div class="some-component" data-props="{}">
            ...more HTML...
            <button class="some-component__button">Click Me</button>
            <script type=text/javascript">
                (function() {
                    var component = document.currentScript.parentNode;
                    var props = component.dataset.props;
                    var button = component.querySelector('.some-component__button');

                    button.addEventListener('click', function(){
                        ...doStuff...
                    });
                 })();
             </script>
        </div>

If it needs a global state, or is part of a larger more dynamic UI I'll start looking at a framework. But for an otherwise static website, it's so much easier to do it that way than it is to introduce an entire framework and build pipeline in order to do a handful of JS components. It's also a somewhat defensive approach, useful in legacy applications with lots of hodge podge JS going on. Generally speaking, you don't cause any problems, and don't encounter any conflicts.

I used to have a class based/web components way to do this, but I don't even bother with that anymore. You don't gain anything from introducing complexity in this circumstance.

</comment></comment><comment><USER24> Indeed! I swore off Web development a couple times because of the mess but now my whole party games platform is made with plain JS, no bundling, no post- processing, no big frameworks and it's pretty good. (Although I did recently augment it with some JSDoc types, for long-term maintainability)

At least three devs have asked why I wasn't using some reactive framework or big library. I know why: I'm much more productive without! Simple DOM helpers go a long way: [https://jklm.fun/common/dom.js](https://jklm.fun/common/dom.js)

(If you're curious: [https://jklm.fun](https://jklm.fun))

<comment><USER25> Well isn't that the economics of it? A new dev is much more productive in the new thing they learned. A more seasoned dev is more productive in all the things they already know.

The question is, who gets to dictate the economics here? The answer is always Thanos, balance.

In a true meritocracy this is a legitimate fight, neither side has a one up. We have to find the pros and cons of the old and new and iterate.

</comment></comment><comment><USER26> @op Nice!

Might be good time to also mention these sites:

[http://microjs.com/](http://microjs.com/)

[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/)

<comment><USER27> [http://vanilla-js.com/](http://vanilla-js.com/)

[http://vanillajs.net/](http://vanillajs.net/)

</comment></comment><comment><USER28> More specifically, how JavaScript can do a lot in browser by interacting through the DOM API.

The modernization of the DOM API in the last 5 years has done a lot to remove the need for jQuery et al, and has made building the View part of JavaScript apps much more frictionless.

<comment><USER29> Where can we learn about this "modern JS"? I feel like in some ways I'm learning the old ways, similar to old c++.

<comment><USER30> The parent isn't talking about JS: they're talking about the DOM APIs. The best resource I've found for learning about these is MDN: [https://developer.mozilla.org/en- US/docs/Web/API/Document_Ob...](https://developer.mozilla.org/en- US/docs/Web/API/Document_Object_Model). I've found this to be an incredibly helpful reference when I need to do something without using a library.

</comment></comment></comment><comment><USER31> An interesting use of 'classList' is that it makes it easy to use css-classes to indicate the state of a dom-element. Is the element selected or not? Well does its classlist include the css-class 'selected'?

<comment><USER32> Do not use classes to mark something as selected. People using screen readers won't know whether something is selected. Use aria attributes like aria- selected instead.

[https://www.w3.org/WAI/PF/aria/states_and_properties#aria- se...](https://www.w3.org/WAI/PF/aria/states_and_properties#aria-selected)

</comment></comment><comment><USER10> If little can do a lot just imagine what I can do with few megabytes: Google Gmail/Youtube engineers

<comment><USER33> Probably a good batch of spaghetti code if you think vanilla can be used for anything serious.

Or rewrite react yourself as another commenter already did.

<comment><USER34> It is an old meme, that every js-developer, who does not use an existing framework, ends up with his own framework. (also happened to me)

Depending on the scope of the work, this is not allways a bad thing. I like my own framework. It does exactly what I want and I can tweak it to my needs anytime.

But I work alone and don't have to share my code with different developers, otherwise there would be problems ...

<comment><USER35> Yeah, the one complaint with frameworks is they never do exactly what you want, instead forcing you to do what generally works for everyone, which is usually good enough. But also can be frustrating. Which is probably why there are many frameworks.

</comment></comment></comment></comment><comment><USER36> So, question for those who are following the JS ecosystem trends more closely: Is innerHTML now officially "ok to use" again?

I remember way back (when XHTML was still on the table) that innerHTML was effectively deprecated: It was still around but you weren't supposed to use it for anything new because support might be dropped at any point in "the future". It was also non-standard. Instead, you were supposed to use the DOM APIs (createElement etc) for any kind of DOM modifications. (Not even talking about the risk of performance issues or XSS vulnerabilities if you used innerHTML naively)

Now "the future" has come around and innerHTML is still supported basically everywhere. It's clear that implementing innerHTML correctly adds substantial complexity to browsers (they have to parse and serialise arbitrary HTML fragments on the fly, synchronously, without stalling the event loop. The result also has to interact well with all the other DOM manipulation/inspection APIs. Not to mention if the HTML string contains its own bits of JS...) - however, there seems to be so much "legacy" content that dropping the API seems infeasible.

So, does anyone know what the official state of innerHTML is in terms of standard compliance and future support?

<comment><USER37> Whether or not it is widely supported is academic - you shouldn't use `innerHTML` for the same reasons you shouldn't use `eval`, the most important being that it is a security risk.

</comment></comment><comment><USER38> I've been doing web development for more than 23 years. I've pretty much stuck to vanilla JS that entire time (though I did use jquery during the worse of the browser incompatibility years). I keep meaning to learn some of the newer libraries but never get around to it since vanilla JS does everything I want it to do and I already know it. I wonder if I would be as surprised by what libraries like Vue can do as this person is about vanilla JS.

<comment><USER6> Not a Vue example but have a look at [https://github.com/drcmda/reactanoid](https://github.com/drcmda/reactanoid)

It's an Arkanoid clone (bat and ball game) written in React, with react-three- fibre for WebGL, zustand for state management, and use-cannon for physics. The full version is about 250 lines and there's also a simplified version that weighs in at 60 lines (not including the library code obviously). It runs at a solid 60FPS on a very basic laptop.

Doing the same thing in vanilla JS, using the same libraries (or alternatives) would be _a lot_ more work, and would end up with the exact same result. That's the point with a well written framework-driven app - when you use something like React or Vue you should be aiming to get the same end result as a vanilla JS app, but with _much_ less effort. The cost to the user should really only be a slightly bigger download.

</comment></comment><comment><USER39> Never set .innerHTML ! document.createElement is very tedious. But you can hide them inside pure functions that returns your component. You could for example put the confetti button example into a function and whenever you want a confetti buttton const button = confettiButton("hurray"); body.appendChild(button); Or you could make a class and extend the Button into a confetti button.

You can then use innerText to change values. And use other DOM methods instead of redoing the innetHTML. When using function abstractions the DOM updates can be private, and you don't have to worry about innerHTML elsewhere overwriting your changes.

Basically React was invented to overcome spaghetti innerHTML, but you can solve the problem with vanilla JS too, just stop thinking about the DOM as HTML, think of it as a tree.

</comment><comment><USER40> I enjoyed this. It conveyed a little of the sense of wonder that can come with just a touch of JS without bashing the frameworks. I also liked the emphasis on making HTML and CSS do the heavy lifting by adding and removing CSS classes as triggers.

</comment><comment><USER41> Instead of HTML, can't JavaScript just be used to paint the browser canvas?

You can create your text boxes, your drop downs, buttons, etc., everything that makes it a GUI application.

Then you fetch your data, per the page you display, via JSON, and fill in the fields.

The initial JavaScript download is heavy, but the normal usage of the web application should be quicker, as you're only fetching the relevant data to fill each of the required widgets.

This does sound resource intensive, for computers back in the 1990s, but today's iPad, iPhone, and modern laptop computers should be powerful enough to handle it.

Or did I just describe some already popular JavaScript framework?

<comment><USER42> I think you just described the browser. While there are some efforts to do canvas-only rendering in JS, they aren't mature and are meant for specific use-cases like game boards and stock charts. For a typical website, this approach would likely have negative implications for your site's accessibility and usability; the site would also be harder to index.

<comment><USER41> That's correct. I was thinking more along the lines of video games and interactive stock charts. But as an easier way to develop GUI applications via JavaScript.

Perhaps where the widget definitions are described via an easier, LISP like syntax, and rendered by the Framework. Kind of like Emacs Lisp.

Actually, it might have been amazing if the original Netscape browser shipped with a Emacs Lisp like scripting tool to begin with. But instead, we got JavaScript.

</comment></comment></comment><comment><USER43> Thank you for this. Really. Thank you.

I wish we had more postings like this.

No complaining, no whining, no "my framework is better than your framework". Just what problems you had and how you solved them.

This actually gives me something to take away.

</comment><comment><USER44> This is great. In legacy codebases for my employer I'll _always_ reach for vanilla JS when solving a problem or implementing a new feature. Better than tacking something on in jQuery.

</comment><comment><USER45> After a full year of only working with React, I started working on a few projects a couple of days ago with Vanilla JS only and it is refreshing. It feels like writing Haiku poems.

</comment><comment><USER46> Unfortunately the reason we have frameworks is because there are so many gotchas. It's true - vanilla JS can do a lot however, there are also a lot of strange edge cases that aren't handled well. If you don't mind failing on these cases then it is fine, but this is why things like jQuery were built and why your React project has hundreds of dependencies. Personally I prefer vanilla JS, but for any serious project it is hard to choose it

</comment><comment><USER47> Does anyone have a nice list of interesting, compact examples of sites or apps that are written in vanilla javascript?

</comment><comment><USER48> I think if you make websites at any layer you owe it to yourself to learn fundamental CSS and modern JavaScript (ES6).

</comment><comment><USER49> What sort of automated test framework do folks use while writing vanilla JS?

<comment><USER50> I use AVA[1] and c8[2] for coverage. It only works in node so I have to use JSDOM to mimic the browser environment.

1: [https://github.com/avajs/ava](https://github.com/avajs/ava)

2: [https://github.com/bcoe/c8](https://github.com/bcoe/c8)

</comment></comment><comment><USER51> In 2020, with our mature and cross browser compatible JavaScript, it surprises me that many people are still discovering vanilla JavaScript. Is something wrong here?

<comment><USER52> I get the sense that there are a ton more beginner tutorials based on frameworks. And those type of tutorials are underrated ways that lots of people use to learn "js".

</comment></comment><comment><USER53> A little bit of C can do a lot, yet most 3A games are written with frameworks.

<comment> ben-schaaf If all you need to do is display a native dialog, read some files, etc. you're better off without the massive 300MB game engine. A lot of people making native apps aren't game devs and a lot that are aren't making tripple-A games.

In the same way there's definitely web apps that are better off with a large framework, but if all you're doing is toggling some classes you're better off without them. Most websites don't need to be SPAs.

</comment></comment><comment><USER54> It's as if using the technology the way it's designed to be used is a reasonable idea. Who could've thought?

</comment><comment><USER55> This is super super minor but it's JavaScript not Javascript. IMO the camel case makes it look so much better :D

<comment><USER56> If you really want to nitpick, it's ECMAScript

<comment><USER57> Well, once it had been LiveScript…

</comment></comment></comment><comment><USER42> Here's what a "little bit" of JavaScript can't do:

      1. Manage subtle browser differences
      2. Store and manage reactive state
      3. Manage declarative updates

You can build a simplified version of React in under 100 lines of code, but that probably won't take care of subtle browser differences. A little bit of JavaScript can do a lot, but it can't do everything you need these days.

<comment><USER58> Does anyone know a 100 line react clone or tutorial? That sounds very educational.

<comment><USER59> This one is amazing: [https://pomb.us/build-your-own- react/](https://pomb.us/build-your-own-react/)</comment></comment></comment>


Shunting-yard Algorithm - <AUTHOR> http://en.wikipedia.org/wiki/Shunting-yard_algorithm

<comment><USER2> Yeah, it's a neat algorithm. I think we implemented it in college. I'm not sure why it was posted here, though. Is there a greater context to this that I'm missing?

<comment><USER3> Possibly related to this story (<http://news.ycombinator.com/item?id=928025>) which has to do with parsing.</comment></comment>


Starbucks to open first coffee shop in Italy - <AUTHOR> http://www.bbc.com/news/business-35684831 <comment><USER2> I remember when I was in Italy 2-3 yeras ago. I think that this concept do not work well in Italy. Italian people drink espresso near a counter. If you want sit down you pay something like fee (coretto) so ordynary Italian folks drink only espresso at couter. The concept of a coffeehouse (where people could sit) was establish more in Vienna. This is smothing completely strange for italian people. I think that this Starbucks concept do not make big impact in Italy (McDonalds case)

</comment><comment><USER3> Well, not my first choice for a coffee place in Italy. Hope at least that they keep giving free wifi. This would help..</comment>


The Ubuntu Conspiracy - <AUTHOR> http://www.linuxjournal.com/content/ubuntu-conspiracy <comment><USER2> It would be by far the biggest community betrayal from the past few years, bigger than Cyanogen and Minecraft selling to Microsoft, and bigger even than Oculus selling to Facebook. I hope Canonical is considering this issue. 80% of its "consumer" users and 50% of its enterprise users could leave it overnight. Ubuntu could become the "OpenOffice" of the Linux distro world.

</comment><comment><USER3> Microsoft to buy Canonical, pass it on!

[http://linux.softpedia.com/blog/microsoft-recommends- ubuntu-...](http://linux.softpedia.com/blog/microsoft-recommends-ubuntu-as- the-most-popular-linux-for-the-cloud-493724.shtml)

</comment><comment><USER4> I would change my ubuntu machines on all the projects, the idea terrifies me (both the operation and the Microsoft).</comment>


Ask HN: Alternatives to Calendly that you know or use? - <AUTHOR> <comment><USER2> I've been using MeetingBird ([https://meetingbird.com/](https://meetingbird.com/)). It is free, has almost all the options and integrations as Calendly, and has a team version too!

<comment><AUTHOR> Surprised that it's free for the amount of features

</comment></comment><comment><USER3> I'm using something called MixMax ([https://mixmax.com/](https://mixmax.com/)) It has a lot of bells and whistles, but I use it only for scheduling meetings over email.

<comment><AUTHOR> Thanks. Any specific reason for choosing Mixmax?

</comment></comment><comment><USER4> [https://hubspot.com](https://hubspot.com)</comment>


What Verna Taught Me - <AUTHOR> http://20bits.com/articles/what-verna-taught-me/

<comment><USER2> This is a fundamental practice of quality management. In the 'Total Quality Management' approach (inspired by Deming's work) the idea is called Kansei and it essentially means: watching how the user users the product will lead to improvements in the product. We see how this has worked well for Agile and Scrum, methodologies in which customer collaboration and feedback are frequent.

The four main principles of the TQM idea are:

Kaizen: Continuous Process Improvement

Atarimae Hinshitsu: things should work as they are supposed to

Kansei: understanding how the user uses the product will lead to improvements in the product

Miryokuteki Hinshitsu: things should have an aesthetic quality, be pleasant

</comment><comment><USER3> There are two things programmers should always do, but are way too lazy (myself included). In my case, it helps I know i'll deal myself with the consequences of shoddy programming, but it's still hard to go against your nature.

1\. Test anything. My apps tend to be flat and simple (business software with web interface) so automated testing is not a real option. Simply going through the motions before uploading on the servers finds 80% of bugs... but it requires considerable discipline to go through 10 minutes of data entry to check a bug fix which took you 5 minutes to code.

2\. Occasionally put yourself in the user's shoes and do whatever he's doing every day. I seldom did this and not come up with an idea or two.</comment>


EC2 Instances Powered by Arm-Based AWS Graviton Processors - <AUTHOR> https://aws.amazon.com/blogs/aws/new-ec2-instances-a1-powered-by-arm-based-aws-graviton-processors/ <comment><USER2> Very cool. As others point out, it does seem a bit expensive, but I do find it impressive that AWS has added AMD and ARM offerings in such a short period. Forgetting the idea of using ARM servers purely for the potential cost savings, I feel this could be a boon to those wanting to run ARM CI builds on actual hardware instead of Qemu.

</comment><comment><USER3> Very interesting. Looking forward to benchmarking these for NodeJS API workloads. Does anybody with experience running node on ARM have any advice/warnings?

<comment><USER4> It all just works well. I've been actually running Node on these instances for a while and it's awesome.

</comment></comment><comment><USER5> Wow...this is actually huge. Finally a big player for ARM based server!

</comment><comment><USER6> Amazon shipping their own CPUs (which are only available on their cloud) and Google shipping their own TPUs (which are only available on their cloud).

TPUs are already a better deal than GPUs for training many models. These CPUs don't seem to have a similar niche yet, but who knows what else they have ready to switch on.

The next ten years are going to be really interesting in the hardware space.

<comment><USER7> Well its true about the TPU's, but you can find similar A72 based servers from other vendors if you try hard enough...

[https://en.wikichip.org/wiki/hisilicon/hi16xx/hi1616](https://en.wikichip.org/wiki/hisilicon/hi16xx/hi1616)

The ThunderX2 based machines aren't A72's but a probably easier to source and are basically in the same conceptual ballpark.

<comment><USER6> Sure, they are Arm cores, but who knows what else they have on them.

Arm has a bunch of extensions[1][2] which would be really useful on these in some circumstances. And that is ignoring the "custom silicon" that Amazon claims to have.

[1] [https://www.arm.com/products/silicon-ip-cpu/machine- learning...](https://www.arm.com/products/silicon-ip-cpu/machine-learning/arm- ml-processor)

[2] [https://www.androidauthority.com/arm-project- trillium-842770...](https://www.androidauthority.com/arm-project- trillium-842770/)

</comment></comment></comment><comment><USER8> For someone who doesn't know much about ARM vs Intel/AMD. What is the use case here? If both run Linux what is the difference?

<comment><USER9> At the current point in time, this is probably limited to ARM-specific workloads (such as if I need to run ARM binaries, or generate ARM binaries without the hassle of cross-compiling).

The long term, however, is where things start to get interesting. I suspect that by the second generation we're going to see ARM servers able to deliver a better price-per-core (and perhaps therefore price for computing performance) than the x86 alternatives. This will be particularly beneficial for applications which require a lot of CPU power and are highly parallelizable. Picture a workload that can take advantage of 64 cores, with ARM you can get this many cores for a lot less cost than x86.

<comment><USER10> These instances already deliver better cost efficiency. The a1 instances are within 5% of the performance of similar c5 instances, but are 40% (!!!) cheaper.

</comment></comment></comment><comment><USER11> Amazon-made CPUs now available in EC2 instances? I hope someone at Intel is paying attention....

<comment><USER12> Surely they do, all kinds of "cloud" companies were their favourite milking cows in the last decade. I believe Amazon's primary motivation for going as far as buying an own chip company was to, at least, send Intel a signal "would you lower the price tag?"

That "cloud" industry is approaching the point of market being fully served, and everybody starting to focus on price. Amazon surely wants to be at least prepared for that, if not having a plan to undercut everybody early on ARM based hosting.

<comment><USER13> From the perspective of capabilities, I think you're right, the market is nearly fully served. From usability, I think we still have a long ways to go.

</comment></comment></comment><comment><USER14> I'm still curious what the real use-cases are going to be for these platforms. I think many people see "ARM in AWS" and think they're going to get an array of super-inexpensive Raspberry Pies with Amazon's network, power, storage and APIs behind them.

But Amazon doesn't appear to be aiming for those users with this product. T3s are probably a faster and cheaper option for the "RPi in the cloud" use-case.

I suspect the real users of this platform are going to be using them for development and testing for mobile platforms.

<comment><USER15> > T3s are probably a faster and cheaper option for the "RPi in the cloud" use- > case.

Cheaper? Yes. Faster? Only in bursts.

The advantage of the A1 instances is you get a full CPU core that you can run at 100% usage 24/7 for ~$18/month. A t3.small is ~$15/month, but you can only use the CPU at 100% for a fraction of the time.

If you're frequently pegging the CPU and so a T3 doesn't work for you, your cheapest option is a C5 which runs ~$61/month.

A1 fits right in between the two needs.

</comment></comment><comment><USER16> This is great news for ARM in general. Hopefully they can offer massive thread count in the future, even if with less powerful cores.

</comment><comment> dis-sys Can't wait to see some specs and benchmarks of this new ARM processor! Best AWS news for me in 2018.

</comment><comment><USER17> Very exciting! I'm curious what type of workloads these will be used for.

Will this be much cheaper than Intel instances?

<comment><USER18> Comparing the large instance (16vCores, 32gib ram) to anything else "large" in N.Virginia, the price seems more affordable than what was purchase-able until now

</comment></comment><comment><USER19> It'll be interesting to benchmark these against existing instance types. Also, there hasn't really been anything in AWS for low sustained load but these seem to fit the bill perfectly.

<comment><USER20> Rick Branson ran a benchmark with Phoronix. a1 is ~2/3 of the cost/performance of a5. [0]

[0] [https://twitter.com/rbranson/status/1067304265696202752](https://twitter.com/rbranson/status/1067304265696202752)

<comment><USER19> Awesome!

</comment></comment></comment><comment><USER21> "we've worked with them to build and release two generations of ASICs (chips, not shoes)"

</comment><comment><USER22> Does ARM feature hardware assisted virtualization? Like Intel VT instructions?

I'm thinking incredibly cheap ARM instances in the future.

<comment><USER4> Yes, Arm does feature hardware virt and it works similarly to other architectures

</comment></comment><comment><USER12> I see, Mr. Bezos finally got concerned by hardware makers turning AWS into their milking cow. Quite a smart move.

</comment><comment><USER23> 2 GB / 1 vCPU about $20. On DO you can get 4 GB / 2 vCPUs plus 80 GB storage and 4 TB on Transfer for $20. (Same with linode.com, upcloud.com)

<comment><USER24> In the same keynote this was announced, they said that one of their regions has reached nearly 5 Pbps of inter-AZ network capacity. They also poked at Google for using phrasing like "regions _usually_ have independent cooling and power control planes". They clarified a common misconception: Regions aren't single datacenters, nor are AZs single data centers, and at least one of their AZs (probably a us-east-1 AZ) has fourteen datacenters.

If you want the Cheapest, go to DigitalOcean. AWS is engineering the Best. Why HN has this obsession with quibbling over a couple dollars while hosting their hobby projects on the same cloud provider that Epic Games and Netflix pay hundreds of millions of dollars to for their massive workloads, I'll have no idea. It's not made for you.

Amazon can get on stage and throw valid infrastructure resiliency complaints at Google. They can't do the same thing against DigitalOcean or Linode, because that'd be like Usain Bolt making fun of a toddler's quarter mile time.

<comment><USER25> Amazon could also pick on someone their own size. Oracle's annual revenue is more than double AWS at 40B a year. If you look at on-prem enterprise IT, or Azure you'll find competitors much closer to AWS with very high performance, resilience, and security guarantees. In fact, Azure is growing much faster than AWS and Microsoft has a huge advantage in many of the industries that AWS is lagging in.

AWS is a leader in "running a web app at scale". But when it comes to Healthcare, Finance, Government, Education, Telecommunications, etc, they are small fish in a big pond.

<comment><USER26> AWS by itself will be the size of Oracle in fiscal 2020. They'll do $24-$25 billion in sales for 2018. Oracle's business hasn't expanded in years: sales in 2015 were $38b, and that's still their approximate annualized sales figure today. AWS is ~64% the size of Oracle. In 2019 they'll be 85% the size of Oracle.

So there you have Oracle with essentially zero growth and a failed cloud business that is not only running from behind, it's a disaster. Things are so bad, Oracle has begun trying to hide their cloud numbers when they report.

Simultaneously, Oracle's balance sheet is turning into a toxic wasteland. Net tangible assets have gone from positive $6 billion to negative $12 billion in just three quarters. They're now spending the equivalent of ~22% of their net profit on debt interest alone. Ellison will have to try to turn to another very large acquisition soon to bail out the ship that is about to sink. As the large cloud competitors get far larger in the next few years, they're going to begin not just robbing Oracle of growth but taking their existing business away. The scale is at a point where for AWS and Azure to double in size again (guaranteed to happen), Oracle is going to lose big.

</comment></comment></comment></comment><comment><USER27> I was expecting a firearm based processor

</comment><comment><USER28> Do you Google Employees think that NSA isn't watching what we do? Mmm, it looks like China is evil so they can't do what USA can

</comment><comment><USER18> Amazon making their own CPUs? Damn. Looks like if you run Python or other scripted languages you can simply port your code over...Nice!

<comment><USER29> They acquired Annapurna Labs back in 2015 - I'm sure this is based on their work, they (Annapurna) were already building chips for Synology prior to the acquisition.

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

<comment><USER30> It is. They mention it in the second paragraph of the linked article.

</comment></comment></comment><comment><USER31> Does vCPU on the chart refer to a physical ARM core and any clue how they stack up against a modern x86-64 core?

If they're significantly cheaper to run at similar perf this is an easy win for arch agnostic things like bastion servers or purely interpreted scripting languages.

<comment><USER32> Hello from the EC2 engineering team!

A vCPU on an A1 instance is a physical Arm core. There is no SMT (multi- threading) on A1 instances. In my experience on the platform, the performance is quite good for traditional cloud applications that are built on open source software, especially given the price. Since the Arm architecture is quite different than x86, we always recommend testing the performance with your own applications. There's really no substitute for that.

<comment><USER31> Thanks for the direct response!

Are A1 instances supported as hosts for ECS clusters?

<comment><USER33> The docker image they release for the on-host agent [0] doesn't seem to have an arm tag. That seems to point towards it being unlikely.

I'll also point out that most docker images you build/run today are x86 and so won't run on arm machines anyway.

[0]: [https://hub.docker.com/r/amazon/amazon-ecs- agent/](https://hub.docker.com/r/amazon/amazon-ecs-agent/)

<comment><USER34> Most of the official Docker images are now multi arch. We have been using Packet.net to build the arm images. But there are many images that are not and some registries don't support multi arch even.

</comment></comment></comment></comment></comment><comment><USER35> Do hosting companies no longer give you the speed of a processing core? I couldn't find anywhere that explains how fast 1 of the ARM cores go? Is it 1ghz or 100mhz? Seems like that would be quite important. Seems like 1vCPU is a bit of an arbitary figure. That could be 1 vCPU that goes at 4ghz but then 2 vCPU's that only go at 1ghz. I feel like there's information missing.

<comment><USER36> With AWS, I found this info from tableau recently:

An AWS vCPU is a single hyperthread of a two-thread Intel Xeon core for M5, M4, C5, C4, R4, and R4 instances. A simple way to think about this is that an AWS vCPU is equal to half a physical core. Therefore, when choosing an Amazon EC2 instance size, you should double number of cores you have purchased or wish to deploy with.

[https://onlinehelp.tableau.com/current/server/en- us/ts_aws_v...](https://onlinehelp.tableau.com/current/server/en- us/ts_aws_virtual_machine_selection.htm)

Don't know how true it is, but there's no reason for me not to trust what Tableau has to say.

<comment><USER37> It's true. Also note that you get a physical core for each vCPU with t2.

I've benchmarked c5 and t3 against t2 and have found single thread perf to be better on c5 compared to t2. When loading all vCPUs the performance suffered on the newer instances (each HT performed worse than a single t2), so you would get more bang for your buck on t2. YMMV of course.

<comment><USER38> Yes T2 performs quite admirably! If your CPU-bound workload doesn't use much memory, smaller sizes of T2 Unlimited can be a much better deal than C4.

T3 gives you both threads of your physical core and commensurably more CPU credits per hour to utilize them. You may notice that even T3.nano offers 2 vCPUs where T2.small has 1 vCPU.

</comment></comment></comment></comment><comment><USER39> Any idea what ARM cores these are based on? A5x? A7x?

A76 would be pretty interesting...

<comment><USER40> Looks like A72. Here's the cpuinfo:

      processor	: 0
      BogoMIPS	: 166.66
      Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
      CPU implementer	: 0x41
      CPU architecture: 8
      CPU variant	: 0x0
      CPU part	: 0xd08
      CPU revision	: 3

<comment><USER39> Too bad, A72 is the sort of thing found in $49 SBC's these days. For the price, it would have been nice to see at least A73, but at least its not an A53.

<comment><USER41> A73 isn't for servers and I don't see any server/embedded SoCs with A75 yet, so Amazon isn't exactly behind.

<comment><USER39> True, most server ARM processors that come to mind are custom (or at least semi-custom): Ampere, Centriq, ThunderX2. Trying to map them to A72/73/75/76 is perhaps short sighted since those are primarily smartphone cores - we'll have to wait and see how they perform in real world tests.

</comment></comment></comment></comment></comment><comment><USER42> On demand pricing starts at roughly $20/month. When they said low cost I was hoping for something in the ~$5 range.

<comment><USER43> And it doesn't come with any Storage or Network Transfer. You will soon require a Phd to figure out the cost optimisation on AWS, or simply switch to DO for a much simpler pricing.

<comment><USER44> I just can't fathom why AWS is so popular given its high mental overhead. Every other VPS provider is like, "Look! It's a server with local storage and memory and CPUs. It comes with this much bandwidth and this much storage. If you pay us you can have it!" AWS: "Hold my beer."

EDIT: I get it, I realize that the value of AWS is in the whole basket of services you can use, not just EC2, but damn do they make it unpleasant. If DigitalOcean gets more enterprise-serious and adds more hosted services, AWS really better watch out.

<comment><USER45> Well there's still an advantage to that flexibility. Sure it's fun for a random project to have average value to every specs, but some project require much more RAM than CPU, or much more bandwidth, or the more usual much more storage. If you need any big amount of storage on Digital Ocean, you need to take one of their beefy machine, even if you don't need that much RAM or that much CPU. Sure there is object storage, but that's a whole different storage system and it doesn't play well with a database server.

When you actually need specific specs at a huge scale, it's not much more complex to do it over AWS.

<comment><USER46> for a database server (or for anything that just needs a big filesystem), DO has block storage, which just looks like an attached hard disk. Works fine with a small VM.

they also have memory-optimized or cpu-optimized VM choices.</comment></comment></comment></comment></comment>


SOPA bill victory Go Daddy folds. Blogs - <AUTHOR> http://blogs.computerworld.com/19483/sopa_bill_victory_go_daddy_folds <comment><USER2> That was 4 days ago, and nobody finds it authentic. There's plenty of discussion on more recent HN threads.</comment>


EtherOops – packet-in-packet attacks on Ethernet cables to bypass firewalls - <AUTHOR> https://www.armis.com/etheroops/ <comment><USER2> The side channel attacks that are coming out of Israel are getting weirder.

</comment><comment><USER3> So use fiber, attack largely mitigated. Got it!

</comment><comment><USER4> The part with the EMP is especially a fun one...

</comment><comment><USER5> Given the large number of prerequisites, this xkcd comic on Security is relevant:

[https://xkcd.com/538/](https://xkcd.com/538/)

<comment><USER6> To be fair, they do say upfront that only nation-state-level attackers are likely to attempt this. It reminds me of a quote from James Mickens[0]:

> In the real world, threat models are much simpler. Basically, you're either > dealing with Mossad or not-Mossad. If your adversary is not-Mossad, then > you'll probably be fine if you pick a good pass-word and don't respond to > emails from firstname.lastname@example.com. If your adversary is the > Mossad, YOU'RE GONNA DIE AND THERE'S NOTHING THAT YOU CAN DO ABOUT IT.

[0] [https://scholar.harvard.edu/files/mickens/files/thisworldofo...](https://scholar.harvard.edu/files/mickens/files/thisworldofours.pdf)</comment></comment>


Show HN: Unreplied 2.0 for SMS/iMessage, now with CLI support - <AUTHOR> https://unreplied.app <comment><AUTHOR> Hi HN!

I finally released version 2.0 of my Mac app, Unreplied!

it offers a status bar menu that shows you a list of messages you haven't replied to. Even if you open the conversation, Unreplied will still keep them on that list, to remind you to reply.

Version 2 comes with a load of new features including a top-down rewrite, Dark Mode support, CLI support, and reminder notifications!

Announcement on my personal blog: [https://duro.me/stories/2020/05/26/announcing- unreplied](https://duro.me/stories/2020/05/26/announcing-unreplied)

How to use the CLI: [https://duro.me/stories/2020/05/26/unreplied- cli](https://duro.me/stories/2020/05/26/unreplied-cli)

I'm hoping people use the CLI mode for new and creative solutions! Let me know if you come up with any, or if you have any suggestions or questions.</comment>


Full video of SpaceX-3 launch - <AUTHOR> https://www.youtube.com/watch?v=Lnf0GArEDsI <comment><USER2> Mr Musk must be proud.</comment>


Ledger and Coinkite Smart-Cards with Multi-Signature for Even More Security - <AUTHOR> http://blog.coinkite.com/post/116127008376/ledger-coinkite-smart-cards-with

<comment><USER2> Lets you use a true hardware wallet (Ledger Nano) with your multisignature account on Coinkite.</comment>


GM, not Tesla, is a better bet on autonomous vehicle future, Deutsche Bank says - <AUTHOR> https://www.cnbc.com/2017/09/25/gm-developing-autonomous-vehicles-at-a-fast-pace-deutsche-bank-says.html <comment><USER2> Dont believe Em' bankers. They could give you loan to buy real estate or mars.</comment>