I once had a vexing problem with my old Intel MacBook — macOS failed to boot, but Windows seemed totally normal. Can't possibly be a hardware failure, right? The symptoms disappeared after replacing the SATA cable!
This reminds of the infamous GPU issues of the unibody models (the last non-retina ones). I have one such 2012 15" MBP which has a dedicated GPU which, as I understand it, has developed soldering issues.
Non-Mac OSs don't know how to turn this GPU on out of the box, so it just sits there without bothering anybody. But, for some reason, MacOS turns it on and it craps the bed, rendering the machine unusable.
I had the 2010 version of this model, with the same symptoms starting in mid 2011. I would get 5-8 crashes a day from the GPU being on the fritz.
Apple ended up replacing the mainboard in a free out-of-AppleCare repair. I never had the problem again and I used the machine regularly until about 2018.
In my case, it lasted one or two more years, and I only learned about the repair after they stopped offering it. By that time, the machine had already been replaced for other, unrelated reasons.
That’s the wrong way to look at it. Improving the performance of a complex piece of software is not something you do in one fell swoop, or even in a dozen smaller steps. It’s a job of compounding many tiny single–digit percentages over years, and of carefully avoiding performance regressions.
Be as impressed as you want but I think it is a very good sign that developers are taking care of it, and as this is a free to use product we can always be happy if someone boosts performance no matter how much
Very, if only because you'd have said I'm not sure how impressed I should be about saving 4.5 MB these days not all that long ago. Remember when emacs was backronymised to 'eight megabytes and constantly swapping'? That was also not all that long ago. Now 8 megabytes is what some pissant JS library takes as part of some miserable npm package used to bellyflop an ad into your browser window.
Just personal experience using LLMs. I've optimized a lot of things in the past year I wouldn't normally have time to do, especially build systems/pipelines.
"Saving X% of RAM" isn't a thing because RAM is itself a cache of compressed swap space and/or mapped files.
The lesson here is pointer-chasing data structures and trees are a lot more expensive than everyone and most programming languages like to pretend they are.
It's more than that, because generally performance is also much worse if you're using a shit ton of memory. That's because CPUs are bottlenecked by cache. So more memory means cache has to be flushed more often, and there will be more misses, which can greatly impact performance.
But they do keep the active tab of each window in memory. Firefox even continues rendering all active tabs in all windows, even if for windows which are not visible.
Not sure if this 45MB is per browser instance or per tab, but it’s the latter case, 10 windows would save 450MB. >10% on a lower-end device.
Reading a blog post about linux security? Do you actually care if the NSA/FBI/CIA/FDA/USDA or anyone else knows you read this particular blog post?
I could understand this argument if we were talking about a social media site, or something more substantial. But a blog post?
> authenticity
It's a linux security blog post. While it's technically possible for a MITM to get in between an inject false information... about linux security? Is that really a real threat?
> integrity
Maybe a real problem, assuming a malicious MITM is trying to target you. But, I suspect, there are other avenues that'd be more fruitful in that case. Just hoping that someone would visit an http site seems like a far fetched concern.
You are not the OP, but I think I was trying to point out this example case in relation to their descriptions of Error/Warnings.
This scenario may or may not yield in data/state loss, it may also be something that you, yourself can't immediately fix. And if it's temporary, what is the point of creating an issue and prioritizing.
I guess my point is that to any such categorization of errors or warnings there are way too many counter examples to be able to describe them like that.
So I'd usually think that Errors are something that I would heuristically want to quickly react to and investigate (e.g. being paged, while Warnings are something I would periodically check in (e.g. weekly).
Like so many things in this industry the point is establishing a shared meaning for all the humans involved, regardless of how uninvolved people think.
That being said, I find tying the level to expected action a more useful way to classify them.
But what I also see frequently is people trying to do the impossible and idealistic things because they read somewhere that something should mean X, when things are never so clearly cut, so either it is not such a simplistic issue and should be understood as not such a simple issue, or there might be a better more practical definition for it. We should first start from what are we using Logs for. Are we using those for debugging, or so we get alerted or both?
If for debugging, the levels seem relevant in the sense of how quickly we are able to use that information to understand what is going wrong. Out of potential sea of logs we want to see first what were the most likely culprits for something causing something to go wrong. So the higher the log level, the higher likelihood of this event causing something to go wrong.
If for alerting, they should reflect on how bad is this particular thing happening for the business and would help us to set a threshold for when we page or have to react to something.
It would be more plausibly practical if GHC could now target wasm, but this announcement is actually about being able to run the compiler itself in the browser.
I have burned git into my brain, so it's no longer hard to me. OTOH, I only pull out jq once every six months or so, and I just barely scrape by every time.
