bitonic

// Copyright (c) 2021 Francesco Mazzoli <f@mazzo.li>
//
// Permission to use, copy, modify, and distribute this software for any
// purpose with or without fee is hereby granted, provided that the above
// copyright notice and this permission notice appear in all copies.
//
// THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
// WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
// MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
// ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES

joepie91

The Freenode resignation FAQ, or: "what the fuck is going on?"

IMPORTANT NOTE:

It's come to my attention that some people have been spamming issue trackers with a link to this gist. While it's a good idea to inform people of the situation in principle, please do not do this. By all means spread the word in the communities that you are a part of, after verifying that they are not aware yet, but unsolicited spam is not helpful. It will just frustrate people.

Update 3 (May 24, 2021)

A number of things have happened since the last update.

yorickdowne

Overview

Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by ~ 14 GiB/week with default cache, ~ 8 GiB/week with more cache.

This will fill a 1TB SSD in a few months, to the point where space usage should be brought down again with an offline prune.

There is an odd behavior with Geth 1.10.20 where initial DB size is large after sync until Geth has been restarted twice. This is expected to be fixed soon, possibly as soon as 1.10.21.

Happily, Geth 1.10.x introduces "snapshot offline prune", which brings it back down to about its original size. It takes roughly 4-6 hours to prune the Geth database, and this has to be done while Geth is not running.

Caveat that while several folx have used offline pruning successfully, there is risk associated with it. The two failure mode

F1LT3R

#!/bin/bash

# USAGE: ytm3 https://www.youtube.com/watch\?v\=rQLBitV69Cc
# DESCRIPION: Download Audio from YouTube videos, Convert to split MP3s (5 Min)
# PURPOSE: Studying w/ iPod shuffle
# PRE-REQS: Node.js, YTDL, FFMPEG
# Author: F1LT3R.io

for URL in $@
do

jordansinger

import SwiftUI
import PlaygroundSupport

// constants
let cardWidth: CGFloat = 343
let cardHeight: CGFloat = 212
let spacing = 36
let animation = Animation.spring()
let cardColors = [
    Color(UIColor.systemRed),

erincandescent

Foreward

This document was originally written several years ago. At the time I was working as an execution core verification engineer at Arm. The following points are coloured heavily by working in and around the execution cores of various processors. Apply a pinch of salt; points contain varying degrees of opinion.

It is still my opinion that RISC-V could be much better designed; though I will also say that if I was building a 32 or 64-bit CPU today I'd likely implement the architecture to benefit from the existing tooling.

Mostly based upon the RISC-V ISA spec v2.0. Some updates have been made for v2.2

Original Foreword: Some Opinion

The RISC-V ISA has pursued minimalism to a fault. There is a large emphasis on minimizing instruction count, normalizing encoding, etc. This pursuit of minimalism has resulted in false orthogonalities (such as reusing the same instruction for branches, calls and returns) and a requirement for superfluous instructions which impacts code density both in terms of size and

taoeffect

PoW vs PoS - Environment and Security

Date: Jul 21, 2019
Updated: See Github revisions timestamps

In questions sprouted from this thread: https://twitter.com/taoeffect/status/1151941939157012480

I copy them here into this gist in the hopes that it will serve others and so that in the future I have something I can link people to. My thanks to @Jehan for the opportunity to put my thoughts on this subject into a somewhat easier-to-read medium.

I've always had trouble understanding the narrative that the owners of huge

jfet97

const obj = { a: { b: 1, c: 2, d: { e:4 , f:[1,2,3,4,5,6,7,8,9,0]} }, g:42 };

const res = Object.fromEntries(flatProps(objectRecursiveEntries(obj)));
/*
{
    "a.b": 1,
    "a.c": 2,
    "a.d.e": 4,
    "a.d.f.0": 1,
    "a.d.f.1": 2,

ebfull

How do I verify the Sapling MPC?

What you'll need

1. Install the Rust compiler. A version from a year ago will work but the recent one is fine too.
2. Download the transcript from the Powers of Tau MPC. (See the links here.)
3. Download the params file from the Sapling MPC.
4. Check out the attestations for the Powers of Tau MPC. (Similar can be found for the Sapling MPC but participants chose various ways to distribute their attestations, they have not been coalesced into a single repository.)

Step 1: Verify Powers of Tau

andyrbell

# use ImageMagick convert
# the order is important. the density argument applies to input.pdf and resize and rotate to output.pdf
convert -density 90 input.pdf -rotate 0.5 -attenuate 0.2 +noise Multiplicative -colorspace Gray output.pdf