Systemd actually manages /etc/passwd, /etc/group, /etc/shadow, etc. using a json database called userdb. Adding a field to systemd's userdb is how you add a gecos field.
In the context of surveillance, yes it is. I know the EU is looking down the barrel of chat control, but I'm pretty sure this California law has already been passed and goes into effect January 2027.
Compilers don't usually write the code that ends up in a PR. But compilers do (and should) generally leave behind some metadata in the end result saying what tools were used, see for example the .comment section in ELF binaries.
The alternative is that for every glyph you render the entire glyph to the screen using the Bezier curves from the font, and you end up with dogshit performance - like the new windows terminal (not sure if they've fixed it yet).
Caching glyphs is good resource management and with modern screen resolutions, color displays and subpixel-antialiasing you just simply need more than 70KB of RAM.
> The alternative is that for every glyph you render the entire glyph to the screen using the Bezier curves from the font
No, because you have no reason to have much more glyphs in your font cache than what fits your screen either (for people using a language with an alphabet based on the latin one at least, which is the majority of people on this website).
> you just simply need more than 70KB of RAM.
I didn't set the bar to 70kB. You also need more than 70kB of RAM yo store a full screen worth of image (which was the bar I set above).
The GP to your original did set the bar at 70kB, mattmanser then explained that images and fonts easily exceed that, and then you called that poor resource management. Sounds like we're on the same page here, but you seemed to have missed the context of the comment you initially replied to.
> And I maintain that the difference cannot be explained by images and font cache alone.
It can't be explained by images and fonts alone, I agree, but images and fonts alone are still enormous compared to 70kB. On my screen an "e" on this site is 10*11 pixels. Subpixel positioning means we need at least 6 copies of each letter, subpixel antialiasing means we need three channel alpha (3 bytes per pixel), we have variations of bold, italic and bold-italic, 95 printable letters in ascii, that's a low-ball of 750kB for one size of one font. This comment page alone has 4 different sizes, I'd expect a chat app to have a few more.
Well even with your quite conservative calculations [1] you end up with a size that is absolutely reasonable and negligible in a 100MB footprint.
[1]: Realistically, you're never gonna have all 95 characters in all weights for all font size, so the actual number is going to much significantly lower than the theoretical envelope. In practice, there'll be a main (font,size), that will have all glyphs (and it's going to be more than 95 because of the ligatures) in normal weight and no italic, with a subset of the glyphs in the three other modes, most likely not evenly distributed between modes. Then you'll have additional fonts (for UI labels, titles, etc) that are going to have much less represented glyphs and almost no variations of weight or italic if at all. Obviously the font(s) used for titles in going to have a bigger budget relatively to the glyph sample size, because each one is bigger than your baseline "e"
Completely agree, it would be very helpful to get even just a breakdown of what the ram is being used for. It's unfortunately a lot of work to instrument.
> sublime consumes 200mb. I have 4 text files open. What is it doing?
To add to what others have said: Depending on the platform a good amount will be the system itself, various buffers and caches. If you have a folder open in the side bar, Sublime Text will track and index all the files in there. There's also no limit to undo history that is kept in RAM.
There's also the possibility that that 200MB includes the subprocesses, meaning the two python plugin hosts and any processes your plugins spawn - which can include heavy LSP servers.
This sounds disingenuous. How does your grandma fare on Windows? Can your grandpa even navigate Linux? For all I know, your grandma could be a HN user and your grandpa a plumber.
She's significantly worse with technology than he is. Neither could tell you what an operating system is. These are exactly the type of average people that supposedly Linux isn't good enough for.
Yes, you can simultaneously use full-quality source and sink (speaker and microphone) streams [0]. And from personal experience, this works exactly as you would expect.
As you've seen, the documentation on LE Audio is rather horrible. The Android documentation [1] is semi-useful even on other platforms, and the official book [2] is also helpful if you're willing to wade through a ton of dense technical details, but there's not really much else available on the internet. I've had to spend an annoying amount of time tracing stuff with Wireshark and reading through the specifications [3] (which are thankfully free) and the BlueZ source code [4] to figure stuff out.
(The poor documentation mostly only matters if you're trying to do something specific; LE Audio mostly "just works" on Android out-of-the-box and Linux after you change the single config setting from [0])
In my experience, it's a significant improvement, but I wouldn't call it a solution. If non-LE drop in quality is like 1/10, with LE it's like 6/10.
I should point out that unlike the other reply I haven't really bothered researching it at all, I just upgraded from a non-LE pair to a LE pair recently.
Not sure why you're taking the rk3588 as a milestone for ARM, when it's a low end chip using core designs that were old when it released. Cortex-A76 is from 2018, so if that's the yardstick then the K3 is 8 years behind. Even then at the time the A76 was released Apple was significantly ahead with their own ARM CPUs.
I can't find anything related to division returning an error type. Looking at std.math.divExact, rem, mod, add, sub, etc. it looks to me like you're expected to use these if you don't want to panic.
Actually you're right, I was going by the source code which was in the link of the comment you replied to, but I missed that that was specifically for divExact and not just primitive division.
reply