297 karma · joined January 6, 2017
> BleepingComputer has been told that the Akira ransomware operation is behind the attack on Tietoevry, coming soon after the Finnish government warned about their ongoing attacks against companies in the country.
> "The incidents were particularly related to weakly secured Cisco VPN implementations or their unpatched vulnerabilities. Recovery is usually hard," warned the Finnish NCSC.
I wonder what the entrypoint was back in 2021 when they were attacked around the same time?
[1]: https://www.bleepingcomputer.com/news/security/tietoevry-ran...
> What's after that?
>
> Tons of stuff. Tons and tons and tons of stuff.
> Debuggers have not substantially evolved since the first Turbo Debugger in 1988!
> For example, we have had GUI debuggers for 20 years now, and we can't see bitmaps! We can't hear sound buffers. We can't view vertex arrays.
> We can't graph values over time. We can't even load a debugging session from yesterday and review it! We have a long way to go.
> Debugging is desperate need of updating, and we see as a long term project. We'll be adding visualizers, new debugging workflows (step through code on multiple platforms at the same time for example), and new features for a long time.
Would be interesting to verifiably taste real wasabi. Who knows, maybe I've never actually even tasted the real thing?
I'm sure.
That way you'd at least have the protection of the WPA GTK.
If you're using docker/podman or docker-compose and your db size is small, a major speedup on linux is to just mount the entire data dir into memory with --tmpfs /var/lib/postgresql/data (or tmpfs: - /var/lib/postgresql/data in docker-compose)
Additionally, if you constantly reset your db in the tests, consider making a template db at the start and later just doing CREATE DATABASE ... TEMPLATE foo; to copy the pages from that template instead of running migrations that produce WAL log. In fact, consider making a db for every test suite from that template at the start - then you can run each suite in parallel (if your app's only state is the db and a single backend).
> The V8 engine is updated to version 11.3, which is part of Chromium 113. This version includes three new features to the JavaScript API:
> ...
> - Methods that change Array and TypedArray by copy
> ...
Excited to see these in. I've been waiting for the non-mutating versions of .sort() and .splice() and now they're finally here (.toSorted and toSpliced)!
> - Resizable ArrayBuffer and growable SharedArrayBuffer
Does this mean that WebAssembly memory can also now grow without making a copy of the entire buffer?
> The V8 update was a contribution by Michaël Zasso in #47251.
Well done Michaël!
You restart the board to programming mode by holding down the BOOT button down while pressing RESET. Wait a few seconds, then COM7 is available. You program the board, and then manually RESET the board with the button. COM7 disappears. Then you wait a few seconds, then COM6 appears. Oh, did you print some debug info on boot? Too bad, it takes a few seconds for the virtual serial port to appear in Windows so you just can't get input during that time because the reset resets the USB controller as well (the entire chip).
This is the benefit of on-board USB-UART chips: if you need to reset the chip, your USB controller doesn't need to be reset so your serial port stays open. Additionally, most ESP32 dev boards offer automatic reset by utilizing the DTR or RTS pins of the UART chip and a couple of transistors.
> AutoHotkey v2 aims to improve the usability and convenience of the language and command set by sacrificing backward compatibility. As such, scripts written for v1 generally will not work without changes on v2
[1]: https://www.baesystems.com/en/feature/adativ-cloak-of-invisi...