Given that a large portion of the population has a HD or higher quality camera in their pocket most of the time these days, most cryptid style conspiracies seem pretty well debunked at this point.
The cost to make a digital copy from film stock has gone way down, to the point that fan groups [1][2] frequently encode and clean up old copies of film:
I fake a tiling window manager on Mac with Hammerspoon, resizing to fit in specific corners/sizes:
-- resize based on ratios
function ratioResize(xr, yr, wr, hr)
return function ()
local win = hs.window.focusedWindow()
win:moveToUnit({x=xr,y=yr,w=wr,h=hr})
end
end
-- 4 corners, different sizes
hs.hotkey.bind({"cmd", "ctrl"}, "w", ratioResize(0, 0, 2/5, 2/3))
hs.hotkey.bind({"cmd", "ctrl"}, "e", ratioResize(2/5, 0, 3/5, 2/3))
hs.hotkey.bind({"cmd", "ctrl"}, "s", ratioResize(0, 2/3, 2/5, 1/3))
hs.hotkey.bind({"cmd", "ctrl"}, "d", ratioResize(2/5, 2/3, 3/5, 1/3))
And to throw windows to other monitors:
-- send to next screen
hs.hotkey.bind({"cmd", "ctrl"}, ";", function()
local win = hs.window.focusedWindow()
local screen = win:screen()
local next_screen = screen:next()
win:moveToScreen(next_screen)
end)
I highly recommend Aerospace[1], went through a few approaches, I cared about not completely compromising security either, it works really well if you come from something like i3
Seconding this. I find MacOS unusable without it. I'll ask here because websearch is failing me: is there a way to fix the focus stealing that happens when you have multiple windows of an application on different displays? Specifically, say workspace 1 and 2 are on monitor Left, while 3 and 4 are on Right. Application A has a window on workspace 1, B has one window on 2 and another on 3, and C has a window on 4. Workspace 1 is active on display Left, workspace 4 is active on Right. If I switch to workspace 3 the following happens:
- the switch goes through, Left displays workspace 1, right displays 3 (desired state)
- Application B is focused, presumably because its window on 3 becomes active (also desired)
- Display Left switches to display workspace 2, presumably because it contains a window belonging to the newly focused application B? (I don't want this)
- the window of application B on workspace 2 steals focus from the one on workspace 3 (???)
Charlie's paternal grandfather Reginald married twice—first to Mildred, mother of Charlie's father Arthur and his siblings Beatrice (a nun with spiritual godchildren) and Cecil (whose widow Dorothy married Charlie's maternal uncle Edward). What is the name of Charlie's goddaughter?
I use it similarly, but I add spots for side x side as well as left, center, right. I only use Hammerspoon for this and a couple tiny things, but it's completely worth it for this alone. Use math to specify window sizes & location. Insanity.
local mode = hs.screen.primaryScreen():currentMode()
local mods = {"ctrl", "alt", "cmd"} -- mash those keys
-- regular app windows
do
local w = 1094 -- no clip on GitHub, HN
local h = 1122 -- tallish
local x_1 = 0 -- left edge
local x_2 = math.max(0, (mode.w - w - w) / 2) -- left middle
local x_3 = (mode.w - w) / 2 -- middle
local x_4 = math.min(mode.w - w, x_2 + w + 1) -- right middle
local x_5 = mode.w - w -- right edge
local y = 23 -- top of screen below menu bar
hs.hotkey.bind(mods, "2", function() move_win( 0, y, mode.w, mode.h) end) -- max
hs.hotkey.bind(mods, "3", function() move_win(x_1, y, w, h) end)
hs.hotkey.bind(mods, "4", function() move_win(x_2, y, w, h) end)
hs.hotkey.bind(mods, "5", function() move_win(x_3, y, w, h) end)
hs.hotkey.bind(mods, "6", function() move_win(x_4, y, w, h) end)
hs.hotkey.bind(mods, "7", function() move_win(x_5, y, w, h) end)
end
function move_win(x, y, w, h)
hs.window.focusedWindow():setFrame(hs.geometry.rect(x, y, w, h))
end
I do this too, really happy with my setup - I use hyper+arrow keys to move windows around a monitor (split in thirds on 40”+ or halves on the built-in screen), or jump to another monitor, and hyper+enter to fullscreen. When you push against an edge in full screen it reduces the window size in stages, it all feels natural.
Insert here the New Yorker cartoon about the shabby business executive around a campfire with a bunch of kids crowing "Yes, the planet got destroyed, but for a beautiful moment in time we created a lot of value for shareholders."
I can generally re-find my place in books, but years ago I acquired a stack of orange punch cards from a university library that they were giving away as scrap paper. These make great bookmarks and also interesting historical conversation pieces if someone notices/recognizes them.
I think the previous use for the punchards to have one for each book and scan them on checkout/checkin (maybe this predated barcodes?)
Oxc is not a JavaScript runtime environment; it's a collection of build tools for JavaScript. The tools output JavaScript code, not native binaries. You separately need a runtime environment like Deno (or a browser, depending on what kind of code it is) to actually run that code.
Deno is a native implementation of a standard library, it doesn't have language implementation of its own, it just bundles the one from Safari (javascriptcore).
This is a set of linting tools and a typestripper, a program that removes the type annotations from typescript to make turn it into pure javascript (and turn JSX into document.whateverMakeElement calls). It still doesn't have anything to actually run the program.
I'm going to call it: a Rust implementation of JavaScript runtime (and TypeScript compiler) will eventually overtake the official TypeScript compiler now being rewritten in Go.
Nothing, but it will happen anyway. Maybe improved memory safety and security, at least as a plausible excuse to get funding for it. Perhaps also improved enthusiasm of developers, since they seem to enjoy the newness of Rust over working with an existing C++ codebase. Well there are probably many actual advantages to "rewrite it in Rust". I'm not in support or against it, just making an observation that the cultural trend seems to be moving that way.
If you want native binaries from typescript, check my project: https://tsonic.org/
Currently it uses .Net and NativeAOT, but adding support for the Rust backend/ecosystem over the next couple of months. TypeScript for GPU kernels, soon. :)
No, it it a suite of tools to handle Typescript (and Javascript as its subset). So far it's a parser, a tool to strip Typescript declarations and produce JS (like SWC), a linter, and a set of code transformation tools / interfaces, as much as I can tell.
Going a bit meta - this blog seems strange as its only other story is criticizing a member of the go community. The OP has posted this story, done so twice (first time was flagged) and has no other comments on HN.
There may also be a downvote brigade in this comment section.
I think this must be a bit. On the one hand you have this story about Bernstein, someone who has made a pastime out of weaponizing process in consensus organizations to drag progress to a halt when he's failed to coerce his preferred outcome; on the other hand you have a story villainizing Filippo Valsorda for not doing that, and avoiding standards organizations altogether.
I first encountered djb's work back in the 90's with qmail and djbdns, where he took a very different and compartmentalized approach to the more common monolithic tooling for running email and DNS. I'd even opine that the structure of these programs are direct ancestors to modern microservice architectures, except using unix stdio and other unix isolation mechanisms.
He's definitely opinionated, and I can understand people being annoyed with someone who is vociferous in their disagreement and questioning the motives of others, but given the occasional bad faith and subversion we see by large organizations in the cryptography space, it's nice to have someone hypervigilant in that area.
I generally think that if djb thinks something is OK in terms of cryptograpy, it's passed a very high analytical bar.
