macOS Sonoma 14.4 might break Java on your machine
appleinsider.com
appleinsider.com
Even if you momentarily ignore the reasons why someone thought this could be a good idea, why not do it in one of the pre-releases or betas??? Doesn’t look like the kind of thing you’d want to do in a last minute change.
The real problem in my opinion is the fact that you cannot go back after a macOS upgrade. So if something like this happens, you literally have no option but waiting for Apple to release a fix, if they want to do it at all.
The good kernel engineers are working on iPhone or Vision Pro, not on MacOS
Technically it is kind of the same, but with different set of configured features.
Already a bit oldie,
"Mac OS X and iOS Internals: To the Apple's Core"
https://www.amazon.com/Mac-OS-iOS-Internals-Apples/dp/111805...
Unless I missed something and the DMA requirement is along the lines of "having to allow other browser engines as long as they don't bring their own JITting Javascript engine", no, it literally can't.
And you know, you’re one web search away from finding the page where Apple directly mentions access to a JIT for alternative browsers: https://developer.apple.com/support/alternative-browser-engi...
code review: self-reviewed
test plan: this change is so obvious no tests are needed those who don't know: ^_^
those who know: -_-I do not have very kind words for Apple's dev teams today. Charitably I am trying to think that screwups happen, but this is bad and it is very hard to see how anyone thought merging it into an rc was okay.
The hardware is not even that good. I presume people like it because it looks slick and serves as a status symbol.
How dare someone doesn't like a MBP?
My workplace provides me with a MacBook yes.
I honestly prefer using my 5 year old Dell G5.
I absolutely hate MacBook screen. It's reflexive, whereas I very much favor the matte finish of basically every other manufacturer.
Fan noise for me is essentially irrelevant. Not that my Dell makes that much noise anyway. I am normally listening to music while I work, and when gaming there's in game sound.
Speaker quality is shit on either laptop. My cheap speaker/subwoofer set that is connected to the docking system is leagues better than the laptop speaker (that I never use anyway).
Touchpad is... as bad as any other touchpad? I use a mouse for a reason.
Battery life is the only thing a MacBook would have in its favor. Again, irrelevant. 99% of the time it is plugged into power.
MacBook comes with a major downside of being tied to OSX however. This cannot be understated.
I think macOS has the worst window management of any major OS especially for power users. It's so bad that buying a half dozen third party apps to "fix" the UX disaster that is macOS has basically been normalized.
I don't like any touchpad so even if a MacBook touchpad is better it's still just the best worst method for mouse input.
I think Apple makes nice hardware though. But I also work docked basically 99% of the time and use it as a desktop replacement so many of the Apple hardware advantages are moot for me. I'm kind of shocked when I see people voluntarily working on a laptop undocked. Working with a crappy keyboard, a crappy touchpad, and a small screen is torture to me even if it's the best crappy keyboard, the best crappy touchpad, and the best small screen.
I use it undocked very rarely, to the point that those hardware advantages are irrelevant.
The downsides are still there when docked however (the horrible glossy screen and the awful OS I have to handle).
Do you use full screen windows ?
Speakers bad in a MacBook? Come on man at least try to be objective.
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 can use my boring Dell with my windows open on a sunny day without issues. MacBook requires me to close the blinds.
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.
"Any manufacturer that provides hardware that has screen with a matte finish and whose hardware is not tied to a shitty OS".
* lack of usb ports necessitating dongles * lack of hdmi/dvi outs * No camera lens cover * Uncomfortable chiclet keyboard * oversized touchpad * overheating * lack of power cores leads to slower parallel compilations
I do appreciate the ease of use of (especially) the network utilities of mac, but it's definitely not my preferred machine.
At least Dell supports their hardware: have you tried updating the monitor firmware or submitting a report?
It's not unusable if you at least have one of those medium density 4K monitors, but it feels like a step backwards if you're used to Windows which still (mostly) supports subpixel font rendering for crisp text at 100% scale, and can render natively at 125/150/175% scales.
Another factor is that focusing on pixel density above all else comes at the expense of pixel speed, there are no large monitors which meet Apples 220ppi standard and have a refresh rate of 120hz or better, no matter how much money you're willing to spend, they just don't exist.
I think the display resolution market suffers from some opposing directions: people who do productivity work like high resolutions, but since Windows (majority of the market) still seems to struggle to scale UI elements correctly some people prefer lower resolution. Also, gamers associate high resolutions with heavy GPU requirements or lower framerates. And then there are companies that are used to spending the absolute minimum on screens that are barely 1080p.
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)
I gotta disagree hard here. Macs have by far the most obnoxious and temperamental WiFi stack I've ever experienced. Constant disconnects, have to turn it off and on to get it to bother looking for APs again. All of them constantly trigger bad experience scores in UniFi.
Absolutely subpar compared to any of my Linux devices, even the raspberry pi jammed inside a metal box.
Is the problematic corporate Mac an M-series Mac or Intel?
M-series have been great in my experience. I did used to get random full system crashes on Intel Macs which haven't happened in a few years on M1/M2.
Why they'd let the system become unstable rather than killing some apps that are too much goes beyond my understanding.
I often have to re-center the balance, it's driving me nuts.
inside a function that can be preempted
Your explanation makes a lot more sense as x86 is probably the only time I’m pushing the cpu usage high enough.
The popping is darn annoying
I'm finding this with software everywhere. Products keep doing the same old stupid shit they did when they were first released. "Refinements" are poorly-designed cruft.
Is there anyone in charge of the OS X experience? There seems to be a lot of resume development - features that can be illustrated with smiling people in a video but don't really work all that well - and not so much interest in the core UX.
I still find it better than Windows, but the gap between what it could be and what it is keeps growing.
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 would they make you press two keys to open one, and the most common single button in the world to open files (Enter/return) to rename one instead?
3. No 'Cut' (I know the alternatives). One might find it surprising but there are fans that defend even this move - they say it's because this is more "intuitive". You only copy everything first and only at the time of pasting you decide whether you want to move it or copy it. I say, if that's really the case, why does every other app and Editor (including the ones made by Apple) have a Cut option? Why don't we always follow this more intuitive method of "copying" first and then pressing the Option button while pasting. Let's remove Cut from everything and see how intuitive people find it.
4. By default, the Finder doesn't even tell you where you are. That's a basic requirement from a File Manager. Sure, fiddle with the settings and at some place you'll find an option to kind of enable that.
5. No option to quickly create a text/other file in a given folder. If you've struggled enough and enabled the view where you're able to see where you are at the moment, there's a _chance_ you'd also see that from that view you can actually go to Terminal directly in that folder. Go there, and type `touch <filename>` to create a file in that folder.
6. You got a full path to go to somewhere on the disk. You quickly open Finder. Oh, the default view doesn't even have a place to paste it and hit Enter. Who could have thought to hide it? Same problem with the native 'File Open' dialog that's used by all the other apps on the system. Even if you have the full file path, unless you go to settings you won't find a way to go to that file directly.
7. No easy (if at all) way to persistently map a network drive that automatically remaps when the network drive is available. You have to keep connecting to the SMB server again and again.
8. Side bar folder shortcuts get removed when the folder is deleted and recreated for any reason. You have to recreate them. Not sure who made all these decisions or if they were even thought about.
9. No straight way to even 'Refresh' the files in a folder. Try going out and in, closing and reopening Finder and just 'hope' that it will update and show the newly created files or changed file properties outside. Many times it just doesn't.
10. 'Get Info' allows you to also 'Set' (a lot of) Info. This is UX 101. They could have just named it `Properties` instead.
11. Hell, you can't even maximize this app window by double clicking on the Title bar, unlike for example another Apple made app 'App Store'. No consistency.
12. In List view there's no padding, I can't even find a place where I can right click and paste a previously copied file in the 'current folder', without it hitting a subfolder and pasting the files into that instead (assuming the folder has many folders inside). I'm surprised no one found it in internal user testing.
These are just off top of my head, I'm sure I can find more if I spend some time. There might be involved solutions to these, but there's no way we can call this an 'intuitive' interface. And this is just one application in the whole Operation System.
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 defend even this move - they say it's because this is more "intuitive". You only copy everything first and only at the time of pasting you decide whether you want to move it or copy it. I say, if that's really the case, why does every other app and Editor (including the ones made by Apple) have a Cut option? Why don't we always follow this more intuitive method of "copying" first and then pressing the Option button while pasting. Let's remove Cut from everything and see how intuitive people find it.
The problem is, where does a file go in between the time you cut and you paste? If you accidentally copy something else to your clipboard, do you loose the entire file? Does the file appear in the Trash or is it deleted permanently?
You could argue that the same problem exists for non-file content (like text) which Apple allows you to cut. I think files and folders are a bigger deal, though. There's a practical limit to how much you can highlight. A folder might contain your entire life's work. (Yes, hopefully you have backups, but better to not reach that point.)
> By default, the Finder doesn't even tell you where you are. That's a basic requirement from a File Manager. Sure, fiddle with the settings and at some place you'll find an option to kind of enable that.
`View` → `Show Path Bar`? I agree it should be enabled by default but it's so easy to change! You can also right click the folder icon at the top of the window, but Apple made this much more difficult beginning in macOS 11.
> You got a full path to go to somewhere on the disk.
I don't think non-developers ever end up in this situation. Those who do can use `Go` → `Go to Folder...`. I realize it's not in the toolbar but it's right in the menu bar.
> In List view there's no padding, I can't even find a place where I can right click and paste a previously copied file in the 'current folder', without it hitting a subfolder and pasting the files into that instead (assuming the folder has many folders inside).
Click the gear in the toolbar → `paste`.
---
I think your other points are valid, and I think the Mac's UX has declined a ton ever since OS X 10.9 in 2013. But I feel quite strongly the above complaints are merely different from other operating systems (and thus what you are used to), not actually worse.
> 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.
It has been a pretty frustrating experience at times. Most of the time is _fine_, but the problems after updates, Docker bugs, certain libraries that we cannot install..
On the other hand, it was never perfect with Linux either. But that was expected. And I can say that macOS does not deserbe the reputation it has.
Overall, kind of a mixed bag. There are some very nice aspects to both he hardware and software, but some that are jarring and make me thing "this is not really meant for professional users". Like the atrocious window management (that admittedly can bve fixed with a couple free applicaitons).
It's been a long time since I ran a Macbook, but this was my biggest problem. The weird uncanny valley where its almost the same but then not.
WSL has problems but there's a very clear line in the sand between Linux and Windows and you know what you're getting.
My opinion and experience is the exact opposite. In fact, I switched to Macs BECAUSE of how good macOS was for development and just general work and daily life.
Around 10-12 years ago I got an iPad, my first ever Apple purchase, as a gift for my aunt. I loved how simple and clean iOS was and found the apps and games interesting, so I thought I'd dabble in iOS dev. I was on Windows 8 at the time (and already sick of Microsoft's bs) so I downloaded a VMWare image for Mac OS X Lion.
As the days went by I found myself spending more time in macOS than in Windows, and enjoying it! A month later I bought my first ever MacBook and never looked back.
Well, sometimes I do look back at Windows, in a VM on macOS, just to try some games, and man, it's still a sad joke in 2024.
Macs are finnicky with hardware (but hdmi sucks by definition, they think you bought the cable and monitor to pirate movies and not to do some work).
However the GUI actually works and if you spend a week on windows 10+ you'll remember why people buy Mac OS.
Personally I have a Mac for stuff that requires a GUI and a headless linux box that I ssh into. And I switched to Macs from ... Linux on the desktop.
Edit: docker is shit because they just install a Linux VM and run their Linux stuff in there. Same on Windows I guess.
macOS is just so clunky. It tried to be so smooth all the time but just ends up being annoying.
So far I haven't managed to turn off the firewall scare popups, I did manage to remove that crap in the task bar that pops up the weather and selected news covering half the screen if you hover in the wrong place, I may or may not have turned off the OneDrive upsell, and I also got a full screen message to upgrade to 11 for free when booting once.
Great user experience overall. And don't tell me I can spend another week to turn those off, is Microsoft paying for that wasted time?
Agreed, but if you turn it off it stays off, it doesn't pop up something every day.
> The sidebar with the Apple shares and news apps.
I kinda know it's there, but I can't remember when I last activated it by mistake *. But then I turn off all notifications except app icon badges so I don't use it at all otherwise.
> Core OS that features only work when paired with iPad/iPhone.
Which ones? Doing phone calls and texts from your laptop? I suppose that requires control of the OS on both sides to work well. I don't know what's available on the Android side.
If there are other features that work when paired with apple mobiles and don't work with Android, I don't know about them.
* Last time I've seen that bar I think it was my cat's butt on the F keys :) She taught me a lot of keyboard shortcuts.
Of course but Microsoft is way more obnoxious about it. In macOS (and iOS) the upsell is a small icon in your system settings. On Windows it's big notifications when you start up your devices. Links in your start menu to third party apps. Notifications when you install and run third-party browsers.
Most mac apps work without an Apple ID. On Windows you can't even use the built in video editor (Clipchamp) without logging in to a Microsoft account.
Microsoft just sucks at UX. On Windows 11 a lot of people now have three versions of Microsoft teams installed. Teams Classic, Teams New, and Teams personal edition. And the search makes sure to avoid showing you the one you use most as the default result.
Don't get me started on how many nag screens and cookie warnings you have to go through when you start Microsoft Edge. I use both Windows and macOS regularly (macOS is my daily driver right now) and Windows has the way worse user experience.
The list of specific annoyances and bugs is likely in the 3 digits by now, and I've only used it for half a year.
The worst of all was getting the M2 soft-bricked by an update, because I had changed the display frame rate to 60Hz, because the tween duration when moving between desktops was for some reason tied to this refresh rate. About 2 second tween duration on 120 Hz until input control, and one second on 60 Hz. Impressive for such a thing to not be picked up by QA.
They could have gone down the path of translating the windows UI APIs, though I think it's better that they left it as is. The bigger issue however, is that there are different systems depending on what it is you want to configure, and it's all ducktaped in an ancient registry that I'm just amazed only breaks as often as it does.
Not to mention that the thing Windows was supposed to always be better at, was driver support. On windows, you have to manually source them, and try as best to avoid all the bloatware that comes with. Windows itself might also decide to replace a driver with an older one (version, release date...). WiFi drivers didn't work last time I upgraded the mobo either.
As for Linux. Completely agree. Gnome is consistent, and gets out of the way often enough. There are some annoyances there too. I have my 90 y/o grandma use Linux/Gnome, because that's what Just Works these days.
The answer to most "it's a bit dumb that MacOS doesn't let you / forces you to" is "install app X, Y, Z".
- Don't like that apple's "Music" app pops up when you connect a Bluetooth headset? => Install an app.
- Want to be able to "alt tab" through windows of the same program, or in general not be uselessly flawed? => Install an app
- Want to be able to move and resize windows without aiming at the exact edge pixels of the window? => Install an app.
- Want to move & resize windows to very common places and sizes on a screen? => Install an app.
- Want global hotkeys for whatever? => Install an app
- Want a software package management system a'la apt? => Install an app.
- Want to rebind keys or make things like Home/End not be dead keys... because apple keyboards don't have that, and they cannot be bothered with it. "you should be using "⌘ + →" anyways... or, I suppose it depends on the window"? => Install an app.
- etc....
You don't get any of these annoyances with Linux / Gnome. "Why not use that if you hate MacOS so much?" I pretend to hear you say. First of all, because of anti-competitive reasons by Apple, I sort of have to. Secondly... something something angry old man yells at clouds.
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.
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 ridiculing it.
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.
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.
How to lose your work using Undo Copy in Windows
I use the command line almost exclusively for file management and avoid it like the plague.
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 thriving indie development scene (which was basically killed by iOS…).
Since then OSX has completely languished as a developer platform. It’s not clear what you can do today as a developer to make your life easier that you could not a decade ago on OSX. And in fact, the destruction of the indie dev scene, combined with the many heavy handed security restrictions of dubious benefit have made it a far worse dev environment than a decade and a half ago.
Further, Linux DEs have greatly improved and Windows now supports Linux development.
The Mac ecosystem has seen a complete turnaround where you now buy a Mac for the hardware, not the software.
However at home I have always been a Windows/Amiga/UNIX head, with Linux being the cheaper path to that UNIX experience, had Microsoft not messed up the POSIX layer, probably I would never have bothered.
For some time I even tried to acquire one of those nice Toshiba laptops using Solaris that Sun used to have.
1. Terminal is very usable, compared to Windows cmd. Modern Gnome Terminal is good, though.
2. Cmnd+C for copy, Ctrl+C for SIGINT.
3. Touch ID instead of root password, which works with Bluetooth keyboard as well, and that's with absolutely minimal configuration, uncommenting single line.
It is subpar, however, when compared to Windows Terminal.
Also I find a simple Konsole on KDE+Linux superior for every Windows and macOS setup (including iTerm2).
That said, iTerm2 isn't good enough to make me use MacOS again.
2. Ctrl+C works for copy when text is selected otherwise SIGINT.
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!
compare with what?
I strongly disagree. I feel that Windows Terminal suffers from a bloated UI and completely asinine organization of the configuration options.
2. I remember the XFCE4 Terminal using Ctrl-Shift-C and Ctrl-Shift-V for copy/paste and liking it, no more SIGINT by mistake. But IMO a minor gripe, you can remap keys for copy/paste in most self-respecting terminal emulators anyway.
3. I agree on that but passwordless sudo saved my sanity and I don't care anymore. If I install a virus then I had all the troubles coming and I'll take responsibility. ¯\_(ツ)_/¯
2. That's bad approach, because it'll be Ctrl+Shift+C in terminal, but Ctrl+C in your IDE. That's inconsistent. I'm usually setting it the other way: Ctrl+C is copy and Ctrl+Shift+C is interrupt, but it's not as good as two different shortcuts.
3. I would say, that it's not only about sudo, it's about other things like revealing passwords in browser, using touch id for passkey authentication, laptop unlock, of course. Those are not strictly developer things, but it's very convenient when it works uniformly. And having some security measure is better than having none, even if it as simple as touch the button, it might cause some second thought. For example few days ago I did a mistake and installed caddy (terrible software, don't recommend). After launch it started tinkering with my system, installing some certificates, and if not for Touch ID, I'd end up with system in unknown state. Probably it'd happily corrupted my system with passwordless sudo.
2. Sure, I don't disagree, I was mostly saying the whole stuff is configurable and we can tune it however way it's more convenient for us.
3. I agree and I'd want a fingerprint or a proper FaceID (with depth-radar and lasers and all, not just something that can be duped by print photos) on my computers but it's not something that would stop me from buying an otherwise excellent machine if it doesn't have this feature.
As for Caddy, let's agree to disagree. :D I will concede that many programs' installers are quite dumb but Caddy itself is excellent once you start it up and it starts doing its own thing.
Installing root certificate into my system without any explicit verbose flags is something malware would do. The developer who thought that's a good thing is the one whose software I'd avoid. His views on usability are completely opposite to mine. What else will he do by default? Listen on 0.0.0.0? Add firewall exception for usability? Create tunnel to the Internet automatically so I can share my work with others without those pesky port forwardings? Some people might like it, but not me, I prefer things as explicit as possible, when it comes to questionable features.
Can't compete with the streamlined easy of highlight-to-copy. I never use a keyboard shortcut to copy text from a terminal (except for yanking in vim / evil-mode)
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.
Nothing came close to OSX’s Expose 15 years ago.
OSX has gone backwards in terms of windows management since then.
Linux is far superior. Even Windows is slightly better because at least windows snap to edges.
I have a $2000 AUD LG monitor that Mac OS just occasionally decides to overdrive (or something) and cause instant but temporary burn in. I'm not the only one - you can find others on Reddit.
While my work Windows laptop might be faster, it's certainly not the one I'm going to pick in a pinch or when I want to travel with just one laptop.
The best mobile configuration I know right now is a Macbook Pro + Parallels. Even with all of its deficiencies.
Are there any good Linux laptops with similar experience as Macbooks when it comes to power management and time from lid opening to usable state?
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 you're looking for a UNIXy nice desktop OS and that's the entirety of your requirement, mac OS is great.
If your REAL use case isn't just generic hanging around, but specifically developing/maintaining an app that runs on linux in production, then you're only hurting yourself the more you introduce mac or windows into the dev process. Nothing good can come of it. Best case you get lucky and you don't run into any issues... and also reap no real benefits because a linux desktop nowadays works fine, it's not the year 2000.
https://stackoverflow.com/questions/66408996/python-not-foun...
> using a third party second display
Has always worked fine for me
> Docker sucks
This is Apple’s fault how? It also sucks on Windows.
> posix compatibility is technically there but isn’t really useful
What does this mean exactly? Can you find an example where it’s not useful? In my experience most of the command line applications I would want on Linux are easily installable via Brew and I can choose all the same shell environments as Linux/Unix.
> The thing randomly loses network and only rebooting fixes it.
On your machine. Not my experience with any Mac I’ve owned. That isn’t expected or common behavior.
> I reboot my corporate Mac more often
I’m going to guess this is because your IT department sucks. I never reboot except for OS updates.
Tried updating to latest xcode, learned that my Mac's storage is almost full. Why? iOS simulator images were taking a whopping 40 GB of space even when I didnt target those iOS versions nor tested on those simulator devices. I uninstalled all the images keeping the one I build for. Next tried updating Xcode again, the issue with creating objective C files was fixed. But then it forced me to download the iOS 17.2 again along with tvOS and a bunch of other extra things. Now my space is close to full again. Why Apple? Why do I need iOS 17.2 when I build for 15.4?
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.
One that says don't update mac os to avoid breaking Java. Another that essentially says upgrade macos to latest version within x days else the issue will be escalated.
It is going to be quite a hassle for IT teams across companies to deal with this problem.
As Gale and Evelle bang in through the door. Evelle holds a
shotgun; Gale holds a shotgun in one hand and Nathan Jr. in
his car seat in the other.
GALE
All right you hayseeds, it's a stick-
up! Everbody freeze! Everbody down
on the ground!
Everyone freezes, staring at Gale and Evelle. An Old Hayseed
with his hands in the air speaks up:
HAYSEED
Well which is it young fella? You
want I should freeze or get down on
the ground? Mean to say, iffen I
freeze, I can't rightly drop. And
iffen I drop, I'm a gonna be in
motion. Ya see -
GALE
SHUTUP!
Promptly:
HAYSEED
Yessir.
GALE
Everone down on the ground!
EVELLE
Y'all can just forget that part about
freezin'.
GALE
That is until they get down there.
EVELLE
Y'all hear that?Haha, this article is quite something :D
The Java Applet was removed from the safari browser. That is unrelated to java apps running on the desktop.
> With macOS 14.4, when a thread is operating in the write mode, if a memory access to a protected memory region is attempted, macOS will send the signal SIGKILL instead.
What is bizarre to me is that Oracle relied on receiving SIGSEGV as normal mode of operation. That should have been a hint where things are going, no?
Not bizarre at all, this how the runtime has always operated, as anyone one who's ever attached a debugger to a Java process knows. The SIGSEGV handler is also responsible to handling NullPointerExceptions IIRC.
> ... the JVM can intercept the resulting SIGSEGV ("Signal: Segmentation Fault"), look at the return address for that signal, and figure out where that access was made in the generated code. Once it figures that bit out, it can then know where to dispatch the control to handle this case — in most cases, throwing NullPointerException or branching somewhere.
https://shipilev.net/jvm/anatomy-quarks/25-implicit-null-che...
> Write attempts to memory that was mapped without write access, or any access to > memory mapped PROT_NONE, shall result in a SIGSEGV signal. > > References to unmapped addresses shall result in a SIGSEGV signal.
How a SIGSEGV can be handled by the program to continue execution normally need some OS specific code. For Linux there's also userfaultfd to suit this need better.
A JVM's use of SIGSEGV might include platform-dependent details for recovery. But for simple application usages (e.g. eliding inlined bounds checks in a performance critical loop operating on an array) longjmp can suffice for recovery. POSIX very carefully defines async-safety and longjmp to permit jumping out of a signal handler and resuming normal execution, provided certain constraints are met, such as that the signal did not interrupt a non-async-signal-safe function.
So you have to disable signals prior to doing anything "non-async-signal-safe" and re-enable them thereafter? That's a pretty big "but"...
It's useful for other things as well. I've used SIGSEGV to emulate hardware interrupts. Normal execution wouldn't trap and there's no need for tests + branches (= normally no slowdown), but when an interrupt occurs a specific often accessed page is marked unreadable.
1. There is very little you can safely do in a signal handler. For a threaded application, that pretty much boils entirely down to setting a bit and leaving it at that. If they did anything more, the behavior is undefined.
2. The memory state that a program receiving a SIGSEGV in is often undefined/garbage, and attempting to execute further at this point is at best unsafe, at worst trampling on state further, continuing execution in a broken state and destroying all evidence that would be useful for debugging - whereas a coredump preserves the state at the time the issue occurs.
There are cases where you need to catch SIGBUS, such as if an anonymous file has been truncated after you mmap'ed it.
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 operating systems, this is not an optimization, so the code was removed earlier this year: https://bugs.openjdk.org/browse/JDK-8320317
This is opposed to calling `sigwait` or similar to actively suspend and wait for a signal, which is not possible to do here.
Granted, it may be that the stars align and their implementation works in practice, but that does not make it any less bizarre.
For example, one kind of program organization that used to be more common in Unix but that remains legal involves keeping signals masked all the time except around certain blocking system calls, e.g. ppoll, that atomically unblock signals and wait. In such a program, a signal can arrive only inside the blocking system call and so the handler can call regular functions without the usual strictures of asynchronous signal safety. (Consider responding to SIGWINCH, which tells you about changing terminal size.)
Synchronous signals are also special in that they're, well, synchronous. That means that in the signal handler you can examine the target memory address or instruction pointer and take action specific to a given spot in your program --- e.g. longjmp to an error handler.
All of this is useful, safe, and legal under POSIX. The main problems with POSIX signals are that, 1) as this thread underscores, most people don't understand them, and 2) signal handlers are process global and hard to share. (Consider if you're running two VMs in a process and each wants to use a SIGSEGV GC safe point trick.)
(userfaultfd, sadly, requires more system calls than a synchronous signal handler to handle anomalous memory access.)
We should be enhancing POSIX signals to make them easier to share, not casting aspersions on them.
It's not. So what?
> The defining characteristics of signals is that, like interrupts and multi-threaded execution
No, they can't. You control when they are masked and unmasked. Certain signals are delivered in response only to certain actions (e.g. floating point errors when enabled, or memory access failures). It's not the chaos you think.
... 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 floating point registers are not saved/restored)
> We should be enhancing POSIX signals to make them easier to share, not casting aspersions on them.
That's fair, but they have already been fixed with signalfd, which more modern processes use to deal with the few POSIX-isms that require it, but many of the original uses have been superseded.
E.g., few modern applications use `timer_create` and SIGALRM, as they can instead use timerfd or poll with strategic timeout (although usually abstracted away by their eventloop). SIGBUS is a POSIX-way to deal with mmap truncation, but sealed memfds can be used to avoid the issue altogether. SIGUSR1/2 can be replaced by any IPC mechanism to give much more flexible controls than a single "reload"/"toggle" signal.
(The POSIX ways can still be useful in certain simpler programs of course.)
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 was correctly saved/restored on Linux.
Don't confuse architectural flaws with implementation bugs. I'm reminded of an argument on emacs-devel in which someone argued that we couldn't call malloc(3) in a multi-threaded program because one beta version of glibc once had a thread safety bug in the malloc implementation.
> SIGBUS is a POSIX-way to deal with mmap truncation, but sealed memfds can be used to avoid the issue altogether.
Sealing a file descriptor doesn't physically seal a USB key into a USB port. :-) You also get SIGBUS on IO failures on mmaped files, and surprise removal is an IO failure. There's really no alternative to a synchronous signal here --- a regular file being mmap()ed isn't a userfaultfd.
IMHO, I think it's crying shame that Hotspot (last time I checked --- maybe it's fixed?) doesn't watch for SIGBUS on access to MappedByteBuffer and translate surprise USB device file removal into a nice clear VM-level exception.
Even for cases for which userfaultfd can work, a synchronous signal can be more efficient because it involves just one entry into the kernel. (sigreturn is optional.) I'd really hate to give up the conventional signal mechanism entirely, although of course I approve of things like signalfd and userfault that reduce the need for signal handling.
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.
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.
`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).
ppoll is a real system call on all Linux systems and has been for over a decade.
> 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,
Which programs do, reliably, all the time.
> You won't get false negatives, but will get false positives.
No, you won't. Once a program wanders into la-la land of memory corruption, all bets are off anyway.
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, where the the guest userspace is very far away from any real hardware traps.
There are basically two classes of UNIX signals: Signals that indicate that you might need to take some action (SIGTERM, SIGALRM, SIGUSR1, ...), and signals that indicate that your process did something illegal (SIGILL, SIGSEGV, SIGFP, ...). There is a very, very limited number of cases where handling these errors make sense, and trying to be "clever" to make (faulty and ill-advised) performance optimizations is not one of them.
> 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 tell me that the VM running the world's most popular OS is pessimizing itself pointlessly.
> The kernel handles hardware traps, which may or may not lead to UNIX signals.
Not all traps result in signals, and not all signals are traps. Nevertheless, the POSIX signals API is the means through which Unix OSes provide user programs the ability to interact with CPU traps. (Windows does the same thing, morally, with SEH and vectored exception handling --- https://learn.microsoft.com/en-us/windows/win32/debug/vector...). Any decent OS should provide applications with the tools they need to make full use of the underlying hardware. All these anti-signals people are just arguing that programs be bigger and slower, because they can't make full use of all the hardware features of the system, out of, ultimately, an aesthetic objection to signal handling.
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. :)
> 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.
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.
You can actually do pretty much anything you want, it's just the C library that uses a lot of global state and internal memory allocations, which messes things up. The core syscall API and any reentrant code you write yourself are not affected.
>The memory state that a program receiving a SIGSEGV in is often undefined/garbage
That may be true for arbitrary segfaults caused by bugs, but the JIT has 100% control over what instructions to emit, it is not restricted by ABIs or platform-specific issues, so there is no problem to use SEGV as a signaling mechanism.
This means a workaround is running java with -Djava.compiler=NONE, no?
It's mostly fine, though. The crashes are rare, and since everything auto-saves, you're not really losing anything. It's just an "oh, okay." moment.
Obviously it'll be good when it's fixed, but on my personal list of impactful bugs, this doesn't crack the top 10.
News like these are the major reason why I apply updates only after long periods of waiting if anything blows up for others. Why companies use their userbase as testers?
But then you are accepting that you are running an exploitable OS since you are lacking the latest security fixes. Not sure if that‘s an acceptable tradeoff.
My work laptop is stuck on 14.3 for a few weeks until they fix this issue. So what? Actual security risk is practically zero. Whereas if I update to 14.4 today the risk is that I can't do my job.
Not really an Apple-specific problem, it could hit anyone who supports multiple versions without opening that can of worms of allowing completely free mix&match of fixes and updates.
As other posters said: macOS might have had an edge over Windows and Linux before but that's no longer the case for a few years now. I'll definitely be looking for ways to use 5K display with my Linux laptop and will likely make a full transition to Linux in the next year or two.
Macs have amazing displays. So I'll use mine as thin clients I suppose. My eyes are happier with an Apple display so I'll use them for that alone.
Apple can still turn this around but their bogus security claims that serve mostly to annoy devs is them shooting themselves in the foot and making themselves a very uncomfortable bed to sleep in just some very short years in the future. Hope somebody at HQ understands that and is able to see the problem before too many people leave.
I suggest the Oracle blog as an alternative.
I thought it was clear, but I have replaced the "this" in my comment anyway.
In that case, I 100% agree with you, the Oracle article seems much better than the Apple Insider article.
This is why most enterprise workplace tech teams don’t roll out any OS level updates immediately. Regardless of whether they are on windows or macOS. Also a good idea to disable automatic updates on all devices that you use daily.
This is misleading. What was deprecated was the browser Java plug-in distributed by Apple. That’s very different from “deprecating Java”.
They basically bamboozled us with fancy wallpapers and gave us this immensely substandard software.
macOS Sonoma 14.4 introduces new emoji as well as other features, bug fixes and security updates for your Mac.
Emoji
• New mushroom, phoenix, lime, broken chain and shaking heads emoji are now available in emoji keyboard • 18 people and body emoji support facing the opposite direction
This update also includes the following improvements and bug fixes:
• Podcasts Episode text can be read in full, searched for a word or phrase, clicked to play from a specific point, and used with accessibility features such as Text Size, Increase Contrast and VoiceOver • Safari Favourites Bar adds an option to show only icons for websites