Not sure if the devs are here, but please don't justify your text! It makes the lines all have huge spaces in the middle. It's much harder to read as a result.
Honestly I've just set up a user CSS sheet that forces left justify. It makes the internet more comfortable, and has practically no downsides / bad interactions, unlike many such overrides.
rivers, contextual word splits, compound noun splits, awkward pauses, there is so many downsides to mindless text justification. Only editorialised and hand crafted justified text is nice. Everything else ends up forceful and ugly.
Strange that online it fell out of favor, because text justification was the default for centuries. It's still around in most PDFs though, e.g. in research papers.
When done properly (i.e. in LaTeX with microtype, with good line breaking algorithm and character expansion) justified text is easier to read. The web is not that.
Ah, this is great! It's a step towards solving my biggest complaint with PEP 723 scripts: bad editor support.
I loved the idea on paper, but without manually creating a matching venv & installing my deps, I wouldn't get in-editor completions during development. That was fine for small things, but intolerable as the script grew. So it's still not a feature I've used much, since it made more sense to just make a real dev environment.
It depends! It's more about growing complexity than LoC. Like if I'm pulling more and more functionality out of cyclopts[0] for arg parsing. Each time I have to go to the docs instead of getting in-editor suggestions it's a little bit more annoying. The earlier I swap over, the nicer it is.
I got hit with a cryptominer on my mac mini the other day. I only noticed because I happened to sitting in the room with it and noticed the fans were working overtime. There was a process, "icloud-services", which was using 100% of the CPU. It's sort of an indictment of Apple that my first inclination was "they've got a bug that's got an infinite loop" instead of "this is malicious software".
After a reboot, I traced it back to a folder in `Library/Application Support` which included a `config.json` that mentioned gulf[.]moneroocean[.]stream, so I knew I'd been popped. Cleanup was easy enough (the files themselves, plus the launch daemon), but it's annoying.
I don't do dev work on that machine (it's really just for plex & stuff) so it must have been some sort of vulnerability in Plex (but not the one described in OP) or macOS itself. Interestingly, I was up to date on my Plex install, but my macOS version was behind what was apparently an important security update related to an RCE (Sequoia 15.8).
Probably? But then I'm using the "vpn slot" on my device all the time which prevents me from connecting to my work VPN when I need it without a little vpn disable dance.
And anyway it drains the battery; and maybe I don't want to add VPN to every device I want to listen to music with, like my PC at work.
Yup. Same use-case. I ended up with a geoblock as a mitigating control. Doesn't fully prevent these types of things, but alleviates the mass-scan type attacks.
If you ever find yourself in southern Louisiana, the Tabasco factory on Avery Island is worth the visit! You can see the factory floor, try as many variants of the sauce as you want, and learn a ton about the history of the company.
It's also a beautiful property complete with a ecologically important bird sanctuary. Just a fascinating day!
I took a detour to visit there once, many year ago, and it was well worth it. I remember being surprised by how small the factory seemed compared to what I expected.
Agreed! Avery Island is a salt dome and is interesting in its own right (just the salt dome). There are other salt domes nearby (Weeks Island and Jefferson Island). If you visit Avery Island and see alligators, you should leave them alone. Despite them appearing that they might move only slowly (and often they do move slowly) they are very fast and can outrun you.
I don't understand why they felt necessary to rewrite a core component in another language. If you have a garbage collection problem my first intuition would be to produce less garbage!
For example better using the stack, or pulling out the big gun of manual memory management.
I'm sure they had reasons to choose Go when they first designed this project but they don't go into them at all.
Feels like they just wanted to play with a new toy.
> If you have a garbage collection problem my first intuition would be to produce less garbage!
FTA:
“These latency spikes definitely smelled like garbage collection performance impact, but we had written the Go code very efficiently and had very few allocations. We were not creating a lot of garbage.
[…]
the spikes were huge not because of a massive amount of ready-to-free memory, but because the garbage collector needed to scan the entire LRU cache in order to determine if the memory was truly free from references”
They explained in the post why this wasn't an issue: they were producing very little garbage, but there was a very large object graph.
> manual memory management
If you need to do manual memory management in a GC language with no builtin support for it, like Go, that's probably a sign that you should switch to a different language.
And importantly in a tracing GC the work load is a function of the non-garbage data not of the garbage.
Generational GC can avoid some of it by ignoring the old code entirely, but Go does not implement generations because its relatively strong ability to stack-allocate generally replaces the nursery, and for most work loads you don’t recoup the costs.
Problem with languages like Go is, because they have GC, their API is less tuned to the ability to prevent new allocations.
In C you see lots of functions whose first parameter is a buffer that will be re-used.
And even in Rust you don't see this often, because reusing a buffer means having to do &mut, which means having to re-structure your code. And it's really easy to do Vec::new().
One of big issue with GC is it need to scan every reachable objects to mark it is reachable. That mean even if your code produce no garbage but have a large amount of long lived object the GC still need to traverse all of those objects every cycle.
It doesn't mention the most annoying tell- content that fades in as you scroll down a page. I'm seeing this everywhere recently and it's so distracting
Depends how much you want to automate, but all you really need is a VPN (or so I am told). There are some good docker containers that bundle the VPN, Transmission, and a dead-man's switch for the connection (allegedly)
I traded a Prusa MK3S for a secondhand Bambu P1S and it was night and day. I believe the prusa could have gotten to a place where it printed well and consistently, but the P1S *just works*. It printed better out of the gate with 0 tinkering than the Prusa did after I had spent hours calibrating, testing, and re-calibrating it.
I wanted the Prusa to be just as good, which is why I started with it. I wanted to support the open ecosystem, but not at the expense of not getting to do what I actually set out to (print things nicely). It's a shame! Maybe I was holding it wrong (but again, with the Bambu, I didn't have to worry about it).
Interesting; I’ve had an mk3s for years now (which i bought specifically to avoid the tinkering necessary with other brands at the time) and apart from dealing with a couple of blockages (probably due to a cheap roll of filament) it’s been totally reliable and hassle-free. I think I’ve had it recalibrate itself maybe three times amongst hundreds of prints. I wish it had automatic print head adjustment to deal with flexible filaments, but that’s about it.
I have a p2s (and x2c) but the main difference in can instantly tell here is that I haven't had any clogs with any enclosed Bambu so far and whatever material I throw at it it just works. It's maybe not a lot difference but it's the thinker free experience I was hoping for.
reply