mov rax, 1
mov rdi, 1
and it would bring down the entire OS (kernel panic) when run by any user mode application under a standard non-root user. Took a few releases for them to fix that. I stopped trusting them from a low-level reliability perspective since then.
Fuzzing their system call interface may not have been a bad idea.
P.S. XNU is an interesting as it lets userspace use Mach syscalls as well as a bunch of BSD system calls directly. Probably esoteric interactions between them are not very well-thought-out. (I hope I am not offending Avie Tevanian here :))
Nothing official from Apple on this yet?
It’s definitely something that should be fixed of course.
> This will be a kernel data structure protected by a mutex or semaphore. task_for_pid waits at pri>=0 for a wakeup that won't happen because race. ps queues behind it at pri<0 (disabling ^C). At least two bugs there.
Seems like a reasonable explanation as to the underlying cause of the behaviour.
"The rules for using Objective-C between fork() and exec() have changed in macOS 10.13. Incorrect code that happened to work most of the time in the past may now fail. Some workarounds are available."
But seems like no, actually, at least not obviously.
Which is a huge pain, because it means that if I ever need to use it, I have to debug on a server.
Have you tried the clang or gcc asan/tsan/usan sanitisers as a replacment? There are pros and cons of valgrind vs compile time instrumentation. The sanitisers increase the memory footprint, but run with less overhead. valgrind can detect some errors that the sanitizers cannot etc.
Seems like they pushed a bunch of substantial changes to the kernel.
My example is that there's an empty blank line in the bottom of about half of my terminal sessions. I haven't looked into it, and I assume it'll disappear in a future point release.
I've waited a bit after the "root" security issue, and now I prefer to be on the latest version.
Very much admits an 'I have no idea what I'm doing' experience
On the other hand I find that if every other sentence ends with an exclamation mark, or a question-mark it gets quite exhausting.
I’m sure there’s a cognitive bias partially to blame (since it’s the most recent) but it looks like we are way past that.
In any case, I would say that even a single data point of a kernel crashing bug is cause for concern.
That's why they gave everyone free CDs with 10.1.
Another reason they killed OS X Server maybe.
Remember Apple started down the "server" road decades ago with their A/UX UNIX server (https://en.wikipedia.org/wiki/A/UX). Throughout the 1990s you could get a high-end Mac spec'd as a UNIX machine if you wanted, though I've only ever seen a handful in the wild.
The introduction of a special-purpose server was an anomaly, the Xserve had no specific predecessor, perhaps some kind of "go big or go home" effort on Apple's part.
While that system wasn't bad by the standards of the time, it couldn't compete with the likes of Dell, HP and others who offered way more flexibility on configuration and who would seemingly sell super budget low-end servers at a loss to lock people into their product line so they can squeeze them on support costs, a model Apple's allergic to.
Now there is only Mac minis for it.
You're right that the Mini is a very capable workgroup server, and providers like http://macminicolo.net/ are hosting Mac "servers" by the thousands, so it's not like they've completely given up. Intel's the only other player in this space with their NUC machines and those tend to cost as much or more.
Hopefully they'll kit out the Mini better in the 2018 iterations. That 2012 quad-code i7 variant was an exceptional unit.
What attracted me to move to Mac OS in the first place some 15 years ago was the sheer quality. It was thrilling to use a computer that Just Worked, with no BSODs or the endless dependency hell that was Linux at the time.
It doesn’t feel like that any more, across either OSX or iOS - it feels fragile. Things crash, behaviours are inconsistent, and it feels like more emphasis has been placed on immediate commerciality than long term retention through quality.
For what it’s worth, I’m in the process of moving to Linux on my MBP. The pros of OSX just aren’t as strong any more.
Ubuntu still doesn't let me change my IP address to a static one via the UI and video drivers still crash or result in hours of googling and reading contradicting articles on how to change xorg.conf
Software has bugs. Operating systems are hard. It doesn't matter where you will go, you will most likely deal with similar issues. Whether it be Linux, Windows or macOS.
The same criticism applies to Windows - give it away for free and I might care less about crashes and the huge slide in quality over the last ~5 years.
As it is, it’s the opposite: Macs run both Windows and Linux “easily”, while other vendors’ buggy hardware has to be patched over with heuristics in these OSes because it has non-conforming device names, responses to introspection queries, etc. Apple hardware is uniquely well-engineered. If you’re writing your own hobbyist OS, it’s a breath of fresh air to run it on a Mac, compared to other kinds of PCs.
This is, coincidentally, also the reason it’s so hard to run macOS on other vendors’ machines. Windows and Linux paper over all the brokenness in hardware land, and so machines built for Windows/Linux rely on these heuristics with sloppy integration work. Apple, meanwhile, just does the integration to the standard in their hardware, and then relies on said standards-conformance in their OS. If everyone conformed to hardware ABI standards as well as Apple does, Hackintoshing would be a matter of just dropping a patched dont-steal-osx.kext into your install disc and calling it good. Everything else you have to do is the hardware vendors’ fault.
> As it is, it’s the opposite: Macs run both Windows and Linux “easily”, while other vendors’ buggy hardware has to be patched over with heuristics in these OSes because it has non-conforming device names
> This is, coincidentally, also the reason it’s so hard to run macOS on other vendors’ machines
Are you not aware that OS X does various explicit checks to make sure it is running on approved hardware, regardless of compatibility and capability attestation? Apple doesn't want OS X running on non-Apple hardware.
Er, yes, that's the "dont-steal-osx.kext" that I mentioned. My point was that thwarting those checks is a very small part of getting macOS to run on a system (and is a solved problem—if it was all that was required, Hackintoshing would be a one-and-done thing, rather than something that breaks on every system update.)
The majority of the (continuing) effort of getting macOS to run on arbitrary hardware—hardware that, by its components, should be compatible with macOS's drivers—is dealing with vendors' whack-ass "doesn't even pass static analysis using Intel's own provided AML compiler" DSDTs (which macOS rightfully tosses its hands up at, but which Windows and Linux heuristically munge into something barely passable and then use it.)
> latest high-end Apple and Dell laptops
Dell (along with HP and Lenovo) are the better vendors as far as spec-compliance goes. Really, any of the PC makers who have an "enterprise workstation" arm, have the in-house expertise for things like ACPI compliance, or UEFI compliance, or PXE compliance, etc. But other vendors? Acer? LG? Xiaomi? Razer? Better to not even try.
The result is they have a lot of problems with tin whiskers. Which is why you'll find about a billion forum threads about people baking their macs in ovens, and similar hijinks.
Granted, if you're not using a mac for anything that intensively uses the hardware (for instance, just text editing) you'll never run into this problem.
Xorg.conf is a delightful stroll through a meadow compared to the nightmare fuel that came before, and in setting Linux (Kali,Ubuntu) on several machines of various spec over the last weeks, it has Just Worked.
Optimus is one of those ideas that’s cool on paper, but horribly implemented.
Sure, but it doesn't help when you are rewriting fundamental parts of the stack like the window server, for instance.
And I'm very glad that they did, the move to Metal shows they are committed to the Mac and not standing still. Just don't treat us as involuntary beta testers.
What do you mean? It doesn't get applied?
10.4 felt like the first version that was a pleasure to use. It felt like the polish had finally caught up with OS 9.
Comments that just say "It's a she" or "she" are basically spam and add nothing to the conversation unless the gender of the author is really that important. Since the blog post doesn't mention anything gender specific, I think it's safe to assume these comments are just spam.
The internet is replete with opportunities for getting triggered and starting flamewars. For HN not to sink into a deeper circle of hell, we all need to resist these temptations. So could you and everyone else please not take HN threads on generic, divisive tangents in the future?
It does get extremely boring to read on every article written by or about a woman someone correcting every comment that uses "he" as a generic antecedent, but in the future I will just ignore it instead of inciting a potential flamewar.
Given the relative gender disparity in the technology field, it's easy to make the assumption that any given developer is a man – we all do it sometimes! It's useful to have that pointed out when we're wrong, so that we can be reminded that we sometimes make incorrect assumptions, and eventually it hopefully won't happen as much.
None of the comments along those lines have been needlessly faux-offended, or attacking anyone – just pointing out a mistake that it would be good to rectify. It's really not harming anyone :)
I get that the gender of the author doesn't matter to you, and it may not even matter to the author of the article, but it does matter to a lot of people. No one is suggesting mistakes are a grave sin—even if her blog does say "Julia Evans" in giant letters right at the top. If someone makes one though, the correct response to people pointing it out is to accept the correction and keep it in mind for next time, not to accuse them of spam.
It's not nice to assume "he" to always be the default - that is what was being corrected. One did not have to know that "she" was correct, but it was easy to find out that "he" was probably wrong. Let's keep discussion on topic, rather than venturing into talking about what you're "allowed" to do.
Getting the obvious gender right is a matter of courtesy.
But there's also very uncharitable explanations! For instance, I'm sure I'm not the only one who's noticed that hard technical IT blogs written by women are disproportionally often written by women who were born men (disproportionally wrt the general population of transgender women). Just like the one starting this thread might have assumed that "it's deep tech, so it must be a guy", I can imagine that stevenh assumed that "it's deep tech, so she must be trans". This is beautifully similar to the sentiment of his comment in general, to not under any circumstance let anyone get away with getting gender stuff wrong.
So it looks like even the people who have a strong opinion about being hard on each other about gender stuff, can do it wrong. Maybe the lesson is that we should be slightly less hard on each other about it?
I propose we politely point out mistakes and assume the best intentions (even though of course sometimes that assumption will be wrong).
It's possible to politely point out peoples' mistakes while giving them no room to purposely misgender, which is exactly what this thread does. Let's examine the course of this conversation:
"It's a she" (In my opinion a polite response. This is where any discussion should have ended.)
"Why does that matter?"
"You can't let people get away with misgendering a trans person"
If you only respond to the final comment, then your point makes sense. But the the act of politely pointing out the mistake already happened - now we must justify why it matters.
I agree with you for the rest. I did think stevenh's comment had a needlessly militant vibe to it, which is what I responded to. The rest of the thread lacks that vibe, which is good.