TVs inherently require a different UI and control mechanism than computers or handheld touchscreens. It's more or less a reskin of iOS, pretty nice, and you can cross-compile/cross-purchase iOS/tvOS apps fairly seamlessly.
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.
They didn't though, they're all Darwin/XNU underneath the hood, it's just the user interface is different, and some of the userland APIs don't cross over.
>TVs inherently require a different UI and control mechanism than computers or handheld touchscreens. It's more or less a reskin of iOS, pretty nice, and you can cross-compile/cross-purchase iOS/tvOS apps fairly seamlessly.
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.
Nitpicking about what words mean when it isn't relevant to the substance of the discussion is always annoying -- but it's even worse when you're actually wrong.
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.
> >TVs inherently require a different UI and control mechanism than computers or handheld touchscreens. It's more or less a reskin of iOS, pretty nice, and you can cross-compile/cross-purchase iOS/tvOS apps fairly seamlessly.
> 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.
Exactly, I'm all for more frequent releases but a yearly one is too frequent. I'd rather have stable features than UI/UX changes every year. Windows is doing the same.
It might make sense on mobile since features and abilities are changing rapidly. For desktop, I'd take stability over new features yearly.
I believe that was sarcasm. It seems unlikely in an organisation of Apple's size that its the same people doing the release/testing processes for all 4 operating systems.
The poll system call is very likely the same exact implementation for all 4 though. If it was a bug in platform specific code then you'd have a point. It's not like they are shipping 4 complete rewrites.
Agreed MacOS/OSX, iOS, WatchOS, and TVOS all are user-land modifications of Darwin/XNU (Next-OS kernel), which is a modification of Mach (BSD-like research kernel).
I don't have macOS 10.12 installed, so I couldn't test it. But I put their test code into an iOS app, and the bug does occur on iOS 10.0.2, on an iPhone 7.
Lots of stuff on macOS gone weird / mental. Try to set thread affinity, for example. Look at their source in /usr/include/mach/thread_policy.h under thread_policy_set and thread_policy_get
Lots of stuff on macOS gone weird / mental. Try to allocate large blocks of memory in a dynamically loaded function. The pointer you get back is a raw non-virtual pointer, then you need to use non-posix calls to map that region into your process's virtual memory space.
Are you saying that when you call dlsym(3) on OS X you get back a non-null pointer to memory that is not mapped inside your address space? That can't be, right? So where does your "weird" pointer actually come from and how is it connected to the allocation of huge blocks?
This is a common error message for a number of CMS's (in this case probably WordPress) when overloaded, and shouldn't reflect upon the validity of the source.
Just tried to track down the details, it looks like I was thinking of an Opam problem specifically, and the last update was about 3 weeks ago, so likely the issue is already resolved.
Thanks for the warning. I put macOS 12 installation on hold for more superficial shortcomings. This one would have taken me a bit longer to find.
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.
Just tried to track down the details, it looks like I was thinking of an Opam problem specifically, and the last update was about 3 weeks ago, so likely the issue is already resolved.
Golang broke on macOS Sierra as well - and since all Go binaries are statically linked, the practical impact is that all compiled binaries stopped working until a compiler update was released.
From the Go1.7 release notes: "Binaries built with versions of Go before 1.6.3 will not work correctly on Sierra."
It sure would be nice if macOS worked as well as Apple was promising a few years back.
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.
I used to have a Surface Pro 3 and the wifi on that machine was mental. I know people have been complaining about wifi reliability on Apple's computers for years now, but the Surface was really something else.
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 had the same issue on my Surface, but Windows 10 basically fixed it. Of course, that was a year after I bought 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.
Wifi was definitely better under 10. The random keyboard disconnections on the other hand... those never got fixed. Maybe it was a hardware problem with the magnetic connector and pogo pins.
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.
I found that was the case pre-NetworkManager/PulseAudio/SystemD, but these days Linux won't stay working any better than Windows does. (My FreeBSD system is still rock solid though)
Surface does have its fair share of bugs. At least in my experience (YMMV) the macOS bugs are more critical and often revolve around NVRAM, which somehow only breaks things for Mac devices.
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.
Is this error only happening when the polled set contains no file descriptors at all?
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.
Returning immediately when nfds==0 is silly: this behavior would introduce a needless discontinuity in the API and requires special-case code in all callers, and all for no benefit. It's like those bad implementations of read_something functions that signal error in the case of reading zero bytes instead of more sanely just doing nothing successfully.
It's subtler than that. It's returning immediately when the number of file descriptors that it fails to add to a kqueue (that is actually going to do the work and that it is setting up) is the same as the total number of file descriptors passed, which it is when they are both zero.
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.)
> "if none of the defined events have occurred" isn't really evaluable when there aren't any defined events in the first place
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.
The question absolutely makes sense. There are no selected file descriptors. Trivially that means no event has occurred on any selected file descriptor. There is nothing undefined here.
You're taking one particular interpretation and treating that as the absolute truth. It's not. You've got a liberal interpretation, and a strict interpretation leaves it undefined. Just because you don't think it should be interpreted strictly doesn't mean the strict interpretation isn't a valid way to read it.
No, it really doesn't. That's what the world "any" means. There is no possible valid other way to read it. It's like saying "2 plus 2 is undefined, because if you interpret plus in a strict way the question is undefined".
If it was written "If there does not exist any selected file descriptor where a defined event has occurred", then I'd agree with you. But the way it's actually written presupposes that there are selected file descriptors.
> But the way it's actually written presupposes that there are selected file descriptors.
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.
We're just going in circles already. It's already been explained that the way the question is written doesn't make sense if there are no file descriptors. I can see why you want to interpret it the way you do, but I don't understand why you refuse to admit that it's possible to read it such that this is undefined behavior.
Because this stuff is important! Functions that behave inconsistently with empty collections for no reason are a major source of bugs. And if you go as far as undefined behaviour then we're talking not just bugs but security bugs.
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.
You keep claiming it's not ambiguous and that nothing is undefined. I've explained repeatedly how the statement can be interpreted such that an empty set is undefined behavior, but you refuse to even acknowledge that this is a potential interpretation of the spec. Yes, the spec should be unambiguous, but that doesn't mean it actually is.
Yes I have. The fact that you seem incapable of understanding this explanation does not mean that I haven't explained it. So please, stop pretending that your viewpoint is the only one that's valid and just accept that there are people who can interpret the wording in a way that you cannot seem to understand.
You haven't given an explanation. This isn't a question of "viewpoint" or "interpretation". The words simply don't mean what you're trying to claim they do.
Yeah, it seems a little bit like arguing whether 0/0 is 0 or infinity without exact specification.
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.
A pure sleep is exactly desirable when poll is coupled to a userspace timer queue. In this case you want to block until the next timer expires or the next io event, whatever come first. It is a fundamental building block of many event based applications.
I can't say I'm surprised. I used to be responsible for the port and upkeep of a relatively low level product to OS X. It was far and away the most troublesome platform. We would frequently run into bugs that had been reported on openradar for years without having been addressed.
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.
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."
To be honest, I'm not 100% sure this poll issue violates the the letter of the standard, although possibly the spirit. Per POSIX, fds must point to an array of pollfds, passing null is a precondition violation and POSIX explicitly says that is UB.
Ironically, given all of the commentary about whether it's conformant for an array passed to a function to have NULL as its starting address, that is not actually the bug here. The bug, as indirectly explained by the headlined article, is actually to do with the array length being zero.
To repeat: The NULL pointer is not the locus of the bug, and this was explained by the detailed discussion from the headlined article. The NULL pointer for the array base is passed to copyin() and copyout() without incident, and those are its only uses by poll().
To repeat: my point is that the test case shown in the article and described in the bug cannot be used to reliably identify a broken poll as passing NULL for fds is, strictly speaking, UB.
I'm not making any claim about the actual source of the poll bug here.
At https://news.ycombinator.com/item?id=12689472 that's exactly what you stated, and you were wrong. The test case has a zero length array; that it what it is exercising; and that is the locus of the bug, as the headlined article's detailed discussion makes clear.
Sierra + the lack of MBP updates has me seriously looking around if I can switch to Linux for my next setup. The Dell 5500 laptops look nice, and I have purposely kept my tools as platform agnostic as possible. So far my list of problems are:
* 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.
You could run Windows on dual boot just for lightroom. I use lightroom myself and I never do any development at the same time I use any Adobe products.
Actually, I remember my finite element analysis professor running on a MBP in a VM both Catia and ANSYS, which are hungry programs resource wise. And on top of that, he was running a bunch of browser tabs, PyCharms, and a few other things on OS X. And it was impressively responsive.
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.
Its not about the processing but the graphics. I have tried Lightroom and Photoshop in a VM a while ago and the rendering was a little off and very slow.
The combination of GPU and what software you're using for VMs might matter too. Intel graphics are probably out. GPU virtualization is far from perfect but I've seen some surprising results.
Lightroom is very demanding both in processing and in GPU. Also you need proper screen color calibration to get accurate results.
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.
Yep, for the price, I can't say I'm impressed with my XPS 9350. The 4k screen is nice, but the shoddy WiFi chip plus random wakeups from sleep make it a real pain.
I don't think the 9350 has whitelists, but I've already seen how tricky it is to open (on site screen replacement 4 days after I got the device...), so I'm wary of getting out the screw driver for now.
I replaced the Wifi chip with an Intel one and have had no problems since.
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).
It amazes me how often an otherwise good-to-high end set of hardware will have a shitty wifi card. You put all this effort into a nice screen, good keyboard, etc. etc. and then you choose a wifi card that is bottom of the barrel just to shave a few bucks off your manufacturing costs?
If you find one, let me know. I'm in the market to replace my 2013 rMBP 15", and I haven't found anything else that hits the sweet spot in terms of combining a high-DPI screen with great battery life (8+ hours).
Right now, just wait. I'm not saying they'll be the answer, but it'd be daft to jump ship before waiting to see the new Macbooks that are expected to launch this month.
Just switched from a MacBook Pro to a ThinkPad, myself. It's early days. Everything you mention was/is also an issue for me.
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.
> * HiDPI does not seem to work as well on other platforms.
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.
Yeah, I found it very application specific. MySql Workbench for example is a mess. 1/2 the app scales, the other 1/2 does not. The problem is that I don't want to have to spend time constantly tweaking DPI settings.
I've been using a HiDPI ThinkPad T550 for almost one and a half year with Linux. One of the greatest annoyances is having displays with varying DPI (internal HiDPI+External StdDPI), I have simply settled on dedicating the internal monitor for the browser where I have zoom set and using other monitors for everything else. Whereas this just work on macOS, resolution independence with various DPI monitors is a great experience with no headaches.
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.
> 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.
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.
HiDPI is a lot better on Linux than it used to be. The biggest pain point is if you're mixing applications with different toolkits you'll need to tweak your settings in multiple locations. It's not too bad though, and there is good documentation on setting it up. It doesn't look as good as OSX (mostly because of font rendering), but better than Windows in my opinion.
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.
The font rendering in Windows is indeed pretty bad, I don't think it's just you. I use a Surface Pro 3 and it can be uncomfortable after half an hour. Part of that is the poor ergonomics as well, but the fonts are hard to read.
"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.
(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."
Not only the font rendering. Windows 10 acts (at least for mem) like a complete shitshow with 2 monitors (1 HiDPI, one a regular 1080p panel). All sorts of programs break while moving from one monitor to another, even built-in stuff
This is something, at least in my experience, that the mac has been particularly good at handling. Which is odd, because the multi-monitor situation on the mac was a mess for the longest time.
Ditto. Running Ubuntu 14.04 and using 1password via Wine. The extension works under both Firefox and Chrome. I followed the install process they have documented here: https://support.1password.com/1password-in-wine/
> HiDPI does not seem to work as well on other platforms.
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...
HiDPI on Windows tends to be a nightmare due to the fractured GUI elements within the whole ecosystem. Between NTVDM, Win32, .NET and VB apps alone there are too many differences and inconsistencies to get HiDPI to work, on top of that, due to the 'backwards compatibility' they can't easily fix it. It's highly unlikely that they will break with their past like for example Apple did a few times(first with the motorola->PPC and then with PPC->x86 on top of the Carbon->Cocoa and Classic->Unix switches) .
I had an issue when running Linux on my Mac where it would never suspend while closed so it would get really warm in my backpack. One of the big reasons I switched back to macOS.
Yeah, running Linux on Mac hardware is a pain, Windows PC's or computers from companies like system76 generally don't have a problem with suspend under Linux nowadays.
Oh you'll find new entries for the list. Linux on the desktop is nowhere near macOS. I'm saying this as a huge fan of Linux on the server, who frequently tries it on desktops.
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.
I think this is a touch dramatic - the Linux desktop is free, open and there are really great projects out there which don't recommend the command line (see elementary: https://elementary.io/)
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
Can you recommend a better Linux experience for someone who wants to be able to turn their programmer-brain off when trying to watch Netflix? That's not a challenge -- if there's a better distro for civilian use than Ubuntu, I'd love to give it a shot.
I've been exclusively Linux as my desktop and laptop, personally and professionally, since the 1990s, and I manage Linux on laptops and desktops of some family members. I am very much of a 'back-end', 'server' kind of guy. My desktop has dozens of 80x24 terminals and a big web browser window, typically running under http://www.6809.org.uk/evilwm/
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.
I dunno, man -- I feel like constant user-experience problems, bizarre hardware issues, and endless configuration tweaking is both unreliable and bullshit. I often contemplate switching to a Linux system, even if just for a change of pace, but I can't justify giving up a platform that allows me to get the vast majority of what I need to do done without waging war against some other programmer's neuroses.
That's very fair. Most of my non-work computing tends to follow typical consumer trends, and most of my work computing isn't meaningfully compromised by running macOS over Linux (now that VMs are usable, at least) -- but I can imagine that if I depended on applications that don't have clear macOS equivalents that Linux would seem far more "reliable and no-bullshit" to me.
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).
Yeah I'm on an HP Spectre 13, just released, and with Fedora 25 (prerelease!) and kernel 4.7.7 and 4.8.1, I'm getting 6 hours of active work, and 9-10 when mostly idle.
I'm not sure when was the last time you used a modern Linux desktop environment, but I'd say that there are a few that are pretty polished right now. Pantheon and Gnome spring to mind. This is especially true when you install a nice GTK theme.
When video drivers crash - do all GUI applications still crash with the display server?
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.
You might also want to think about using a distribution that emphasizes stability more. Arch is a great distro for people who want a bleeding edge, but it's strength is not stability. Debian is probably the most stable, Ubuntu LTS releases are decent as well.
Yes but Debian and Ubuntu LTS both take more time to be sure everything is working and then don't mess with it. The "stable" bit there means less change so less chance of things breaking.
> Arch is a great distro for people who want a bleeding edge, but it's strength is not stability.
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.
I switched to linux for my laptop this year and encountered surprisingly few problems. The distribution defaulted the KDE plasma and I certainly don't feel punished for leaving the command line.
[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.
Couldn't agree more.
I have been using Ubuntu from the beginning till 2013 exclusively watching the system becoming more and more mature but I was constantly tackling small problems. Suddenly the external projector won't work via HDMI anymore, then there's a codec for an audio file broken, and updated crashes apt and you spend hours trying to fix things.
Since Windows is not an option for me, I switched to a Mac.
I am very upset that Ubuntu is supposed vanguard of Linux. My experience with Ubuntu has largely been negative. You have random crashes of daemons and apps that I do not see on my gentoo system...the same exact processes!
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.
Cannot agree more with this, I've been using Arch for close to 4 years and it's been much more stable (!) Arch is rolling release (!) than Ubuntu has ever been.
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.
>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.
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.
I mean I can't speak for you as I can only speak for my experience and experience of people I know.
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.
So what distro is supposed to be the one that 'just works' now? It's really a shame how Ubuntu has degraded, in the 10.4 days I found it worked very well out of the box.
> * HiDPI does not seem to work as well on other platforms.
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.
Of course you shouldn't take it to that extreme either, but if you need DPI scaling for content to be readable then you're past the point where increasing the density further is meaningful.
So make applications that scale appropriately to the screen. The OSX hack of pretending the screen has exactly one quarter as many pixels as it does for certain purposes is clever and looks good on the tiny range of hardware that OSX supports, but it is a hack and not really a sustainable solution for a general-purpose OS (how does it end up looking on a 4k TV? On a high-DPI projector?).
It's not really a hack and it's not the way it actually works (unless you have an extremely badly written graphical app and dismiss every OS API). On top of that, it works great on most hackintoshes as long as you use proper supported graphics hardware. TV's, VR headsets, projectors, monitors, it all works fine. The only problem you have is when you get used to it, almost all other operating systems and non-HiDPI displays are utter crap.
FWIW, CSS uses a pretty similar hack - CSS pixels are defined in terms of a virtual 72 DPI resolution that does not correspond to screen pixels. In both cases, there are APIs available for DPI-aware apps which want to do something smarter, and the hack has been quite successful in supporting high DPI rendering while retaining backwards compatibility.
I'm sorry, but I'm wondering if you have ever seen a HiDPI screen. No way I'm going back, after getting used to the clarity and less eye strain.
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.
Yes, that. On macOS, that was indeed a pain, on day 1 in 2012. Four years later, I can't even remember the last time I used an application that didn't support HiDPI properly.
>HiDPI does not seem to work as well on other platforms.
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.
If you can mitigate or stomach the data collection in Windows 10, it's a real contender nowadays for a good development machine. If the Linux integration isn't up to snuff (I haven't actually used it yet, my dev is all over PuTTY sessions anyways), you could probably put some of the money saved from buying a MBP alternative into more RAM and use a VM.
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.
While I do agree that Windows 10 is much better than Windows 8, it still is way too annoying for me to even consider it for my main operating system.
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.
> 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 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).
It was a specialty (gaming) mouse. I think your breakdown on why vendor driver software still sucks is entirely correct, but it overall ends up making it a poor experience for the primary use cases I have for an operating system. At the end of the day it's just another reason not to use windows. And of course, the driver software has it's own automatic updates that require restarting every single time even for minor version/bug fix updates. I totally believe you that the vendors could do a much better job if they tried harder, but no one is forcing them to.
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.
Having just setup my gaming PC with an external SSD that can boot up as a ubuntu based machine learning workstation, I wholeheartedly agree. Desktop linux is brutally bad. At least they finally fixed the fonts. My current desktop is split into two because my 4k monitor which uses dual-dp is recognized as two monitors. Also, I had to install Nvidia drivers myself post install on a 640x480 desktop. The whole thing is laughable.
It was much easier getting nvidia-docker, tensor flow and caffe running than getting the desktop to limp along.
I personally use both macOS and Arch Linux and am much happier with the Linux experience:
- 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.
> We would frequently run into bugs that had been reported on openradar for years without having been addressed.
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.
> 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.
HFS+ in general makes my butt pucker. It's the only one that occasionally eats itself under regular use. Usually so badly that a restore from backup is the only solution.
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.
My guess is they switch the numbering system over and call it macOS 11. There's no sign of Apple breaking from the lockstep yearly releases with iOS feature integrations, and next year is their one shot to make the version numbers line up.
Even though AppleTV nigh unto runs iOS, and you could even sort of ask the system what version of iOS-ish it is running, the version numbers for tvOS were always annoyingly not the same as iOS ones (I think always earlier by a major revision).
MacOS refuses to recognise that there is even a filesystem on the drive, and if you have to do recovery it involves just scanning the remnants filesystem looking for magic numbers without any metadata (like filenames!). I've seen it happen on three different laptops now (not all mine unfortunately, mine are at least backed up!).
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.
Microsoft did and does today. Personally, I've submitted 6-7 bugs to them over the years, for Windows and other products, have gotten patches delivered in weeks, and rolled into a normal update roll up on 3 occasions. With a security issue, the program manager for the product called me back personally and arranged to have engineers onsite work with our folks in mitigation.
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.
My general algorithm is : Q: is this problem likely to appear on HN? If YES then no need to submit radar report; if NO then problem affected user base too small to escalate radar report thus no point wasting time with submitting a radar report.
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.
Does any major desktop system have a working bug-process? Microsoft seems to respond with "reinstall and don't call us again", the various Linux distributions let the ticket wait for a few years, then mass close them with "applies to old version". Apple's "tennis with the Pacific Ocean"-response to tickets has already been widely discusses in this thread.
I mean, that is a great point. Bug fixing in general is not a sexy part of hackerdom. No one remarks about how great project X is with replying and fixing their bugs. It's like a working toilet, people only care once it no longer works.
This is an issue in the kernel. You don't report this to the distro vendor but to the appropriate kernel mailing list. In this case the interface to user space is broken AND it's a regression, so it would be appropriate to cc: Linus. Chances are high it's fixed in the next -rc release (i.e. within a week).
Post edit: the above was fascetious. Linux is excellent but is also clearly the product of many years of community evolution, and it shows in its many quirks.
If you don't upgrade until xx.yy.5, then it is a great UNIX. By "dot dot 5" they've usually fixed the things they fucked up in dot dot 0. This means I'm a year behind, but I can run the latest in a VM (VMware Fusion is awesome) for testing and builds, etc.
There seems to be a general lack of interest in maintaining the underlying UNIX system well at Apple, for various reasons. It's frustrating that a large company with a lot of money is unable to handle OS projects with the seriousness and attention to detail that they deserve. Wanting to release a new version of the OS every year with some shiny new features for the end user should be balanced with stabilizing and improving things under the hood. I'm deeply disappointed that such focus on the Mac and macOS is lacking.
Apple clearly doesn't care about the Mac platform and derives only a sliver of revenue from it compared to iPhone, music and app sales. Apple believes that Mac exists solely as platform to develop iOS apps.
I doubt any "additional" money spent on macOS/OS X would make a huge difference to Apple's bottom line. But it would show that Apple is serious about the platform. Money itself is not the issue, but a serious lack of management attention right from the top. Craig Federighi is a nice and funny communicator who knows software (at a deep enough level usually not expected in large corporations for someone in his position), but something is clearly missing in the entire pipeline.
> I doubt any "additional" money spent on macOS/OS X would make a huge difference to Apple's bottom line. But it would show that Apple is serious about the platform.
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?
> 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.
If apps and content are developed on OSX then they will be first-class citizens on iOS devices for end users. If Apple gives up on OSX to milk revenue from iOS, what happens when the hottest new apps and content are second-class citizens on iOS devices because everyone is developing/authoring on something else?
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.
They care enough for those of us that see Mac OS X, as an operating system using Swift, Objective-C, Cocoa, drivers written in C++, Metal, playgrounds and sandboxed applications, with little or no interest to UNIX PDP-11 CLI compatibility.
No. One of the worst spots to be in for a company is for your revenue to be dependent on one product. 'Services' is dependent on iOS/macOS (App sales, Apple Music, iTunes, etc.). Apple needs the Mac, because it's currently their only other product besides iPhone/iPad that brings in significant revenue (and not just dependent revenue).
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.
I think Jobs did believe in Unix, as a way to have a system that doesn't fall down all the time; just he wasn't perhaps on board with all the crusty bits that come with Unix.
More likely it was that Mach was a fully functional free OS. Next only had to slap a GUI toolkit on top of to have their own OS. Also as it was a teaching OS, so it was easy to find reference material + developers.
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.
> 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.
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/
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.
I feel the developer experience has improved substantial, mostly because homebrew is simply amazingly stable and up-to-date. I don't care about the build-in ruby or git because it's replaced immediately anyway. I guess the experience is different for people doing system-level C.
But this is a /workaround/ for the base system being poorly maintained. Apple provide Ruby, Python, and a whole host of other languages and tools on the base system. There's little excuse for them not to keep it up to date and functional. The default "experience" is miserable.
> how many people continue to insist to me that OS X is a great UNIX. It may be a great desktop OS
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)
>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.
Anything specific? Because I don't find anything "butchered", apart from the usual assortment of bugs.
Multi-monitor support got pretty effed up around 10.7 or 10.8. It had something to do with the new full screen app mode.
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.
> It seems like 10.6 is the agreed-upon high point for macOS
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.
> 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.
> 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.
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).
If by "effed up" you mean it now works in a way that is actually really useful. Previously, all monitors shared a single space, so you couldn't switch between spaces on one monitor without switching your others. Now all monitors have independent spaces, so you can switch spaces separately, and you can fullscreen an app on one monitor without affecting another. It's soooo much better now.
"I remember discovering that unnamed semaphores don't work on OS X"
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.
On Mac OS, you must initialize Mac-OS-specific members of struct sockddr_in to zero, or it won't bind a local listening socket. You can't fill in just the address family, address and port.
It is generally a good idea not to pass unitialized struct members. Since the BSD socket API is meant to be extensible, new struct members could be added at any time. Enforcing this rule leads to more robust and portable code.
That is simply nonsense. The members are not documented in POSIX or anywhere else.
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.
FreeBSD also has the same .sin_len member that macOS uses. If you still do not believe me that this is allowed, here is the relevant section in POSIX.1-2008:
I don't dispute that certain structures can have additional members.
A good example is "struct tm" from ISO C's <time.h>
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.
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).
POSIX leaves it ambiguous whether you need to clear it or not.
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.
So implementations are free to add whatever extra members they feel like.
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.
So raimue's point is explicitly true for sockaddr_in6; while it is
left ambiguous whether the (allowed) implementation-defined members of
sockaddr_in must be initialized.
[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.
For IPv6 that makes a modicum of sense, because IPv6 has additional fields in the address not directly related to identifying the endpoint, and these have been historically in churn.
There is no ambiguity: there is no requirement in POSIX that the additional members of struct sockaddr_in be initialized by the application. The requirements are given for sockaddr_in6 only.
Why is sin_len that necessary? The socket functions have a length parameter, including bind:
int bind(int sockfd, const struct sockaddr *addr,
socklen_t addrlen);
If this redundant length is necessary, why is it okay to lie and set it to zero? The length of the address sure isn't zero.
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.
Depending on your architecture, access to data of different size needs different alignment. You may never have heard of it, as it mostly does not exist on x86 except for special instruction set extensions such as SSE. However, by using structs of different size, you could violate these alignment requirements on ARM, SPARC, MIPS, etc.
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.
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 liked OS9 better. I never understood the move to OSX, which instantly made all OS9 software perform worse or not perform at all.
It is nice that Apple tried to make UNIX users a little more at home with a BSD-like userland. But BSD, Linux, Plan9 all have better kernels than Apple.
It feels like I am the one crying out in the wilderness. I not been a developer on mac OS but I use it for computational science and the user experience in the CLI is terrible compared to linux.
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.
One of our devs also found that getdirentries returns a bogus too-large value when given a buffer much larger than needed to store the actual data on return, and fills the remainder of the buffer with 0. This caused an infinite loop in our code, as we continually processed empty strings. This behavior is new in 10.12.
getdirentries() is deprecated as of 10.6 because it doesn't work with 64-bit inodes, according to the man page. The manpage recommends using readdir().
Late adopter here. I never update to any new operating system from Apple on any of my devices what I need to use for production up front. I usually wait until I absolutely have to upgrade otherwise something does not work, or if I have evidence that the new OS runs well on the device I am going to install it on. This saved me a lot of headaches in the last 5-10 years. Given Apple's no downgrade once you upgraded attitude with MacOS I would say it is extremely risk to update to any new operating system version. For those who are not familiar, it is not supported to downgrade MacOS by Apple, they upgrade the firmwares many of the devices in your Mac during an upgrade and there is no official downgrade for those. It is possible with hacking, I know, but I would not risk warranty with such a method.
There's risk both ways... By updating you risk breakage. By not upgrading you risk security issues and increase technical debt (which is a risk amplifier).
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.
Security patches are available for the previous version, the trend is that the previous 2 versions of OS X receive security updates. Would you mind giving me an example of technical debt? I am not sure what you mean by that. Just to confirm, I am not missing out on security fixes at all, I am updated all the way to the latest version with security patches with the previous version of MacOS.
I'd guess not "ransom", but not enough resources allocated to backport fixes, along with a lack of incentive since they fixed them already in the gold standard New Version.
Oh, I completely agree. I've ranted about this before; I like to use old versions and be a late adopter after all the kinks get worked out. I'm just saying maybe it's more due to a (possibly negligent) misplacement of priorities than to outright malevolence for non- or slow-upgraders.
"We're Apple... everyone always uses the latest versions of our stuff..."
Also a fan of the late adoption on OS X / macOS new versions.
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.
Running Mavericks here without incident. I avoided the WIFI debacle with Yosemite. Unfortunately cannot upgrade Xcode or Safari past version 9 - a fair trade for an OS that works I suppose. I'll switch to Chrome and not use Xcode. Swift? I hardly knew ye.
You can find many bug reports referencing OS X kqueue brokenness - however if you want to get to the details of what's wrong with kqueue impl on OS X - you will have to do that yourself - test out various use cases, look at libev source code and try to get it to use kqueue on various OS X versions, get it to pass all tests - iow lot of work. It seems to be acquired wisdom to ignore kqueue on OS X for many OSS projects. As this thread also shows it (poll which use kq) worked on previous version but broke on Sierra which alone seems to be enough to ignore 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.)
Poll may be implemented using kqueue, but that doesn't mean that a claimed bug in poll means kqueue is buggy. Specifically, that HN comment you're linking to is talking about testing poll, not testing kqueue, so it's irrelevant.
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.
I am not sure what you are trying to argue. It seems to be a well known and accepted fact that kqueue and poll both are buggy on various OS X versions - badly enough that Google shows many Open Source projects avoid using both. If you need more proof - the curl site seems to have the code that illustrates the poll bug on iOS per the comment below. If you're saying kqueue isn't buggy because you couldn't find proof - as I said you can investigate more as to why various open source projects don't use it- perhaps there are comments in code, perhaps you can test all osx versions for all the test cases? (The libev docs I linked to clearly state poll is buggy because it's implemented using kqueue.)
I can believe that there are bugs, I just want to know what they are. I'm not going to spend ages trying to test all sorts of corner cases to find out what they are myself.
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.
The fact that behavior changed doesn't mean it's a bug. If the behavior in question is undefined behavior, then it can be subject to change without warning.
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.
Every other UNIX like platform behaves one way (returns after timeout for empty/NULL fd set) and always has, but if you want to pick the interpretation that makes it a non bug in OS X - then you have to agree that it was buggy under OS X between 10.9 and 10.12! Can't have it both ways :)
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!
> you have to agree that it was buggy under OS X between 10.9 and 10.12
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.
I think this is going beyond reason - not correct for OS X?! What does that mean? It's not just Linux either - MS does the same thing. You don't cause developers and users pain by randomly changing stuff - correct or incorrect to you doesn't factor. If something was working it is a reasonable expectation for any mainstream OS that it will continue to work. If you don't agree with that then your choice - the world hasn't worked that way in a while.
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!
> You don't cause developers and users pain by randomly changing stuff
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.
So you are saying you will feel better if you made the assumption that it is a burden for Apple to stick to one behaviour _and_ you will ignore that a very popular library curl was depending on it and so far had to twice adjust their code. But yeah we will assume undue burden for Apple to keep it working one way.
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.
If it's undefined behavior, libcurl shouldn't be depending on it. And the fact that they were bitten by this behavior in the past makes me wonder why they decided to depend on the behavior since then. And I'm definitely not the only person arguing otherwise because what got me thinking that this might be undefined behavior was someone else's comment arguing that. Besides, popular opinion is not what defines a spec, so even if I was the only person arguing this way that wouldn't mean anything.
That is NOT undefined behavior. That is at the most not-clearly-defined behavior that is bounded, with TWO possible outcomes - Apple switches between those (not at runtime - but across OS releases!!) and that's not correct in any sense of the word! Dereferencing NULL/Wild/free()ed pointer (again not applicable to this case - we are not dereferencing the NULL FD set - NULL here specifies empty) is undefined behavior - not specified if that will fail silently or cause you to call a function or trap or a hundred other things - not bounded or in other words without specific choices. Vastly different from either return after timeout or immediately. Do one thing consistently, preferably same as what other UNIXes are doing, or if you do otherwise stick to it. This isn't undefined behavior where code does something and result can be unknown - this is deliberate behavior!
There are more than 2 possible choices if you read the spec as leaving the empty set case undefined. There's 2 choices that are likely to result, but that doesn't mean the implementation can't do something else instead.
> 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.
Now you're just being deliberately offensive. I do not appreciate you implying that I'm a troll. I've been nothing but honest throughout this whole discussion and have explained my reasoning many times. The fact that you interpret your disagreement with me as proof that I'm a troll is incredibly arrogant.
In the specs of the poll function I don't find anything that says if you pass NULL as the fds then also it will wait for specified timeout. Am I missing something?
"If none of the defined events have occurred on any selected file descriptor" - This statement is not same as passing NULL.
Passing NULL is treated like passing an empty fd set. If there are no file descriptors to check, then "none of the defined events have occurred on any selected file descriptor" is trivially true. The same would hold for non-empty fd set and no defined events, I'd imagine.
It is kind of tricky to define this situation formally. Much like if a statement says "Given a list of numbers" than does empty list denotes a list of numbers? There are arguments for both - yes it does and no it doesn't - but the only way to select any one argument over other without conflict depends on additional constraints in the definition like saying "Given a list of numbers where the minimum length of list is 1".
Ahem! The problem is not the NULL array start address. It's the array length being zero, and thus equal to the number of file descriptors that poll() fails to add to the kqueue, also zero. Read everything referenced by the headlined article, and you'll find this.
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.
In released products, no. In development kernels it's a bit more like the wild west. It was only a few years ago that dup3(2) was broken in a development kernel. That's a very fundamental syscall, especially when you consider that some libraries replace all dup2 with dup3 to get O_CLOEXEC behaviour.
Of course these things get fixed very rapidly, so completely unlike this Apple/poll story.
I was perhaps being stary-eyed and naive, but I expected that Linux would have a comprehensive test suite which would catch this sort of thing, at least for the most common syscalls.
I assume that they at least test, and may even test before integrating, but when things are merged into HEAD, changes in various subsystems might affect one another, or some such.
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
It's not a similar situation at all: Linux doesn't break POSIX semantics (well, not here: MADV_DONTNEED has an... "interesting" interpretation of POSIX, so there's at least one violation, but that's not the exact topic of discussion, and seeing as it's not one of the most used syscalls in POSIX, it's less of a problem. Although it's still bad. If you're interested in the sins of the Linux kernel, you can go see Bryan Cantrill's lightning talk on the subject).
If you closely enough at the spec, it is unclear if this actually a violation.
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 .
If you look closely enough at the spec, almost anything is conformant. But it's generally acknowledged that breaking everybody's code is a Bad Thing.
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.
321 comments
[ 2.1 ms ] story [ 166 ms ] threadI'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"?
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.
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.
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.
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.
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:
So implementations are free to add whatever extra members they feel like.However, about IPv6 it says:
So raimue's point is explicitly true for sockaddr_in6; while it is left ambiguous whether the (allowed) implementation-defined members of sockaddr_in must be initialized.[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.
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.
http://www.unix.org/what_is_unix/history_timeline.html
I liked OS9 better. I never understood the move to OSX, which instantly made all OS9 software perform worse or not perform at all.
It is nice that Apple tried to make UNIX users a little more at home with a BSD-like userland. But BSD, Linux, Plan9 all have better kernels than Apple.
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."
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'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.
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.
"If none of the defined events have occurred on any selected file descriptor" - This statement is not same as passing NULL.
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.
All I know is I'm getting 50% less battery time this week.
Oh, and sqllite-ruby seems to be a bit grumpy.
This makes me wonder if Apple really earned the Unix certification. If it didn't, then the Open Group should be ashamed.