HN user

onestone

1,885 karma

[ my public key: https://keybase.io/onestone; my proof: https://keybase.io/onestone/sigs/RBwdA9XsiM5Di-mKH-Dz31i3SkzFt-jDtai8W8XlBSE ]

Posts28
Comments155
View on HN
deis.com 8y ago

Deis Workflow Final Release

onestone
5pts0
medium.com 9y ago

“The Flippening” and How I Learned to Stop Loving Bitcoin

onestone
2pts1
v8project.blogspot.com 9y ago

V8 Release 5.7

onestone
4pts0
krebsonsecurity.com 9y ago

A Shakeup in Russia’s Top Cybercrime Unit

onestone
18pts1
v8project.blogspot.com 9y ago

V8 Release 5.6

onestone
3pts0
fork.ethstats.net 10y ago

Ethereum hard fork successful with mining majority

onestone
149pts131
v8project.blogspot.com 10y ago

V8 Release 5.3 – Improved ES6 Promise performance and more

onestone
2pts0
blog.kubernetes.io 10y ago

Rktnetes brings rkt container engine to Kubernetes

onestone
2pts0
v8project.blogspot.com 10y ago

V8 Release 5.2

onestone
6pts1
www.2ality.com 10y ago

Six nifty ES6 tricks

onestone
11pts0
chromium.googlesource.com 10y ago

JavaScript async/await implemented in V8

onestone
509pts217
v8project.blogspot.com 10y ago

V8 Release 5.0 (upcoming)

onestone
91pts31
nodejs.org 10y ago

Node.js Foundation to Add Express to Its Incubator Program

onestone
1pts0
blog.dustinkirkland.com 10y ago

ZFS Licensing and Linux

onestone
6pts0
www.cockroachlabs.com 10y ago

What can we learn from our GitHub stars?

onestone
2pts0
blog.kubernetes.io 10y ago

Kubernetes 1.1 Performance upgrades, improved tooling and a growing community

onestone
20pts8
www.bizjournals.com 10y ago

MIT, Harvard find metabolic 'master switch' behind obesity

onestone
6pts0
andrea.corbellini.name 11y ago

Elliptic Curve Cryptography: ECDH and ECDSA

onestone
41pts3
googledevelopers.blogspot.com 11y ago

Polymer 1.0 Released

onestone
10pts1
googleblog.blogspot.com 11y ago

You say you want a mobile revolution

onestone
1pts0
andrea.corbellini.name 11y ago

Elliptic Curve Cryptography: a gentle introduction

onestone
238pts38
github.com 11y ago

Node.js and io.js are merging under the Node Foundation

onestone
794pts81
www.stgraber.org 11y ago

Getting started with LXD – the container lightervisor

onestone
48pts7
lists.debian.org 11y ago

Ian Jackson Resigns from Debian Technical Committee

onestone
127pts199
systemoverlord.com 11y ago

Towards a Better Password Manager

onestone
1pts0
utcc.utoronto.ca 12y ago

Why systemd is winning the init wars and other things aren't

onestone
129pts153
lists.debian.org 12y ago

Debian Technical Committee chooses systemd as default init system

onestone
2pts1
spion.github.io 12y ago

[JS] Why I am switching to promises

onestone
4pts0
Bootstrap 4 Beta 3 9 years ago

There will be no breaking changes from Beta 3 to stable, so our changelog should be short and sweet. Expect some linting, Sass variable improvements, updated docs Examples, and more build tool improvements.

Nice! We can finally use Bootstrap 4 without expecting future breaking changes.

I have several servers in GRA which were unreachable for two hours. Might have been due to the routing or DDoS-protection infrastructure.

The Ethereum "ice age" is a mechanism to ensure smooth transition to future planned hard forks. By tweaking the difficulty adjustment formula to artificially increase block times after some time (the so called "difficulty bomb") it makes mining on the old chain unprofitable, and incentivizes everyone to move to the/a new one. The general idea is to prevent extreme conservatism and stagnation w.r.t. hard forks, as we are seeing in Bitcoin.

I was the one who added Yarn to the official docker-node image[1][2]. This was the most popular docker-node feature request at the time. We managed to achieve it with a minimal size increase (with the help of the awesome Yarn team) and without affecting anything else. There was already a history of us providing some bonus features which the upstream Node project doesn't, such as a musl-libc build (for Alpine Linux).

[1] https://github.com/nodejs/docker-node/pull/337 [2] https://github.com/nodejs/docker-node/pull/403

Well no, actually. Good Nvidia cards are also nearly extinct, because they are actually still profitable for Ethereum mining. So when people couldn't find AMD cards, they settled for bying Nvidia.

Unlike the situation with Bitcoin a few years ago, Nvidia cards are ok for mining Ethereum (something like 40-50% lower hash rate than AMD, but still very much profitable).

The truth is almost exactly the opposite of what you say actually. Yes, Arch is more difficult to install and configure the first time because it requires you to actually understand the steps it takes. But the top quality documentation really makes that not so difficult.

Arch is actually much _easier_ to maintain afterwards (once installed and configured) than almost anything else. This is because it does not add layers of useless abstraction, very much unlike DEB and RPM based distros. Packages are very close to upstream, with only minimal patches when really necessary, unlike RPM/DEB distros which heavily customize and patch most packages. Packages are also very easy to create, you can learn to do that in minutes, again very much unlike DEB and RPM which are needlessly overengineered and have whole ecosystems of helper scripts aiming to help with that complexity, but you have to spend a lot of time to actually learn them as well.

Also, I might still want to do some things differently server-side in getInitialProps(), despite most of the code being shared. For example, clients might access the API through a load-balanced frontend, while on the server I might want to prefer talking to an API process on the same machine. Authentication might also be different. Of course these things (e.g. the API endpoint) shouldn't be hardcoded, but even then you need to get them somewhere, most likely a configuration file or an environment variable. And sharing these details (names of environment variables for example) with the client is not something I particularly like.

You are right about that, I admit.

Still, using the same transpiled code both client-side and server-side is suboptimal at least. E.g. if I target Node 7.x on the server, I don't need to transpile async functions for example (and screw stacktraces in the process).

I evaluated Next.js recently, and while it looks excellent on the surface, there were a couple of red flags:

- Devs insisting (incorrectly) that they _have_ to ship the component source code _inline_ in the server-rendered HTML. I commented on this issue here: https://github.com/zeit/next.js/issues/427#issuecomment-2908...

- The same transpiled code is used both server-side and client-side. Code which should be strictly server-only, e.g. getInitialProps(), is visible client-side as well.

This doesn't work well for modern websites using push-style updates, e.g. via websockets. Old nginx processes might never close after the reload, as connections are very long-lived. If reloads happen often this leads to memory exhaustion. So this is a bad solution to rely on.

I actually meant economic majority because that's what gives the token its value. A >50% hashrate majority in a PoW blockchain can censor transactions, but it's powerless if most users (or most precisely, the users who own most of the tokens) collectively decide to hardfork.

I'm saying that the main rule for all blockchains (not only Ethereum) is that consensus is decided by the majority. This is their "constitution". The majority of the stakeholders in a blockchain can decide to change the consensus rules. In a traditional legal system majority is not required, laws can be changed by relativly few people.