Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS Sonoma 14.4 might break Java on your machine

appleinsider.com

Post reply on HN
Print view View original

241–250 of 271 posts

Re: macOS Sonoma 14.4 might break Java on your machine

#241

Post by bdavbdav »

self_awareness wrote: post #156
addicted wrote: post #93

Earlier quoted context omitted.

The reputation was well earned when Linux on the Desktop wasn’t as easy or friendly as it is today and was severely lacking good quality GUI applications. Windows was a virus laden mess and was not useful for running Linux apps. And besides the flaws of the other OS’es, OS X had some of the nicest window management features (Expose from the Snow Leopard is still my favorite window switcher), was a UNIX and had a thri…

> And besides the flaws of the other OS’es, OS X had some of the nicest window management features I'm always confused by such statements, because what KDE offers on Linux easily dwarfs every window management concept in every major OS. I always need to install additional third-party apps (e.g. Rectangle on macOS) to get a poor-man's equivalent of KDE-style window management functionality.

But I don’t have a subset of apps that work in x11, and a subset in wayland… nor inconsistent display fractional scaling in MacOS. Wanted to love KDE, but in complex setups, it’s difficult.

Re: macOS Sonoma 14.4 might break Java on your machine

#242

Post by arghwhat »

quotemstr wrote: post #207
arghwhat wrote: post #186

Earlier quoted context omitted.

This did not improve performance, it was just an unnecessary hack. The authors agree, as they removed it realizing it was not an optimization. UNIX signals are in no way or form direct translations of hardware CPU traps. The kernel handles hardware traps, which may or may not lead to UNIX signals. Heck, with userfaultfd, a different userspace process could be handling, or injecting, the fault! Not to mention VMs, whe…

Please, knock it off with the value judgements. "Ill-advised" according to whom? You? Why should your opinion prevail? > This did not improve performance, it was just an unnecessary hack Well, the Android VM certainly uses a signal mechanism for safepoints and stack overflow checking, for a reason ( https://android.googlesource.com/platform/art/+/master/runti... ) (both latency and code size), so don't sit there and…

> 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. :)

Re: macOS Sonoma 14.4 might break Java on your machine

#243

Post by arghwhat »

quotemstr wrote: post #205
arghwhat wrote: post #193

Earlier quoted context omitted.

> Also, there's a lot more you can do in a signal handler than just set a flag: you can longjmp or even make calls to regular functions. ... As long as the called functions are fully async-signal-safe/reentrant. It used to be even more sensitive, in that not all register state was correctly saved/restored on Linux. (On the fabled plan9, where signals are replaced with arbitrary-text "notes", the issue is even bigger…

> As long as the called functions are fully async-signal-safe/reentrant. 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. > It used to be even more sensitive, in that not all register state wa…

> 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, timeout or sigmask pointers. A sleeping process cannot segfault.

If you register a SIGSEGV handler, you have zero guarantees that it will only fire at a particular time in your code as it is delivered on any pagefault from any code accidentally generating it. This is why the async-signal-safe rules apply.

If you try handling such fault, what needs to be reentrant is the full call stack that lead to the fault, and every call made from the handler. If, for example, the fault is generated from an event loop handler (in case of a single-threaded example, most things run off event loop handlers), the signal handler must in turn not touch the event loop (no adding/removing/adjusting events, no dispatch) unless the event loop is fully reentrant.

Re: macOS Sonoma 14.4 might break Java on your machine

#244

Post by tuananh »

merlindru wrote: post #162
SpaghettiCthulu wrote: post #153

Earlier quoted context omitted.

But both are awful compared to the other terminal emulators available. My favourites are alacritty and kitty.

IMO Windows Terminal is amazing Good design, great performance, great text rendering Has tabs, themes, quake mode, a settings UI, and keyboard shortcuts (that you can rebind) On macOS, I like iTerm2 a lot!

> great performance

compare with what?

Re: macOS Sonoma 14.4 might break Java on your machine

#245

Post by quotemstr »

arghwhat wrote: post #243
quotemstr wrote: post #205

Earlier quoted context omitted.

> As long as the called functions are fully async-signal-safe/reentrant. 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. > It used to be even more sensitive, in that not all register state wa…

> 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 zero guarantees that it will only fire at a particular time in your code as it is delivered on any pagefault from any code accidentally generating it

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. In principle, you can do the non-reentrant thing after having checked that the signal came from the context you expect, and you can do this checking in an async-signal-safe manner.

> If, for example, the fault is generated from an event loop handler (in case of a single-threaded example, most things run off event loop handlers), the signal handler must in turn not touch the event loop (no adding/removing/adjusting events, no dispatch) unless the event loop is fully reentrant.

Of course. That's a matter of program design.

Re: macOS Sonoma 14.4 might break Java on your machine

#246

Post by quotemstr »

arghwhat wrote: post #242
quotemstr wrote: post #207

Earlier quoted context omitted.

Please, knock it off with the value judgements. "Ill-advised" according to whom? You? Why should your opinion prevail? > This did not improve performance, it was just an unnecessary hack Well, the Android VM certainly uses a signal mechanism for safepoints and stack overflow checking, for a reason ( https://android.googlesource.com/platform/art/+/master/runti... ) (both latency and code size), so don't sit there and…

> 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 general. See https://github.com/openjdk/jdk/blob/9059727df135dc90311bd476...

> Be careful with fallacies suggesting only one side of an argument is based on opinions. :)

The wonderful thing about choosing not to care about facts is having whatever opinions you want.

Re: macOS Sonoma 14.4 might break Java on your machine

#247

Post by piyush_soni »

Wowfunhappy wrote: post #235
piyush_soni wrote: post #232

Earlier quoted context omitted.

Oh ... Where to begin. I can write an essay on it, but just to name a few: 1. There's a button on my M3 Mac keyboard that says 'delete'. It deletes stuff everywhere else, but welcome to Finder, this simple button doesn't delete a file or a folder. They thought giving it a two/three keys combination was a better idea. 2. Similarly, they thought you rename file/folders more often in a day than you open them. Why else w…

> There's a button on my M3 Mac keyboard that says 'delete'. It deletes stuff everywhere else, but welcome to Finder, this simple button doesn't delete a file or a folder. They thought giving it a two/three keys combination was a better idea. It would be pretty darn annoying if an accidental key press could just delete a file! > No 'Cut' (I know the alternatives). One might find it surprising but there are fans that…

> It would be pretty darn annoying if an accidental key press could just delete a file! : - Isn't the 'Bin' made exactly for that purpose? And also, just like any other accidental delete, Undo is always there. Very easy!

> The problem is, where does a file go in between the time you cut and you paste? : - It doesn't have to go anywhere, it's just "marked for" 'cut', just like a file marked for copying doesn't go anywhere until you paste it. All other Operating Systems have got it exactly right for eons. If you accidentally copy something else, that mark is removed, and the file is still happily sitting where it was. (Windows even shows it visually in their File Explorer). No safety hazard. I don't understand your other point - be it my entire life's work, it's always at one place or the other. It can't go to a third place, and in any case Undo and Bin are always there. At least in Windows moved files go back to their previous places on Undo. This is a much more intuitive default, making sure a recovery option is always there for exceptions.

> `View` → `Show Path Bar` : Yes, that's what I had done, but imagine having a proper address bar which both tells you where you are, and is editable so can be used to paste a new address to go to. That will be much more intuitive, and that's what other OSs have done.

> Click the gear in the toolbar → `paste`. : I don't see a gear icon, but sure, I can also do it using Cmd+V and also from the Edit Menu. But a 'Paste Item' is still there in the Context menu that is unusable in a lot of situations. Wasn't Steve Jobs really particular about pixel perfectness? I don't see that here.

I didn't even talk about my other problems with this OS especially when you use non-Apple hardware. I just want to point out that unlike what a lot of people believe, Windows (and even modern Linux) UI is much more intuitive and arguably causes less repetitive strain injury to our hands with more frequent OS operations made easier. The only thing I had found great in Mac's UI was Spotlight (though even that leaves a lot to be desired), but Windows now offers that too under their new PowerToys fleet of applications (less capable in some places but it should only get better) and I think people should give it a try.

Re: macOS Sonoma 14.4 might break Java on your machine

#249

Post by kjkjadksj »

galdosdi wrote: post #240
kjkjadksj wrote: post #216

Earlier quoted context omitted.

Why? Macos is already a unix os.

Everyone says this until they're spending their whole weekend working around some weird tiny differences in between a GNU tool and something that comes with OSX or homebrew or something. And when you finally get it working you have the "satisfaction" of knowing you bought NOTHING of value with all that wasted time -- just the opportunity to be able to use FaceTime on the same laptop you develop on, or something. If y…

One line into the cli and you can have your gnu tools installed. Its no harder to manage software environments in mac than it is in linux because you can use the same tools. I use conda on mac and the linux server that does the compute. I could use docker too if i wanted.

Re: macOS Sonoma 14.4 might break Java on your machine

#250

Post by hollandheese »

okamiueru wrote: post #228
hollandheese wrote: post #225

Earlier quoted context omitted.

>Don't like that apple's "Music" app pops up when you connect a Bluetooth headset? => Install an app. Get a better bluetooth headset that doesn't send play when it connects. That's the problem. It's the headset that's doing something wrong.

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't happen to be working at Apple R&D?

IT IS THE HEADSET DOING SOMETHING WRONG! No one asked it to send play when it connects, the manufacturer decided to do something brain dead there. It still messes with Windows and Linux machines too if you set the play/pause button to launch an app.

Do you happen to work for a bluetooth headset manufacturer? It sure sounds like you're excusing their broken behavior.

Post reply on HN