At my work, one thing that I've often had to explain to devs is that the Parallel collector (and even the serial collector) are not bad just because they are old or simple. They aren't always the right tool, but for us who do a lot of batch data processing, it's the best collector around for that data pipeline.
Devs keep on trying to sneak in G1GC or ZGC because they hyper focus on pause time as being the only metric of value. Hopefully this new log:cpu will give us a better tool for doing GC time and computational costs. And for me, will make for a better way to argue that "it's ok that the parallel collector had a 10s pause in a 2 hour run".
Every GC algorithm in HotSpot is designed with a specific set of trade-offs in mind.
ZGC and G1 are fantastic engineering achievements for applications that require low latency and high responsiveness. However, if you are running a pure batch data pipeline where pause times simply don't matter, Parallel GC remains an incredibly powerful tool and probably the one I would pick for that scenario. By accepting the pauses, you get the benefit of zero concurrent overhead, dedicating 100% of the CPU to your application threads while they are running.
Gotta be honest, I have a hard time arguing for G1 over ZGC. It seems to me like any situation you'd want G1 you probably want ZGC instead. That default 200ms target latency is already pretty long. If you've made that tradeoff for G1 because you wanted lower latency, you probably are going to be happier with ZGC.
I also find that the parallel collector is often better than G1, particularly for small heaps. With modern CPUs, parallel is really fast. Those 200ms pauses are pretty easy to achieve if you have something like a 4gb heap and 4 cores.
The other benefit of the parallel collector is the off heap memory allocation is quiet low. It was a nasty surprise to us with G1 how much off heap memory was required (with java 11, I know that's gotten a lot better).
What I want in windows is Notepad++ or Kate (and even Kate is a bit much). That's the full extent of the features that I'd want in something like notepad.
Adding RTF and a wysiwyg markdown editor is the last thing that I want from something like notepad. When I open notepad, I still want to see the characters that are present. Heck, I'd like to be able to see the difference between a space and a tab. I'd want to be able to see which type of line ending are being used (and switch to the correct one, \n) Hiding characters is antithetical to the reason I'd use notepad in the first place.
I want to be able to search text and see text. Not compose a document or talk to an LLM.
Oh I've ditched windows or I would go grab Kate (I use it on my linux box). I'm just commenting on how even if you were to enrich the features of notepad, the direction to take it is towards a kate editor and not towards an wordpad editor.
The main case I can think of is wanting some forum functionality. Perhaps you want to allow your users to be able to write in markdown. This would provide an extra layer of protection as you could take the HTML generated from the markdown and further lock it down to only an allowed set of elements like `h1`. Just in case someone tried some of the markdown escape hatches that you didn't expect.
I think this might be the answer. There's no point to it by itself (either you separate data and code or you don't and let the user do anything to your page), but if you're already using a sanitiser and you can't use `textContent` because (such as with Markdown) there'll be HTML tags in the output, then this could be extra hardening. Thanks!
I wouldn't trust myself to always remember to sanitize it, and in a company with more than one person, it becomes impossible to ensure it is properly handled.
Seems like this has a bunch of footguns. Particularly if you interact with the Sanitizer api, and particularly if you use the "remove" sanitizer api.
Don't get me wrong, better than nothing, but also really really consider just using "setText" instead and never allow the user to add any sort of HTML too the document.
Using an allowlist based Sanitizer you are definitely less likely to shoot yourself in the foot, but as long as you use setHTML you can't introduce XSS at least.
The energy density isn't out of line if this is a true solid state battery. The cycle life, though, is AFAIK. I don't believe solid states have that sort of cycle life.
Addressing the claims one by one is still doing it head on. There's not some logic timeline for this stuff.
The slow drip of verification is a smart move IMO. It keeps them in the media for longer (Gabbo) and stops them from being lost in the other 1000 different battery announcement. Hopefully getting them funding I'm guessing they need to start full manufacturing.
That said, while this certainly is a promising battery based on the claims, I won't get my hopes up until there's an actual product I can buy.
Molasses was cheap because it was the packing material for plate glass - which was only made in England. Place your plate glass in a barrel, fill it with molasses and you can ship it to North America. Just wash off the glass and you're good to go.
Agreed. They said they ruled out rust in 2024, I believe the article they published was near the end of 2024 because I remember reading it fairly recently.
Seems like a lot of language switches in a short time frame. That'd make me super nervous working on such a project. There will be rough parts for every language and deciding seemingly on whims that 1 isn't good enough will burn a lot of time and resources.
Devs keep on trying to sneak in G1GC or ZGC because they hyper focus on pause time as being the only metric of value. Hopefully this new log:cpu will give us a better tool for doing GC time and computational costs. And for me, will make for a better way to argue that "it's ok that the parallel collector had a 10s pause in a 2 hour run".
reply