4 ms·

Ok since these types of threads are typically filled with complaints, just to add another data point: I’ve upgraded last week and have not experienced any probl

Ok since these types of threads are typically filled with complaints, just to add another data point: I’ve upgraded last week and have not experienced any problems at all. And yes, I’m using USB hubs, printers and even Java.

CharlesW 3y ago
I feel bad for folks experiencing problems, but the upgrade was uneventful on my Macs as well. Work also rolled out the update company-wide with no apparent ill effects, which is surprising given all of the enterprise-y junk they install.
- tetris11 3y ago
  I wonder if this is some kind of warped A/B testing with "stable" upgrades from Apple
mike_hearn 3y ago
Is that on an M1? Apparently the Java issue only affects Apple silicon for some reason
- lolinder 3y ago
  Most of the time with these update problems it's way more specific than that. It'll be an Apple silicon chip with a very specific system state, creating a low number of high profile errors that are indistinguishable from random. It's still often a good idea to wait a few days or weeks before updating just in case you're caught by the bugs, but the rates of errors are usually much lower than the mainstream media reporting would lead you to believe.
- shagie 3y ago
  From 2020 https://www.securemac.com/news/arm-macs-faq https://www.securemac.com/news/arm-macs-faq > Write XOR execute (W^X) > Apple Silicon Macs will enforce a restriction called “write XOR execute” (W^X). This means that chunks of memory will be designated as writable, or as executable, but never as both at the same time. Many macOS apps contain performance optimization programs that require memory to be both writable and executable, but this can lead to serious security issues. By enforcing W^X, Apple will harden Mac security at the memory level. App developers, however, won’t be left out in the cold — if they still need those optimization programs for their apps, they can use a new macOS API that provides a way to switch between write and execute permissions quickly and safely. And the nature of W^X - https://en.wikipedia.org/wiki/W%5EX https://en.wikipedia.org/wiki/W%5EX > W^X ("write xor execute", pronounced W xor X) is a security feature in operating systems and virtual machines. It is a memory protection policy whereby every page in a process's or kernel's address space may be either writable or executable, but not both. Without such protection, a program can write (as data "W") CPU instructions in an area of memory intended for data and then run (as executable "X"; or read-execute "RX") those instructions. This can be dangerous if the writer of the memory is malicious. W^X is the Unix-like terminology for a strict use of the general concept of executable space protection, controlled via the mprotect system call. --- See also Porting just-in-time compilers to Apple silicon - https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon https://developer.apple.com/documentation/apple-silicon/port... And W^X now mandatory in OpenBSD (8 years ago : https://news.ycombinator.com/item?id=11789169 https://news.ycombinator.com/item?id=11789169 )
  - mike_hearn 3y ago
    The JVM has worked fine on macOS and Apple Silicon for years. It's not violating W^X. The problem is an undocumented/unannounced and probably unintended change in kernel behavior.
    - dylan604 3y ago
      Shouldn't this help zero in on where the issue is located? If it did not occur in the last released beta but it now exists in the released update, doesn't that significantly reduce the footprint of where to search for changes?
      - shagie 3y ago
        From a discussion on it previously : https://news.ycombinator.com/item?id=39741517 https://news.ycombinator.com/item?id=39741517 by fweimer > 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/29397d29baac3b29083b1b5d6b2cb06e456af0c3 https://github.com/openjdk/jdk/commit/29397d29baac3b29083b1b... > On current CPUs and operating systems, this is not an optimization, so the code was removed earlier this year: https://bugs.openjdk.org/browse/JDK-8320317 https://bugs.openjdk.org/browse/JDK-8320317 (there's a lot more comments further down that are worth reading) It is known where this is causing a problem and the code was removed a few months ago in the code for Java 23.
  - acdha 3y ago
    Java has worked great on Apple Silicon since release and it’s still working great now for most users. The linked post explains that Java is already using the W^X modes but there’s an edge case involving page faults while the JIT is updating pages, which to me seems suspiciously like an attempted security improvement which needed better testing: https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860 https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860
- stingraycharles 3y ago
  Using M2 Pro, but mostly using Java through the version installed by MacPorts.
samstave 3y ago
[flagged]
- nameless912 3y ago
  uh...what?
  - samstave 3y ago
    [flagged]
    - transcriptase 3y ago
      Gear down big rig. Your HN account is 15 years old, you should be familiar with etiquette here by now.
    - kstrauser 3y ago
      Fine, but… USB hubs? I bet they’re more popular now than ever since you can use them as docking stations now.
    - boesboes 3y ago
      Chill a bit mate, someone didn't get you joke. No need to be a cunt about it.
JacobiX 3y ago
I've also updated my M1 Pro to macOS 14.4 and use Java (versions 21 and 17) daily with IntelliJ IDEA without encountering any issues so far even when using debuggers and profilers. Not sure how to explain it !
travisgriggs 3y ago
Same for me. On an M1
danaris 3y ago
I, too, have had no trouble with USB hubs or Java since upgrading to 14.4. (I don't currently use a USB hub—my Thunderbolt dock has been fine, but I doubt it's close enough to count!)
microtonal 3y ago
Me neither. The thing is that at the scale of an operating system like macOS or iOS is that even if only 1% of its users encounter an issue, it's still a lot of people. Enough to fill many discussion boards with complaints.
- dehrmann 3y ago
  Apple doesn't have long tail support in its DNA. Its used to supporting 5 years of devices with just a handful of SKUs per generation. In contrast, Microsoft is used to supporting a huge variety of hardware and keeping it working.
turquoisevar 3y ago
Same here on two Apple silicon machines. In fact, I used to get kernel panics from time to time with USB hubs until a couple of major revisions ago. What I’m running now, in part via monitor USB hub, is so far beyond the scope of what I expect to be part of QA and intended support that I’m surprised it’s not giving me any issues.

CharlesW 3y ago

I feel bad for folks experiencing problems, but the upgrade was uneventful on my Macs as well. Work also rolled out the update company-wide with no apparent ill effects, which is surprising given all of the enterprise-y junk they install.

tetris11 3y ago
I wonder if this is some kind of warped A/B testing with "stable" upgrades from Apple

mike_hearn 3y ago

Is that on an M1? Apparently the Java issue only affects Apple silicon for some reason

lolinder 3y ago
Most of the time with these update problems it's way more specific than that. It'll be an Apple silicon chip with a very specific system state, creating a low number of high profile errors that are indistinguishable from random. It's still often a good idea to wait a few days or weeks before updating just in case you're caught by the bugs, but the rates of errors are usually much lower than the mainstream media reporting would lead you to believe.
shagie 3y ago
From 2020 https://www.securemac.com/news/arm-macs-faq https://www.securemac.com/news/arm-macs-faq > Write XOR execute (W^X) > Apple Silicon Macs will enforce a restriction called “write XOR execute” (W^X). This means that chunks of memory will be designated as writable, or as executable, but never as both at the same time. Many macOS apps contain performance optimization programs that require memory to be both writable and executable, but this can lead to serious security issues. By enforcing W^X, Apple will harden Mac security at the memory level. App developers, however, won’t be left out in the cold — if they still need those optimization programs for their apps, they can use a new macOS API that provides a way to switch between write and execute permissions quickly and safely. And the nature of W^X - https://en.wikipedia.org/wiki/W%5EX https://en.wikipedia.org/wiki/W%5EX > W^X ("write xor execute", pronounced W xor X) is a security feature in operating systems and virtual machines. It is a memory protection policy whereby every page in a process's or kernel's address space may be either writable or executable, but not both. Without such protection, a program can write (as data "W") CPU instructions in an area of memory intended for data and then run (as executable "X"; or read-execute "RX") those instructions. This can be dangerous if the writer of the memory is malicious. W^X is the Unix-like terminology for a strict use of the general concept of executable space protection, controlled via the mprotect system call. --- See also Porting just-in-time compilers to Apple silicon - https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon https://developer.apple.com/documentation/apple-silicon/port... And W^X now mandatory in OpenBSD (8 years ago : https://news.ycombinator.com/item?id=11789169 https://news.ycombinator.com/item?id=11789169 )
- mike_hearn 3y ago
  The JVM has worked fine on macOS and Apple Silicon for years. It's not violating W^X. The problem is an undocumented/unannounced and probably unintended change in kernel behavior.
  - dylan604 3y ago
    Shouldn't this help zero in on where the issue is located? If it did not occur in the last released beta but it now exists in the released update, doesn't that significantly reduce the footprint of where to search for changes?
    - shagie 3y ago
      From a discussion on it previously : https://news.ycombinator.com/item?id=39741517 https://news.ycombinator.com/item?id=39741517 by fweimer > 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/29397d29baac3b29083b1b5d6b2cb06e456af0c3 https://github.com/openjdk/jdk/commit/29397d29baac3b29083b1b... > On current CPUs and operating systems, this is not an optimization, so the code was removed earlier this year: https://bugs.openjdk.org/browse/JDK-8320317 https://bugs.openjdk.org/browse/JDK-8320317 (there's a lot more comments further down that are worth reading) It is known where this is causing a problem and the code was removed a few months ago in the code for Java 23.
- acdha 3y ago
  Java has worked great on Apple Silicon since release and it’s still working great now for most users. The linked post explains that Java is already using the W^X modes but there’s an edge case involving page faults while the JIT is updating pages, which to me seems suspiciously like an attempted security improvement which needed better testing: https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860 https://bugs.java.com/bugdatabase/view_bug?bug_id=8327860
stingraycharles 3y ago
Using M2 Pro, but mostly using Java through the version installed by MacPorts.

samstave 3y ago

[flagged]

nameless912 3y ago
uh...what?
- samstave 3y ago
  [flagged]
  - transcriptase 3y ago
    Gear down big rig. Your HN account is 15 years old, you should be familiar with etiquette here by now.
  - kstrauser 3y ago
    Fine, but… USB hubs? I bet they’re more popular now than ever since you can use them as docking stations now.
  - boesboes 3y ago
    Chill a bit mate, someone didn't get you joke. No need to be a cunt about it.

JacobiX 3y ago

I've also updated my M1 Pro to macOS 14.4 and use Java (versions 21 and 17) daily with IntelliJ IDEA without encountering any issues so far even when using debuggers and profilers. Not sure how to explain it !

travisgriggs 3y ago

Same for me. On an M1

danaris 3y ago

I, too, have had no trouble with USB hubs or Java since upgrading to 14.4. (I don't currently use a USB hub—my Thunderbolt dock has been fine, but I doubt it's close enough to count!)

microtonal 3y ago

Me neither. The thing is that at the scale of an operating system like macOS or iOS is that even if only 1% of its users encounter an issue, it's still a lot of people. Enough to fill many discussion boards with complaints.

dehrmann 3y ago
Apple doesn't have long tail support in its DNA. Its used to supporting 5 years of devices with just a handful of SKUs per generation. In contrast, Microsoft is used to supporting a huge variety of hardware and keeping it working.

turquoisevar 3y ago

Same here on two Apple silicon machines. In fact, I used to get kernel panics from time to time with USB hubs until a couple of major revisions ago. What I’m running now, in part via monitor USB hub, is so far beyond the scope of what I expect to be part of QA and intended support that I’m surprised it’s not giving me any issues.