Poll on macOS 10.12 is broken
daniel.haxx.se
daniel.haxx.se
Off hand I remember spending the better part of two days trying to understand a bug that was traced to a coroutine issue -- OS X was just not saving a required register, known and reported for 5 major versions.
I remember discovering that unnamed semaphores don't work on OS X. Not that the functions aren't implemented, just that they always return an error.
So I'm not surprised that poll() would be broken, nor am I surprised that it's broken again.
The only thing that surprised me anymore is how many people continue to insist to me that OS X (or macOS now, I guess) is a great UNIX. It may be a great desktop OS.
edit: iOS->OSX
I wonder if the Open Group will accept a bug report? From http://www.opengroup.org/openbrand/ : "Anyone buying a Registered Product is guaranteed that: The product conforms to the identified Product Standard. ... The product will continue to conform. ... Any conformance problem will be fixed within the prescribed timescale."
The poll issue is a clear violation of the UNIX spec. http://pubs.opengroup.org/onlinepubs/7908799/xsh/poll.html
Returning immediately with a non null fds, a zero lenght and non zero timeout is unarguably a bug.
I'm not making any claim about the actual source of the poll bug here.
* HiDPI does not seem to work as well on other platforms.
* Lightroom is a pain to run over wine or some other tool (and no, Darktable is not there yet)
* 1Password still has no linux client
* I like the iPhone and do not plan to move away anytime soon
* iOS app builds - not really a problem to keep my old MBP around just for doing builds
I have been using linux for years on the server and I'm really amazed how short this list has become.
I'm not saying Lightroom will run in a VM, I haven't used VMs for heavy programs, this was just an anecdote of me being surprised by how someone could use huge engineering programs inside a VM.
Personally whenever I use the clone/heal brush Lightroom slows down to almost unusable performance and this is on an i7 + 8GB RAM - I can't imagine running it in a VM. I am sure this is Adobe's fault though cause the same tools in Photoshop perform multiple times faster.
Which is what I do nowadays, my netbook is the only surviving desktop still having a native install of GNU/Linux.
[ It still has terrible battery life, and chucks out a load of heat though ].
I did have other problems -- some serious. Right now, running Fedora 24 and Gnome 3, it seems to be a reasonably workable machine, but yeah, it's been more trouble than you'd like for the money. Part of it seems to be that Skylake is just wonky on its own. Some of my issues in Linux have been issues with the dual-booted Windows 10 install as well (e.g., sometimes rebooting instead of waking from sleep).
I'm dual-booting Windows for Photoshop and Lightroom, and using the 1Password Web interface since there isn't a Linux client.
Like you, I still have my MacBook Pro around for when I really need a Mac. But I'm tired of supporting Apple when its clear they're not especially committed to the Mac anymore.
It seems that if you have a GTK3 desktop (I've tried elementaryOS, GNOME 3 apparently works well as well) most of the developer related things will work well at 2.0 scale - like Mac does it. At least I've tested out Sublime Text, Chrome, Terminal apps, GVim and other included GTK3 apps.
Another thing is if you lug your computer around a lot, I often go from one 3-monitor setup at work to another at home however this always messes up my window placement and I haven't seem to found any DE/WM which handles this cleanly in a convenient way even near the experience on macOS.
This experience have made me realise that even though Linux is workable as a developer OS today it is nowhere near as convenient and seamless as macOS.
Have you tried a tiling WM like i3? If you unplug and replug monitors you're just changing what workspaces are displayed where. The experience is identical if you have one or many monitors.
That doesn't really solve your other issues though. Personally I use lastpass which works fine in Linux but I haven't used 1password enough to be able to say whether it's a valid comparison or not. Lightroom might work under Wine or in a VM if you don't use it so often that you really need it to be native.
Windows vs. OS X have quite different philosophies in font rendering:
> https://blog.codinghorror.com/font-rendering-respecting-the-...
"Apple generally believes that the goal of the algorithm should be to preserve the design of the typeface as much as possible, even at the cost of a little bit of blurriness.
Microsoft generally believes that the shape of each letter should be hammered into pixel boundaries to prevent blur and improve readability, even at the cost of not being true to the typeface."
Also under Windows font hintings and other subtile details of the font format have much more importance on a good-looking font display than in the font rendering algorithm than under OS X.
Source:
> https://www.smashingmagazine.com/2012/04/a-closer-look-at-fo...
(This article is from 2012; I don't know whether it is still up-to-date):
"On Mac OS and iOS, we hardly have any control over the rendering, which is acceptable (since it’s generally very reliable). [...] On Windows, hinting matters—especially for TrueType-based fonts (the only Web fonts Internet Explorer 6–8 will accept). Apart from that, one significant control we have over the rendering is the choice between TrueType and PostScript. Except for very well-hinted fonts in smaller sizes, the latter is equal or superior in rendering, and easier to produce. Even though DirectWrite is making Windows rendering more pleasant, it will not remove the necessity to provide well-hinted fonts."
I would argue that hidpi doesn't look as good as Mac, but better than Windows. I'm primarily committed to Gnome, so I cannot speak for other desktop platforms, but GTK applications look pretty good and the font rendering is fine (again, not great like Mac, but not bad like Windows).
But there's always that one tool that just isn't there...
There is no Linux desktop experience that is consistent, or coherent. You'll frequently want to use software that happens to be made for the other window manager, and suddenly you have different keyboard layouts depending on the window that's active. Toolbars are sometimes on top, sometimes in the window. Sleep absolutely definitely will never work, unless you muck around in the kernel for a bit. Then it works but your wifi cuts off when you're playing music.
Most of design is either created by people who want to punish you for leaving the command line, or these people who put blinking, nascar-style ornaments into their water-cooled, wall-mounted, intel-inside-stickered towers.
Oh, and battery life on Skylake is about half of what a Macbook gets.
Is it as refined as MacOS? No. Does it have the same polished application selection? No. Does it need both of those to be useful? Up to you, and you can help mold it and become part of the community
This is a problem. I want a desktop, not a job with "feeling good" salary.
That's why I said you can do it, the days when you had to do it are long gone.
Seriously, I think two of the biggest problems facing desktop Linux are:
- people having outdated experiences - equating Ubuntu, (not that great), with Linux and thinking that Ubuntu problems are Linux problems.
So, I can't directly disagree with most of what you said on point, except for sleep/hibernate/suspend. Especially in the last decade, it often works without any low-level tweaking, and I can get it going in MOST cases without too much fuss.
In the last 10+ years, my wifi experience on Linux has been very solid, often more solid than my OSX-using co-workers.
But this is all anecdata.
Though Ubuntu (and to a much lesser extent, some others) have come light-years toward producing a consistent, coherent Linux desktop experience, it still lags painfully behind OSX and Windows.
With all of these disadvantages, though, the 'all the way down' reliability and no-bullshit you get from a Linux desktop (or server) is worth its weight in gold. It's just that the entry fee is still too high.
That beings said, the vast majority of consumers, and I suspect the vast majority of developers, do not rely on such applications (or their equivalent w/r/t Windows).
Try updating your firmware. My Skylake laptop gets 10 hours or so. If a Macbook got 20, I'd be quite impressed. :)
I've toyed with Arch during Windows 7 times - after hearing how linux is more stable than windoze/windblowz - and then nVidia drivers crashed, X server crashed, aaand upon starting X - all GUI applications were closed.
Are. You. Friggin. Kidding me? People were talking about stability when such things happened? Linux stability compared to Windows 7 - zero. At that time.
Has it changed?
This is an often repeated myth that just isn't true, (unless you have [testing] enabled). I had a single Arch install survive for 3 years without any problems and that involved switching over to a new init system.
I only had to install Windows back on the machine because I went on to sell it and get a new one.
(Performance is another matter, of course, but for regular desktop use, it does not matter that much.)
I personally haven't had the video driver crash on me, but even so, I think a video driver is not the OS, so not sure what you're talking about.
Kernel panics would be more understandable comparison.
[edit]
The only issue so far is that when I unplug an external display, it sometimes fails to shrink my desktop accordingly. I've seen issues of a similar level of annoyance on macs as well.
[edit2]
There are the other standard linux things (every piece of software is configured differently &c.) but as we are talking about someone who uses linux on the server already, I didn't consider that apropos.
Since Windows is not an option for me, I switched to a Mac.
I don't recommend gentoo for everyone although it really isn't that bad--if you can develop a web app, I'm sure you're definitely capable enough to use a supposedly "advanced" distro like arch or gentoo, but Ubuntu isn't that sterling of a system in my experience especially when you need something beyond the defaults.
I also enjoy pacman a lot more than apt.
Hate that Ubuntu == Linux for many people.
Agreed in a sense. All OSes have their issues. They're just different issues.
> Linux on the desktop is nowhere near macOS.
And that's because it's a different OS. It's not trying to be MacOS. And I'm glad it isn't. Because if I wanted MacOS I'd run that, don't you think?
> Sleep absolutely definitely will never work, unless you muck around in the kernel for a bit. Then it works but your wifi cuts off when you're playing music.
I've yet to experience any issues like this on any of my hardware, but I've been shopping around from Linux-friendly OEMs like Dell XPS laptops and Lenovo ThinkPads. So maybe that's just you being unlucky about your hardware? Hard to tell over an internet comment.
But let's be real here: Linux as a general purpose desktop OS mostly works on pretty much any hardware you throw at it. OSX works on maybe 3 models made by 1 vendor.
Trying to arrest Linux for poor hardware-support in this scenario is a pretty weak hand to play, honestly. Because out of the three big OSes, MacOS is clearly the general purpose operating system with the weakest hardware support of them all. Its hardware support is piss poor.
Straight up FUD. This isn't the experience at all. Linux had these issues in the mid 2000s, that hasn't been my experience in years.
I agree with the "inconsistency" but I see the same "inconsistency" when I open matplotlib windows (wxgtk I suppose) and they look different, only closing the window fails randomly on OS X and leaves Python interpreter running while I've yet to experience that on Linux.
Then, I'd try to kill the non-responding app, and kill works on Linux, but on macOS, it is inconsistent. And that wasn't ten years ago, that was may be two or three days ago.
You didn't ask for advice, but if I had any, it would be to avoid Ubuntu. Most of the poorly functioning and randomly crashing processes I've seen on Linux was on Ubuntu machines.
HiDPI is just a waste of processing power and money anyway.
> * Lightroom is a pain to run over wine or some other tool (and no, Darktable is not there yet)
Sure, but that's an Adobe issue.
> * 1Password still has no linux client
KeePass?
> * I like the iPhone and do not plan to move away anytime soon > * iOS app builds - not really a problem to keep my old MBP around just for doing builds
Being that tied to your desktop OS sounds like a huge reason to move away from iOS.
You're right, we should all go back to 640x480 CRT screens.
After being on HiDPI displays for years, old LCDs are practically unusable. More eye strain, lower max information density, less visually appealing.
I don't really care whose issue LR is. It's a tool really without equal, and it's required for my use case.
Keepass is what I would move to, but 1Password is so much nicer. Hopefully they support Linux fully at some point.
Why would I move away from iOS? The hardware and software as a package work better than anything on Android I have used, again for my use case. Part of my job is building apps for both platforms. There is no way we would stop doing the iOS version.
HiDPI was broken for me on my external display once I "upgraded" to Sierra. In order to fix the problem, I had to install the most recent beta of the OS - not a move I liked making, but one I felt necessary because my external display is such an important part of my work.
This marks the first time that I've had this kind of issue with a macOS upgrade so soon after release. Lesson learned. Now I plan to hold off, with future releases. These new versions aren't bringing any new features that I care about, in the end, so there's no need for the new & shiny version of the OS anyway.
As someone who ran Linux both on the desktop and laptop for well over a decade, for me Windows 10 has finally gotten to a usability point that I accept, WRT the window manager. That may sound odd, but I was "that guy" you might have run into who had a fully hand written FVWM config that was extremely customized to be efficient, so the fact that Windows is often sufficient now is quite a feat to me.
That said, my workflow does often consist of just browser + email + terminals, so take that into consideration.
Every windows update (which MS now shoves down my throat at the most inconvenient of times) seems to want to force me to use Cortana. Every update also re-adds shortcuts to the windows store to my quicklaunch. I'm constantly seeing nags and offers for things I'm not interested in using on the lock screen.
It feels like there is no one at Microsoft really in charge of the user experience and every department within the organization gets to add their "must haves" to the next version with little consideration on how it affects the overall experience of the operating system. In this regard, Apple is and always has been lightyears ahead of MS and that just doesn't ever seem to change.
Then there's still long standing issues that exist that completely boggle my mind - I just plugged in a new USB mouse the other day and had to restart after installing the software for it.
I do agree it's a bit naggy at times. As for the updates... I have complicated feeling about that. It's annoying that it auto-restarts, but the alternative is so much worse. There's a registry hack to prevent it, which if you think it's a good idea to turn auto-updates off, you should probably feel comfortable making a registry change to show you know enough to be responsible about that. The windows store stuff seems to only come back from certain updates, I'm not sure which ones.
> I'm constantly seeing nags and offers for things I'm not interested in using on the lock screen.
I've seen multiple reports of this, but I don't see it, so can't really comment on it. My lock screens are just images (rather good ones actually, like for the chromecast, IMO).
> Then there's still long standing issues that exist that completely boggle my mind - I just plugged in a new USB mouse the other day and had to restart after installing the software for it.
Was it a specialty mouse? Did it install it's own software (it sounds like it, when you mention "installing the software for it")? If it automatically launched a third party installer that decided that you needed to restart, that one can't be totally blamed on MS (beyond expecting them to blacklist the device for poor driver quality/installation, which won't exactly make people happy either).
The problem with the MS platform is that as it's the primary market for most people and devices, you get some very low quality stuff. That same stuff might not work at all on other platforms, or be feature poor (e.g. a mouse that can't use all it's swizzy features because it's using the base USB HID stuff). That's a common problem with hardware on Linux (until the device gets open source support, if it ever does), so I'm used to it. Sometimes I choose not to install the proprietary driver for Windows anyway, just because I don't want their crap on my system.
Poor third party driver quality has historically been a large cause for instability in Windows systems, and IIRC around Vista was where they changed how drivers worked to address this problem, and now Windows is much more stable IMO. So, crappy devs shunting crappy drivers with their products is less of an issue, but still a problem, and one that's not really going to go away as long as closed source third party drivers are allowed without careful vetting (which they may be doing to some degree now, I'm not sure).
The one-two punch that routinely frustrates the hell out of me is when the vendor driver software requires an update, and the reboot process in turns fires off the windows update install. Now, instead of sitting down to play a game, I'm waiting fifteen minutes for two different software updates to finish and reboot my computer.
It was much easier getting nvidia-docker, tensor flow and caffe running than getting the desktop to limp along.
I would recommend giving something with GNOME 3.22, like Arch or Gentoo a serious try instead.
You can use something like https://antergos.com to install Arch and https://www.sabayon.org for Gentoo.
- GNOME 3.22 has pretty great HiDPI and most GTK apps work very well with it + it looks great with the Arc theme + Numix icons
- A small virtual machine for Lightroom may be easier than Wine, or try a commercial, supported fork like Crossover
- The system is just soo much lighter and more responsive than macOS, no constant locks or spin wheels in 1/3rd of the CPU+RAM usage of a Mac.
- A package manager like pacman runs circles around Homebrew and the whole UNIX CLI toolset feels much more like a first class citizen
- Bugs are visible and traceable in the open and patches are often provided within a couple of days.
- WiFi on my 2015 15" MBP constantly drops for me, never happened to me under Linux (Arch specifically)
- The kernel can be compiled with only your specific modules, allowing for even faster, leaner system
- systemd is amazing and makes managing the system super easy
- Greater choice of file systems to fit your needs, most of which are not 30 year old and do not operate on a single file at a time.
- Even if the GUI freezes, it's super easy to switch to a tty and restart the display server, avoiding a hard reset
- Hardware with proper GPU available, allowing you to play over 2000 games on Steam, including some which are not on Mac at all
- Vulkan support/more likely to support future games
- Runs cooler and quieter
- Not subject to one company's whims and control
- I also have an iPhone, apart from iOS dev, why is this a concern for you under Linux?
- Rolling release if you want it, (contrary to popular opinion, very stable, I had the same install for 3 years without issues and that involved swapping the entire init system)
- Free as in freedom software, passionate people and community, generally much more of a developer/like minded individual type of crowd if you care about that With it comes a sense that you're contributing to something having real impact out there.
In over a decade of submitting bug reports to Apple, they've only ever fixed a few of my issues. Most of my reports are easy to reproduce and test. I'm better off spending my time doing clean room reimplementations of whatever their API promises or just scrapping whatever I wanted to do than even wasting time reporting bugs.
"Radar Radar Radar" is all they ever ask. I don't care anymore. The whole process is opaque with no guarantees of a fix or a workaround; it'a unworthy of my time. They have over $100 billion in cash - about time they start testing and fixing more of their own issues.
Why would any organization with all that cash worry about fixing issues. They were showered with money in spite of those issues, so they must not matter.
So if anything, the bigger and richer they get, the less inclined they are to fix issues. Unless they perceive that there is a looming threat, and certain issues are seen as connected with it.
It's not like Apple doesn't have the cash either. They could take some of the money that is trapped overseas for tax reasons and open up a field office somewhere (Ireland? China?) who's only job is to run through Radar from top to bottom and close out/fix every issue.
The recovery tools are kind of touchy too, they only work on certain versions of MacOS and are kind of difficult to track down. The only saving grace is that Time Machine is so easy to use that people sometimes actually turn it on.
Having a support contract helps a lot. Apple doesn't really even offer that.
With one fairly epic failure from them, my employer was big enough to get a sad Apple guy to fly up and express his heartfelt sorrow. Very touching. His SE helpfully suggested that we restore our phones (15,000 of them). That was about the extent of it.
It's just their way, each vendor is uniquely obnoxious. But the unpredictability limits what you can do with their products.
In fairness, this applies to any large company. What gets the grease is volume field reports from Customer Support, not bug reports from developers, no matter the level of detail.
I have an outstanding Radar report of a problem with the Fusion drive from at least Yosemite on; on a full SSD in the CoreStorage volume, allocating a file buffer larger than the 4GB copy partition will instantly hang the file system, effectively disabling the computer. You can't even reboot, hard power cycle is the only solution. This isn't in general a good way to create a file, but Transmission does exactly this, unfortunately.
If everyone follows your algorithm then you will have efficiently implemented the Bystander Effect.
How recent is your experience, I have found this not to be really true anymore, at least for the past few years.
Why should they care about it as a platform if its impact is negligible. Wouldn't one prefer to focus on the next non-negligible thing?
Apple should care for multiple reasons:
- reputation matters
- not acting like it's abandoned its roots is a positive in image building
- not being shamed repeatedly, with good reason, about its attitude as well as seeming ineptitude
- recruiting talent becomes easier since it's likely more people may see Apple as a decent place to work at (considering this alone in this context, for the sake of simplicity)
- making the platform used to build apps for its best selling platform a lot better ought to be a no-brainer
- …and many more that don't occur to me right now
As I said, I don't think Apple would have to blow a significant amount of money with its finances and budgets to make this better. In my view, with the reasons stated above, Apple has more to lose with this lackadaisical attitude toward macOS/OS X and the Mac platform than just saving some money because the revenue potential is lower. I can't imagine how it'd be to be in a company that gets shamed so much and doesn't seem to want to respond or do much to alleviate matters.
On a related note, Xcode also gets a lot of flak, despite the fact that it's what helps Apple make money from apps. I repeat, something seems seriously missing.
Apple's long term strategy absolutely relies on OSX, if current management are taking a short term view, well it wouldn't be the first time. Only there is now now Jobs to come riding to the rescue.
In last quarter Apple had revenue of $42B.
$24B in phone sales compared to $5B in Mac sales. iPad revenue roughly same as Mac sales. Services made up the bulk of the remaining revenue.
This gives you an idea of how unimportant Mac sales are to Apple. They just need Macs for the sake of the iOS ecosystem.
I think problems with macOS are often magnified on discussion forums. Partially, because there is a subset of the community that heavily dislikes Apple (for ideological or other reasons). Some macOS updates introduced minor bugs for my daily use, but it is an incredibly smooth ride compared to most other systems (I have used Linux on the desktop from 1994-2007 and still have a Linux machine at home for porting software, etc.).
It's very clear from Apple's action, or rather, inaction and silence, over several years, that Apple doesn't "need" the Mac for any specific reason. It's one of those things that's there because it's there.
If it were true that Apple needs the Mac, we would've seen a lot more attention paid to the platform, not just neglect that has been shamed online repeatedly for a long time. The situation is quite unfortunate, in my view.
They were never committed to it with A/UX and for NeXT it was just a way to bring in software from the blooming UNIX workstations market.
I remember back in the early 2003, they came to CERN trying to promote the idea of using Mac OS X for research because of the UNIX compatibility.
In both cases, NeXT (aka Apple) needed the developers to help grow their diminishing market.
Now they have the upper hand and don't need UNIX compatibility more than they already offer, and the non-UNIX layers is what matters.
They are not alone, just look at Google efforts with Brillo, Fuchsia and removal of insecure UNIX V APIs in Android.
Microsoft more or less did the same thing with OpenBSD and NT kernel. Several kernel sections started out as BSD code (the networking stack for example).
Don't forget Jobs attempted to steal NeXt's fork of the GCC with Obj-C extensions. The FSF had to sue NeXt to get them to release their modifications.
Stealing Free Software is cheap from a business perspective.
Actually there was no lawsuit. NeXT released the patches after a warning: http://ebb.org/bkuhn/talks/LinuxTag-2011/compliance.html
> Stealing Free Software is cheap from a business perspective.
This is why I recommend everyone use AGPLv3 whenever possible (and consider changing the license on your old Free Software - you can do this if all of the contributors consent). Apple has been removing all GPLv3 software from Mac OS X over the past several years because v3 is incompatible with their goals of totalitarian computing: http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/
Brillo and Fuchsia have almost no GPL or LGPL licensed code.
They also are in the process of kicking GCC out of the Android NDK. Only a few feature parity issues are preventing it for the time being.
When Apple tried A/UX he was on his way out and it was never an attempt to replace Mac OS.
Regarding NeXT, the company was targeting the new workstation market, which was moving away from Lisp and Ada Machines into UNIX ones, thanks to UNIX code being freely available, as AT&T was not allowed to charge for it.
NeXT main competition were Sun and Irix workstations, so a certain compatibility with UNIX was desired.
However the whole Mach stack was very UNIX-unlike. Many naysayers regarding Objective-C use for systems programming aren't aware that even NextSTEP drivers were written in it.
So it was all about business, Steve was always keen on how Xerox PARC OSes used to work.
Between 10.2 and 10.8 it was both, culminating on 10.5 and 10.6, the crown jewels IMHO. After 10.8 it took a definite turn for the worse, acquiring the worst of 'modern' practices and slashing many historic features that users loved, from user-friendly stuff to power user shortcuts and customizations.
I haven't even tried 10.12. The previous releases (10.9 through 10.11) have thoroughly butchered the interface, usability, compatibility, performance, and UNIX-level features.
I'm now back on GNU/Linux (Mint 18 Cinnamon) and I'm loving it! I have yet to find a feature or program I'm missing, while many things are so much easier. (Focus follows mouse, middle button paste, and Alt + window dragging, how I missed you! Not to mention apt-get)
Anything specific? Because I don't find anything "butchered", apart from the usual assortment of bugs.
It seems like 10.6 is the agreed-upon high point for macOS - then the porting of iOS designs/features (remember those linen textures?) resulted in more UX issues and bugs than usual. Thankfully it has improved significantly since then, though.
Might be -- I'm using just one external monitor, so don't know.
That said "multi-monitor support suffered badly for a version or so" is rather anti-climatic after "butchered".
I don't know who is agreeing here, but I find people who say this to be looking with some seriously rose-tinted glasses. Mac OS X 10.6 is really not that great. It's hardly as "rock-solid" as people make it out to be.
It's the iOS 6 of OS X. It's the refinement of the most familiar interface before things started changing. That doesn't make it better, just more comfortable for some.
Here's the kicker: it's ugly. It looked good at the time, but looking back on it, it looks clunky. The remaining Aqua elements look out of place and weird, buttons lack consistency, design is all over the map.
10.12 isn't perfect but it's a pretty damn good OS. Mac OS X/OS X/macOS has always been kinda buggy; it's the nature of an OS with a significantly smaller userbase. IMO it's no worse now than it was in 10.6, except it has a ton more features.
Many of those features are the reasons why it is worse to many people. New code comes with a cost. Every new system feature (handoff, clipboard sharing, sandboxing, etc.) is more places for bugs to pop up.
There was no code in 10.6 that could cause your desktop, documents folder, and photo library to just randomly "disappear" one day when iCloud decides to have a few too many drinks and stumbles home. In 10.6, they didn't need a new low-level networking library to support drag-and-drop between your iPhone and your Mac, and as such, that code wasn't there to repeatedly rename your Mac "Foo (7)" or whatever.
Sure, if you use the new features, then on balance, they're probably fine, despite the problems that pop up. But a lot of people see these features as solving problems they don't have and solving them in a way that makes loads of things that used to work reliably no longer quite so reliable.
What are you talking about? Assuming you mean universal clipboard (you can't drag & drop to your iPhone), that's built on top of handoff, a technology we've had for a few years now, and has nothing at all to do with your computer being named "Foo (7)". I suspect you're thinking of the discoveryd fiasco, which isn't related to any feature work at all but was caused by Stuart Cheshire retiring (and was fixed by Stuart coming back out of retirement).
Yeah, Posix semaphores don't work on macOS. Confusingly, support for unnamed semaphores exists however in Apple's libdispatch, using dispatch_semaphore_t. Don't ask me why.
E.g.
http://www.kylheku.com/cgit/txr/commit/?id=8bc6ba624272e9df4...
The API is extensible in that we can introduce new address types, and overlay new structures. You can implement a new network "foo", then in the API add AF_FOO address family enumeration and a struct sockaddr_foo which exhibits whatever members you want (which are documented and must be initialized).
The AF_INET family has only sin_family, sin_addr and sin_port. If we init these, we are good to go.
If you want a struct similar to struct sin_addr, but with more fields that are user-visible and must be initialized, you must introduce a new derived type AF_INET_SPECIAL along with struct sockaddr_in_special.
> Enforcing this rule leads to more robust and portable code.
Enforcing this rule ensures that correct code that works everywhere breaks on (i.e. does not cleanly port to) Mac OS.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/net...
> The <netinet/in.h> header shall define the sockaddr_in structure that includes at least the following members: [...]
The "at least" is the keyword. Additional members in the struct are allowed by POSIX. You have to expect and handle them according to the standard.
Is there a blanket requirement somewhere in POSIX which says that whenever a structure may have members in addition to the required ones, these members must be initialized (and specifically to zero) when the application creates such a structure and passes it to a library function?
(If so, why are they repeating that requirement for struct sockaddr_in6?)
In any case, does the issue reproduce on FreeBSD? If I google for this bind problem, it only appears to be reported against Mac OS X, and no other Unix, historic or current.
https://groups.google.com/forum/#!topic/comp.std.c/zl15FkixB...
If a standard structure may have additional members, those do not have to be initialized by the program, unless the requirement is explicit somewhere. For example, we do not have to initialize members of "struct tm" other than the standard ones when calling asctime; there is no wording which absolves asctime of behaving as required if those members are not initialized.
The same reasoning applies to the POSIX bind function and the members of struct sockaddr_in. (But not struct sockaddr_in6, for which initialization requirements are specified).
About sockaddr_in, POSIX-2001, 2004 edition[1] has to say:
10004 The <netinet/in.h> header shall define the sockaddr_in structure that includes at least the
10005 following members:
10006 sa_family_t sin_family AF_INET.
10007 in_port_t sin_port Port number.
10008 struct in_addr sin_addr IP address.
However, about IPv6 it says:
10016 The <netinet/in.h> header shall define the sockaddr_in6 structure that includes at least the
10017 following members:
10018 sa_family_t sin6_family AF_INET6.
10019 in_port_t sin6_port Port number.
10020 uint32_t sin6_flowinfo IPv6 traffic class and flow information.
10021 struct in6_addr sin6_addr IPv6 address.
10022 uint32_t sin6_scope_id Set of interfaces for a scope.
10023 The sin6_port and sin6_addr members shall be in network byte order.
10024 The sockaddr_in6 structure shall be set to zero by an application prior to using it, since
10025 implementations are free to have additional, implementation-defined fields in sockaddr_in6.
[1]: The current UNIX standard is UNIX V7, which corresponds to SUSv4, which corresponds to the POSIX-2008. However, macOS is certified UNIX under the previous version, UNIX 03, which corresponds to SUSv3, which corresponds to POSIX-2001.
/* Apple's socket address. */
struct sockaddr_in {
__uint8_t sin_len;
sa_family_t sin_family;
in_port_t sin_port;
struct in_addr sin_addr;
char sin_zero[8];
}
int bind(int sockfd, const struct sockaddr *addr,
socklen_t addrlen);
If sin_zero must be zero, why doesn't the bind function make it so?
Don't add a member to the end of a struct just so that padding has a name, and then make me initialize it.
POSIX defines a type called struct sockaddr_storage which is at least as large as the largest sockaddr_* type. There is no need to pad the various sockaddr-s up to that size; the sockaddr_storage can be used to declare storage large enough to receive any address.
For example, struct sockaddr only contains 1-byte members. Therefore it does not have special requirements on alignment. struct sockaddr_in contains at least one member of 4 bytes (struct in_addr), therefore it also has a alignment requirement of 4 bytes to avoid splitting the 4 byte member between memory words.
In order to support casting pointers to any of these struct types, implementations pad all of these structs to make them all the same size and therefore having sane alignment requirements.
You will not read anything about these kind of problems in POSIX, since these are limititations implied by the hardware architecture.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys...
Quote: "The sockaddr_storage structure solves the problem of declaring storage for automatic variables which is both large enough and aligned enough for storing the socket address data structure of any family."
You're never going to define the storage for an object of `struct sockaddr`; that's just the "abstract base" so to speak: pointers are cast to that type when calling the API. The API switches to the right department in the code, which converts the pointer back to the right concrete type again, like "struct sockaddr_in". So all that is needed is the property that the "struct sockaddr " type can store and recover any other "struct sockaddr_whatever " pointer.
You're also never going to be doing completely silly things like converting a "struct sockaddr_in " to "struct sockaddr_ax25 " or whatever.
I'm not convinced the desktop is great either. Sure, the visual polish is better (font rendering is much better on OS X), but things like windowing, workspaces I find was much more my speed on Gnome 3.
From the bottom of my heart, I want to thank you for using a word aside from "problematic."
I'd argue that missing out on security fixes is far more risky than any technical issues you may encounter after an update but I'm a security engineer.
Which is just silly for someone like Apple
> a lack of incentive since they fixed them already in the gold standard New Version
That is not how security works. Again, it is just silly for someone like Apple to believe only the latest release needs security fixes.
"We're Apple... everyone always uses the latest versions of our stuff..."
While that works well, you can install the newer version in another partition or disk. That's what I did with macOS Sierra and then I went back to an older version as it doesn't seem very stable to me.
FWIW on a macOS Sierra test box I just had compress hang on zipping up 2 small log files. Not sure if that's Sierra or if the machine has problems, but it sure was weird.
I come from linux, I'm used to screwed up APIs, and stuff breaking. But when we have something broken, it's usually because it was designed that way (see epoll). Usually, anyways.
But even we would never break something this fundamental. And if it did break, we'd probably fix it. Immediately.
Breaking one of the most used syscalls in the POSIX spec isn't an option, and is never okay. Ever.
Of course these things get fixed very rapidly, so completely unlike this Apple/poll story.
But in this case, they are using poll as the time-honored way to sleep. Yes Apple should follow the expected POSIX behavior but at the same time if sleep is what is desired, there's usleep(3) and nanosleep(2) which are found in libc's time.h
Also, according to the developer, this same behavior was present from 10.3 to 10.9 ( Apple was certified to be compliant from 10.5 onwards which tells you that this isn't non conformant) and OS X did not even ship with a poll(2) implementation before 10.3 .
It's also possible that the test suite just doesn't check for this. In any case, the behavior is necessary for any application that polls against a set of fds of varying size, as the fd set may shrink to zero before expanding again, and and punishing the developer for not checking as special case that all other unixes handle automatically is pretty unfair.
My MBP is so buggy as it is with El Cap that I prefer to use a cheap surface 3 for anything other than dev work.
Every time Apple releases a macOS update I'm left to decide between the bugs I already experienced that might be fixed and the mountain of bugs that are surely hidden in the new update.
Every couple of weeks they'd put out a patch that claimed to fix the wifi, and while it did get better, it was never as good as it should have been. I live in a 1-bedroom apartment with an 802.11ac router and all of my other devices work fine. The router's off at one end of the apartment where the coax comes in, but I'm never more than 25 feet away from it.
I've heard here and talked to a number of professionals that do not use Linux because they want something that "just works". But if I really sit down and catalog my issues, Linux can be a headache to set up, but once it's working I rarely have issues. Part of that is researching the right hardware, so I guess it's not the plug and play of proprietary platforms, but it works.
The last piece of productivity software I wanted on Linux was just released recently (Substance Designer), so I'm seriously considering a dual boot. Have to keep Windows around because it's my gaming machine, but I'm a bit sick of having software updates shoved down my throat at inopportune times.
What pisses me off the most about W10 is that it makes you pick "active hours" when it won't install updates, but it's a 12 hour maximum and it's the same every day. As if my home computer's usage pattern on Monday-Friday is going to be the same as the weekend.
The newest and my personal favorite is a faulty file save/open dialog on OS X. Anytime an app invokes that, the entire app crashes. Really fun in Chrome, Word, Atom, or any other app that involves opening or saving files.
Libc (or the various other libs that compose libc) are not necessarily system calls, often they are wrappings of severals.
I'm talking about the `dlfnc.h` interfaces.
"If none of the defined events have occurred on any selected file descriptor" - This statement is not same as passing NULL.
I have adopted the practise of installing new OS releases on a separate test partition first. Blindly updating the main system can be a really bad trap.
From the Go1.7 release notes: "Binaries built with versions of Go before 1.6.3 will not work correctly on Sierra."
I don't know what the underlying cause was.
Bonus stink - http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AN... - kqueue has been buggy and Apple switched poll to use kqueue in 10.5.6!
> most versions support only sockets, many support pipes
That seems to be self-contradictory, especially because elsewhere in the document it says
> usually it doesn't work reliably with anything but sockets and pipes, except on Darwin, where of course it's completely useless
But nowhere on that page can I find an explanation of what's actually wrong with it.
Here is a thread with sample code having kqueue issues - https://discussions.apple.com/thread/4783301?tstart=0 (Note: I haven't seen that code myself - it might as well be buggy itself but you can use it for your tests as a starting point I suppose.)
Edit: User DerekL also reports running code that illustrates the bug on latest iOS version - https://news.ycombinator.com/item?id=12687527
As for that discussions post, there's no replies at all so there's no indication as to whether anybody's analyzed it to find out if there's a bug in that code. That post alone is not remotely sufficient to claim there's a bug in kqueue. Also, after a fairly cursory examination, I've already found a case of uninitialized data being passed to kevent() (specifically, the code puts a struct kevent on the stack, fills in 3 fields, and then passes that to kevent(), even though this leaves 3 fields undefined; see line 169). The other really funny thing this code does is it updates a kqueue from one thread while it's being waited on in another thread. I don't see anything in the manpage about thread-safety, and a comment thread on mio suggests that it may not be safe to do this (https://github.com/carllerche/mio/issues/163#issuecomment-98... - one person says it's not safe, other people say it is safe with epoll, it's unclear whether this is actually true and whether kqueue is safe or not). If it is not in fact safe to update the kqueue from one thread while waiting on it in another that would certainly explain the missing events.
Part of the problem here is that as long as it's "common wisdom" that kqueue is broken, then it doesn't actually matter if it's broken or not, people will continue to repeat that it is. There needs to be actual concrete information about what specifically is broken (and not just "my test app is broken", because as I demonstrated above, your test app may be what's buggy rather than kqueue) so we can track this and confirm that it's still broken on new OS releases.
> the curl site seems to have the code that illustrates the poll bug on iOS per the comment below
As has been pointed out in this comments section already, a strict reading of the POSIX poll spec could be argued to say that an empty file descriptor set is undefined behavior, so I don't find this one poll bug to be terribly convincing.
Umm the behavior of poll changed across os x versions. That's the bug. You don't break user space.
Also I'm not sure how you're claiming it's POSIX compliant given -
* poll() is defined by POSIX and The Single Unix Specification it specifically says:
If none of the defined events have occurred on any selected file descriptor, poll() waits at least timeout milliseconds for an event to occur on any of the selected file descriptors
10.12 and lesser than 10.9 versions poll implementation returns immediately.
And the argument here is that the cited wording assumes a non-empty set of file descriptors, because the way it's worded doesn't make sense if there are no file descriptors. If there are no file descriptors, it's impossible for an event to happen, so there's nothing to wait on.
Also whatever you say - no sane OS vendor keeps alternating between different undefined behaviors causing pain for developers. MS, Linux, FreeBSD - AFAIK they all do everything to not break user space. Linus has famously said - if you break a working userspace binary - it's a bug!
No you don't. Neither behavior has to be buggy. That's what undefined behavior means, that any and all possible behaviors are valid because no specific behavior is defined as correct.
> Linus has famously said - if you break a working userspace binary - it's a bug!
That's a very hard-line stance, and it means accidents of implementation become guaranteed behavior which can be extremely restrictive down the line. Linus obviously believes that this philosophy is correct for Linux, but that doesn't mean it's correct for OS X.
It would be one thing if they always consistently returned immediately in poll if you passed NULL but alternating between returning immediately and returning after timeout with no guarantee which OS version will change it again in future - that's madness. Hey but ok - for you I will say it - Apple can do no wrong!
That's different than the hard-line stance that Linus takes. Either you're deliberately mischaracterizing what's going on, or you don't actually understand what you were referencing.
In any case, just because some API behaved in a particular way in a degenerate possibly-undefined case doesn't mean the OS needs to preserve that behavior in the future. It was probably an artifact of implementation, so if the implementation changes, the undefined behavior may change too. And that's perfectly alright, if it's undefined behavior. Sure, if you are aware of the particular behavior and aware that apps are relying on it, and it's not an undue burden, then it's a good idea to preserve the existing behavior. But that's a lot of "ifs" there.
And No, I am not misunderstanding anything I am sure - as are the libcurl authors! You so far seem to be the only person arguing otherwise with no proof that there is undue burden for Apple while ignoring causing impact s twice for not an obscure library! Ok, I'm done here.
> Apple switches between those (not at runtime - but across OS releases!!) and that's not correct in any sense of the word!
Assuming it's undefined, then sure it is. Linus treats accidental implementation-defined behavior as guaranteed in Linux. But Apple only guarantees documented behavior. If something is undocumented, Apple is free to change it. In practice, they try to keep backwards compatibility (even going to such lengths as preserving old bugs for certain apps based on bundle ID), but that doesn't mean they guarantee backwards compatibility for undocumented behavior, or that they're wrong when they change something that affects undocumented behavior.
> This isn't undefined behavior where code does something and result can be unknown - this is deliberate behavior!
Given that the behavior changed, I'm willing to bet it's not deliberate behavior but is an artifact of implementation.
But it needs to be a regression or integration test
(However I can understand people thinking "ah if you're polling nothing then it immediately returns" instead of looking at the spec)
I personally would not have guessed that this usage is valid at all, since it would always for the timout. If no timeout is specified there's then even the question if it should wait infinitely (makes no sense but matches the normal poll-without-timeout behavior) or not at all.
This behavior is explicitly described in posix, worked prior to OSX 10.12, but behaves differently as of OSX10.12
Where? Here's the [POSIX specification of poll][1], for reference. Nowhere in there can I find that it explicitly specifies the behavior of an empty-set poll. The only really relevant paragraph, with relation to the timeout arg is this one:
> If none of the defined events have occurred on any selected file descriptor, poll() shall wait at least timeout milliseconds for an event to occur on any of the selected file descriptors. If the value of timeout is 0, poll() shall return immediately. If the value of timeout is -1, poll() shall block until a requested event occurs or until the call is interrupted.
But "if none of the defined events have occurred" isn't really evaluable when there aren't any defined events in the first place; the answer is undefined because the question is wrong. Thus, it seems to me that this behavior is undefined, as far as POSIX is concerned.
(I wonder if this could be rephrased as, if ∃ fd∈∅ where none of the defined events have occurred on fd, then poll shall wait timeout…; this if is false (not undefined), so is should not wait the timeout. But then, the standard leaves us wondering what it should do, if not that. I think this reinterpretation depends on equating "any" with "at least one", though.)
(Having poll wait the timeout when passed the empty set certainly seems useful, but whether or not that's standard is a different question.)
[1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/po...
It absolutely is evaluable. If there are no defined events then none of them has occurred. There's nothing weird or undefined about that; the empty set is empty.
> If none of the defined events have occurred on any selected file descriptor
Note the "on any selected file descriptor". If there aren't any selected file descriptors to begin with, then the question doesn't even make sense. I can see how you could read it as saying it should sleep, but strictly speaking it seems like this is undefined behavior.
How so? It just says "If none of the defined events have occurred on any selected file descriptor, poll() shall wait at least timeout milliseconds for an event to occur on any of the selected file descriptors." "Any selected file descriptor" and "any of the selected file descriptors" make perfect sense for an empty array; nothing written there requires or implies any need for the array to be non-empty.
Words have meanings. The document is supposed to be a specification. I care about having programs that work, and that requires OSes to actually follow the relevant specifications. The document is not ambiguous, there is nothing undefined here; a conforming implementation is clearly required to sleep the specified time when passed 0 fds.
No you haven't. Not at all. Not unless you're claiming the word "any" means something different from what it means.
No no, all (certainly any!) of them occurred.
While I would agree that the specification the poll case would favors sleeping I would still guess that it's pretty much undefined behavior as it's not a normal use-case to wait for nothing and would not rely on it.
I don't see why a pure sleep behavior of poll would be wanted anyway, as it makes the eventloop unresponsive until the next timeout - which is normally not wanted in an eventdriven application. Normally I would always have at least one filedescriptor for eventloop wakeup (eventfd, signalfd, self-pipe, ...) in the poll set.
I'm glad Apple chose to develop a different OS for each class of device, unlike say, Microsoft's insistence on the one-size-fits-all approach — it's what made the iPhone popular in the first place.
This isn't what an OS is. It is about 10 levels of abstraction below this. It handles managing virtual memory, IO, networking, process switching, processor interrupts, threading. All the low level nitty-gritty hardware details you need to worry.
These tasks are fairly generic this is why Linux can run on Smart Phones, Laptops, PC's, Watches, and Super Computers.
What you are describing is called a "kernel", which is one important part of an OS. No one (or almost no one) uses "OS" as a synonym for "kernel".
Linux is a kernel. Desktop Linux (Ubuntu or whatever) is not the same OS as Android.
> This isn't what an OS is. It is about 10 levels of abstraction below this. It handles managing virtual memory, IO, networking, process switching, processor interrupts, threading. All the low level nitty-gritty hardware details you need to worry.
> These tasks are fairly generic this is why Linux can run on Smart Phones, Laptops, PC's, Watches, and Super Computers.
You're talking about the kernel Linux, not about an operating system. An example of an operating system is GNU/Linux, which includes much more than just a kernel.
It might make sense on mobile since features and abilities are changing rapidly. For desktop, I'd take stability over new features yearly.
Why do people wait for things to go wrong then make blanket statements about a "better way"?
This makes me wonder if Apple really earned the Unix certification. If it didn't, then the Open Group should be ashamed.
All I know is I'm getting 50% less battery time this week.
Oh, and sqllite-ruby seems to be a bit grumpy.