251–260 of 271 posts
I find it difficult to imagine how a change like this (sending a SIGKILL to the process instead of SIGSEGV on a page fault) can be done in the final release and not in one of the EA releases or betas. It is clearly a breaking change with no easy workaround (since SIGKILL cannot be caught), for a behaviour which is well defined by POSIX. Even if you momentarily ignore the reasons why someone thought this could be a go…
Been saying this for as long as I’ve been using macOS: it is not a developer friendly OS and am close to the conclusion that this reputation is a psy-op. Yeah it’s pretty, it mostly works when the box is first turned on and the hardware is unmatched but macOS itself is actually subpar. QA seems second tier, things you’d except from other OSes like, I don’t know, using a third party second display are just bad experie…
The hardware definitely keeps getting better and yet the software keeps getting worse. sigh.
I mean they have even screwed up a nice app like iBooks. I used to use it for reading ePubs all the time, but now I dread opening up one. Lags like crazy. And so many crashes and reboots needed. Keep submitting crash reports but fairly certain that no-one ever reads them.
Yes, remarkably today - the Windows desktop needs less reboots than macOS today. Can anecdotally confirm this with 2 windows PC's, 3 windows laptops and 3 Macbooks in the family.
Earlier quoted context omitted.
It's always something else doing something wrong. Everything has to conform to Apples design guidelines. Heaven forbid the OS could let you chose what you want to happen... like launching Spotify instead, or simply nothing at all... It's the headset doing something wrong. What a fascinating take. You wouldn't happen to be working at Apple R&D? Maybe I missed the /s, it's just too on the nose, almost as if you're ridi…
> Heaven forbid the OS could let you chose what you want to happen... like launching Spotify instead, or simply nothing at all. Yes, the OS could do that. I'd prefer if Apple made that key configurable. But the problem isn't Apple and Bluetooh Headsets, it's that Apple made the play/pause button unconfigurable (without additional software). >It's the headset doing something wrong. What a fascinating take. You wouldn'…
Compare it with
> - Don't like that apple's "Music" app pops up when you connect a Bluetooth headset? => Install an app
The only difference is that you add a puzzling self contradiction of "the problem isn't Apple, but that Apple has..."
This is entirely an Apple and MacOS thing, and most certainly not an issue on Linux. Though I don't know about Windows.
Earlier quoted context omitted.
Strange. I've got the complete opposite experience. Most displays work fine. It helps if you stick with models that advertise at least a bit of macOS support (like some Dells or Samsungs). Docker sucks, but there's Orbstack. I don't care for posix, but most of my *nix tools are available in Homebrew. Network is steady and more bulletproof than wireless on Linux. Is your experience based on a recent mac?
The problem with third party displays on the Mac is the system has some deeply held assumptions that all monitors are as pixel-dense as the ones which Apple ships with their machines. 100% DPI scaling for classic ~100ppi monitors is a poor experience since macOS no longer supports subpixel font rendering, and DPI scales higher than 100% but less than 200% are really just 200% in a trenchcoat because the system render…
As you know, subpixel rendering only works when you have a very specific display (i.e. LCD) since it takes advantage of, and hence relies on precise characteristics of how the pixels are physically laid out in the display.
This means that subpixel rendering fails to work on displays that have different layouts, the most recent example of this have been newer OLED displays (I think QD-OLED) which has a different pixel arrangement and then you ironically had Windows users complaining that the text looked jagged (although you are able to change the algorithm for subpixel rendering to match the QD-OLED, the unfortunate problem here is that its not really possible for this to work all for applications as it depends on which UI engine you are using, Windows is a giant mess here).
Long story short, I can see why Mac removed sub pixel rendering, its basically a workaround that reflected a time when you had less dense displays which were all LCD and had the same physical layout. Nowadays though high pixel density displays are a lot more common and then you don't need sub pixel rendering at all (and it works with all of the different physical pixel layout arrangements)
Earlier quoted context omitted.
Ok so you couldn’t list a better laptop . Any laptop is good docked and ignoring the noise with headphones. The only thing valuable of your response is the matte screen. Which can be fixed with a cheap Amazon film if wanted. Still with the glossy screen I can see my MacBook much better in direct sun than I can any matte HP elitebook I’ve used in the last 5 years. The sure view screens are actually almost unusable ind…
> Ok so you couldn’t list a better laptop I did. You just didn't want to listen. > Speakers bad in a MacBook? Come on man at least try to be objective. Mac users that list the laptop speakers as good are really digging in. It is marginally better than regular shitty laptop speakers, but it is still very shitty. Any cheap proper speakers are much better, to the point that listing it as a positive is misleading. And I…
Hate to be that guy, but you literally didn’t. Your “I honestly prefer using my 5 year old Dell G5” does not answer that question.
Earlier quoted context omitted.
The signal comes from a safe fetch, which is just a read that allows ignoring the fault as if it never happened. Such a signal is deliver synchronously, so the usual restrictions for asynchronous signal handlers do not apply. The code in question takes into account that the value read might be garbage. See the big comment here: https://github.com/openjdk/jdk/commit/29397d29baac3b29083b1b... On current CPUs and operat…
The "safe fetch" code relies on a signal handler (either here https://github.com/openjdk/jdk/blob/48717d63cc58f693f0917e61... or here https://github.com/openjdk/jdk/blob/3c70f26b2f3fa9bc143e2506... ), which is considered asynchronous delivery (i.e., delivered mid-execution, see `man 7 signal`) - which is why the `async-signal-safe` manpage simply states that it is functions that can safely be called within a signal h…
Earlier quoted context omitted.
> That is not accurate. If I have a single-threaded program sitting around a ppoll(2) loop and a signal can arrive only inside my main loop ppoll(), then I know a priori that my signal handler can't be interrupting non-reentrant code and so I can call whatever I want inside it. If you have a single-threaded program sitting in ppoll, you cannot ever receive a SIGSEGV during said ppoll unless you passed it bugus fds, t…
> you cannot ever receive a SIGSEGV during said ppoll Unless someone sends one with kill(2). Also, I was talking about signals in general, not SIGSEGV in particular. Who uses SIGSEGV as an async work dispatch mechanism? > unless you passed it bugus fds, timeout or sigmask pointers. A sleeping process cannot segfault. No, you get EFAULT. System calls don't work that way. > If you register a SIGSEGV handler, you have z…
`ppoll(2)` is a C library function you call. On glibc, depending on which implementation you hit on your architecture, the `ppoll` call will segfault before the syscall if you call it with bogus timeout or sigmask pointers, as glibc is dereferencing them.
> That's why you use sigaction(2) to register signal handlers --- your callback gets both a siginfo_t and a ucontext_t you can use to figure out whether your segfault came from a region of code you know about or some other random thing going wrong in your process.
It is true that you could try to figure out whether the faulting address is within a range you thought belonged to a particular thing, but I don't see any reason or benefit. However, this is fragile: Distinguishing between a page fault from a corrupt program state and a page fault in a valid program depends on the program state (specifically, inspecting memory that is likely foo), which in turn makes the output undefined. You won't get false negatives, but will get false positives. You could also try to establish a list of all program counter values (PIE/PIC caveats), and check if the signal originated from near those, but... Ugh.
Now, any other signal I could level with you, but not SIGSEGV. Not until I see some code where it's truly justified: a real, tangible benefit that can only be obtained in this fashion, justifying all the gymnastics and (in my opinion) nastiness of trying to handle a signal that should never be handled in the first place (not even for crash dumps, they're always worse than a proper core).
Earlier quoted context omitted.
> Please, knock it off with the value judgements. "Ill-advised" according to whom? You? Why should your opinion prevail? Ill-advised as per the authors decision to remove said hack as it brought none of the intended benefits. Or are you suggesting that your opinion is more valuable than the authors whose code we're discussing? Be careful with fallacies suggesting only one side of an argument is based on opinions. :)
The actual text from https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860 says this: > We have been working on a patch that switches the jit protection mode to EXEC around these potential faulting memory accesses. Yes, they're changing one aspect of signal handler use to work around this problem. They're not stopping the use of signal handlers in general . Hotspot continues to use signals for efficiency in gener…
This whole thread is about SIGSEGV, and specifically their SIGSEGV handling. However, catching normal signals is not about efficiency.
Some of their exception handling is still odd: There is no reason for a program that receives SIGILL to ever attempt continuing. But others is fine, like catching SIGFPE to just forward an exception to the calling code.
(Sure, you could construct an argument to say that this is for efficiency if you considered the alternative to be implementing floating point in software so that all exceptions exist in user-space, but hardware floating point is the norm and such alternative would be wholly unreasonable.)
> The wonderful thing about choosing not to care about facts is having whatever opinions you want.
I appreciate the irony of you making such statement, proudly thinking that your opinion equals fact, and therefore any other opinion is not.
This discussion is nothing but subjective opinion vs. subjective opinion. Facts are (hopefully, as I can only speak for myself) inputs to both our opinions, but no opinion about "good" or "bad", "nasty" or not can ever be objective. Objective code quality does not exist.