Twitter abuses all media file uploads, each type in its own way. If we want to upload a good looking animation loop from some low-color, high-detail generative art, we have to game their system's mechanisms.
don't upload a video file, they will re-encode it into absolute 💩
create a GIF, which they will auto-convert into a video file 😱
The frames of the GIF will be resized to an even-sized width using an extremely naive algorithm. Your GIF should be an even size (1000, 2000,
| # IDA (disassembler) and Hex-Rays (decompiler) plugin for Apple AMX | |
| # | |
| # WIP research. (This was edited to add more info after someone posted it to | |
| # Hacker News. Click "Revisions" to see full changes.) | |
| # | |
| # Copyright (c) 2020 dougallj | |
| # Based on Python port of VMX intrinsics plugin: | |
| # Copyright (c) 2019 w4kfu - Synacktiv |
Blog 2020/9/1
<- previous | index | next ->
This script downloads one of the QEMU images from https://people.debian.org/~aurel32/qemu/ and boots up a vm.
This repository contains source code of a shallow water partial differential equation (PDE) solver. The solver is written in differentiable Swift which allows end-to-end propagation of derivatives through time. In physics this kind of solution is traditionally called adjoint and it unlocks a new class of algorithms for optimal control of PDEs.
More details about the PDE and how to derive it from general Navier-Stokes equations can found for example on Wikipedia.
The following notebook demonstrates how the differentiability of the solver can be leveraged to solve an otherwise tricky optimal control problem.
Showcase.ipynb [![ColabBadge]][ShowcaseColabLink]
Based on an example for Elvish.
From comment posted to HN:
I love the structured pipes, but as mentioned in another discussion, replacing the shell is a big leap for a lot of people. And you can get quite far without it with tools like "jq". And when I saw this, I just had to tinker a bit to see what I could do with Ruby, based on the example on the homepage:
$ curl -s https://api.github.com/repos/elves/elvish/issues | jr 'each{|issue| puts "#{issue["number"]}: #{issue["title"]}"} ' | head -n 11
Or (I expect pitchforks when you see the implementation for this):
| # Scan for CVE-2017-0143 MS17-010 | |
| # The vulnerability used by WannaCry Ransomware | |
| # | |
| # 1. Use @calderpwn's script | |
| # http://seclists.org/nmap-dev/2017/q2/79 | |
| # | |
| # 2. Save it to Nmap NSE script directory | |
| # Linux - /usr/share/nmap/scripts/ or /usr/local/share/nmap/scripts/ | |
| # OSX - /opt/local/share/nmap/scripts/ | |
| # |
These results are with glibc malloc on x86_64. The last public PaX and grsecurity patches don't support arm64 which is one of the two architectures (x86_64 kernels including x32/x86_32 and arm64 kernels including armv7 userspace) focused on by linux-hardened. There isn't anything other than x86_64 to compare across all 3 kernels although linux-hardened has the same end result for both x86_64 and arm64 (with slightly different starting points) and there are few mainline differences. The linux-hardened implementation of ASLR is a very minimal modification of the mainline implementation to fix the weaknesses compared to grsecurity. The intention is to upstream all of these changes, although care needs to be taken to properly justify them to avoid getting anything rejected unnecessarily.
Explanation of differences between kernels:
| echo "[+] Getting \system\\currentcontrolset\\services" | |
| $raw_services = Get-ChildItem -Path hklm:\system\\currentcontrolset\\services | select Name | |
| $services = @() | |
| foreach ($srv in $raw_services) { | |
| $shortname = "$srv".Split("\")[-1] | |
| $shortname = $shortname.Substring(0,$shortname.Length-1) | |
| $services += $shortname | |
| } |
One thing that surprises newer programmers is that the older 8-bit microcomputers from the 70s and 80s were designed to run at the speed of random memory access to DRAM and ROM. The C64 was released in 1982 when I was born and its 6502 CPU ran at 1 MHz (give or take depending on NTSC vs PAL). It had a 2-stage pipelined design that was designed to overlap execution and instruction fetch for the current and next instruction. Cycle counting was simple to understand and master since it was based almost entirely on the number of memory accesses (1 cycle each), with a 1-cycle penalty for taken branches because of the pipelined instruction fetch for the next sequential instruction. So, the entire architecture was based on keeping the memory subsystem busy 100% of the time by issuing a read or write every cycle. One-byte instructions with no memory operands like INX still take the minimum 2 cycles per instruction and end up redundantly issuing the same memory request two cycles in a row.
| #!/boot/bzImage | |
| # Linux kernel userspace initialization code, translated to bash | |
| # (Minus floppy disk handling, because seriously, it's 2017.) | |
| # Not 100% accurate, but gives you a good idea of how kernel init works | |
| # GPLv2, Copyright 2017 Hector Martin <marcan@marcan.st> | |
| # Based on Linux 4.10-rc2. | |
| # Note: pretend chroot is a builtin and affects the current process | |
| # Note: kernel actually uses major/minor device numbers instead of device name |
