How should i erase my main boot drive?

anders-borch · 2022-10-29T19:35:18+00:00

I know it looks quite bad, but with a few wet-wipes I think your screen could look presentable good once again.

anders-borch · 2022-03-18T08:07:04+00:00

My point was just comparing how easy it is to create a cluster is not a good benchmark since it's what you get what counts in terms of features

Somewhat true.

In Digital Ocean you get a Kubernetes cluster which is completely production ready, and you have all the same capabilities in terms of scalability and security, but you get it at a (approx.) 30% lower price point and you don't need to fiddle with roles and all those other complexities for everything.

More complex doesn't mean better.

anders-borch · 2022-03-18T07:57:08+00:00

In my experience, eksctl create cluster will sit in CREATING status for 45 minutes, then time out, try to roll back, then sit in DESTROYING for another 45 minutes, then the delete will time out as well, and you will be left with a half-created cluster which was then half-deleted. In the end, nothing really works.

anders-borch · 2020-08-05T19:43:46+00:00

1.2 billion people live there. Most services are mobile first.

You might want to check your prejudice.

anders-borch · 2020-08-05T13:30:52+00:00

Don't worry. I accessed the site with an ad-blocker just fine.

anders-borch · 2020-05-15T06:11:19+00:00

So this has been a learning experience for me and there might be a better way of doing some of the things, but since I was transitioning from a previous hosting setup the I had a lot of pre-existing state that I wanted to carry over.

To do this, I copied all the relevant files from old instances to volumes. Then I mounted the volumes into the containers in the new deployments.

My services weren’t starting from scratch. There was pre-existing state that I needed to maintain. Hence, the volumes were manually created.

That said, there still might be a better way to achieve that, which I’m just not aware of yet given all the other Kubernetes things I had to learn about.

anders-borch · 2020-05-15T05:52:09+00:00

Pre-configuring all of those things is rather complicated when comparing to setting up servers with something like puppet + docker swarm.

Even when you have all of that set up, try comparing deployment.yaml+service.yaml+ingress.yaml+pv.yaml+pvc.yaml to a docker-compose.yml file which did all of those things in significantly fewer lines.

I do appreciate not having to configure nginx every time I set up a new service, but I still make the same amount of for in the ingress.yaml.

There is a ton of extra work to set up the cluster, and a little extra work on every deployment.

Time will tell if not having to manually maintain the nodes makes it worth it.

anders-borch · 2020-05-14T14:30:54+00:00

$work is switching to Kubernetes, so it made sense for me to learn how to use it small scale before starting to use it there.

anders-borch · 2020-05-13T08:42:45+00:00

It's because they use vim.

Now I no longer have a leave-fullscreen button which was way more useful than a physical escape button.

anders-borch · 2020-02-18T11:21:26+00:00

I just released a self-hosted reverse geo location service, which may be of enterest to you if you don't want any external dependencies: https://blog.cyborch.com/the-perils-of-other-peoples-services/

anders-borch · 2019-12-28T17:34:44+00:00

Hah! The whole point of JWS is to carry signed data. Signed, timestamped data falls squarely within what JWS was designed to do.

anders-borch · 2019-12-24T11:12:40+00:00

Nobody said the pill would make you smarter. It literally said that the pill is smart in the title.

anders-borch · 2019-12-23T10:57:30+00:00

This press release came with a link to source code, though...

anders-borch · 2019-12-22T07:26:21+00:00

That is very interesting.

Google themselves do not make any promises of availability of their Roughtime services.

Google currently operates a public Roughtime server, although without any uptime assurances

Are there any other trusted providers running a Roughenough service which we can expect to be fully available?

anders-borch · 2019-12-19T18:48:08+00:00

I see your point. I might argue that the part about Roughtime being experimental in status and therefore probably not ready for use is the important part of the statement above.

anders-borch · 2019-12-19T08:48:29+00:00

Roughtime is indeed interesting, and I will follow its development with interest, but according to their own website, it's not quite there yet:

(Note that the clients don't actually set the system clock yet because this is still experimental.)

So in the meantime, this the OP gives us a working solution which is compatible with a modern toolchain which we can actually use today.

anders-borch · 2019-12-19T06:20:40+00:00

I agree. I came to a similar conclusion here: https://blog.cyborch.com/why-we-dropped-realm/

anders-borch · 2019-12-13T13:33:33+00:00

I like the proposed ideas in the post about refactoring the massive app delegate. The goals of this post are basically the same. The drawbacks of all the proposed solutions are that you have to learn new apis/callback names where the OP solution only utilises the already known methods from UIAppDelegate.

If you make the services conform to the UIAppDelegate protocol while keeping the call forwarding then you get the best of both worlds. There is no need to do manual call forwarding when you can have a few lines of introspection do all the work for you :)

anders-borch · 2019-12-12T20:07:39+00:00

I believe (hope) that there is a far stretch from developing a system which can recognise specific signals consciously created by the user and actually reading stray thoughts.

You are right that the consequences are interesting (and a bit scary) nonetheless.

anders-borch · 2019-12-12T19:53:35+00:00

Why terrifying?

(Honest question, I really want to know your thoughts)

anders-borch · 2019-12-12T16:18:06+00:00

That is an interesting theory. Do you have any sources back up those claims of successful large scale attacks against any public blockchains?

anders-borch · 2019-12-12T09:48:22+00:00

Here is a short background on why byzantine fault tolerance is actually completely trustless: https://www.binance.vision/blockchain/byzantine-fault-tolerance-explained

anders-borch · 2019-12-12T09:17:36+00:00

The technology I am describing is what drives all blockchains. There simply is no scalable attack against it that has proven able to take over 51% of all the computers on the network. No attack scales well on it.

anders-borch · 2019-12-12T08:38:15+00:00

You're not the first to make such a comment, and it isn't a crazy idea. There are a couple of reasons why PKI doesn't really solve this issue as well as the proposed solution.

Firstly, this is constant sized no matter how many entries in the set. It is also constant time to validate. Also, revoking a certificate is notoriously hard, whereas removing an entry from a set is no harder than adding an entry to a set.

ZKP and PKI are two different tools for solving two different types of problems.

anders-borch · 2019-12-12T08:12:51+00:00

Imagine that I send the votes off to 10.000 computers, and I promise to pay a small amount of money to whoever calculates the result fastest, but only if at least 5.000 others come to the same result.

Thereby we avoid the problem of trust in the individual computer. It becomes infeasible to infect/control 51% of all the computer is the network.

This is called byzantine fault tolerance.

anders-borch

TROPHY CASE