Unix Pioneer Ken Thompson Announces He's Switching From Mac To Linux

ralphbsz said:
Well, some other operating system just moved 32-bit support from tier 1 to tier 2. Bad, but less bad.
Click to expand...

I don't need 32 bit Mac binaries, but this move on part of Apple disabled running Win32 binaries in Wine. I lost a game that way, has to run in a VM now :mad:
 
Beastie7 said:
Meh, that's more of an accessibility thing than stability. I agree it's dumb but you get a lot more with their developer program. Pro's outweigh the cons IMO.

Windows RT failed because Microsoft provided a shitty architecture transition strategy for their developer base. Not to mention the whole Windows 8 UX/UI disaster they put people through. Microsoft is just bad a making software. period.



To name a major few:

- Quartz ( Wayland wants to be this, but has failed for over a decade. Quartz was released in 2005(!) )
- AirPlay/AirDrop/AirPrint
- Continuity
- By-default app sandboxing
- Dynamic memory compression
- Thunderbolt GPU offloading
- Automatic GPU switching
- APFS (yes, the only stable filesystem comparable to ZFS)

As far as DE's are concerned. The desktop was already a solved problem when Apple inherited NeXT. Most (if not all) modern ideas came from NeXTSTEP.
Click to expand...
OK, let's take a look:
- Quartz: It's a graphics stack, not a protocol... It includes stuff like Core OpenGL and GPU offloading... Wayland is a protocol in the same sense as HTTP. The two have very different purposes and designs.
- AirPlay/AirDrop/AirPrint : Something wrong with Samba/CUPS/VLC streaming over wifi? same thing. Avahi / mDNSResponder is in ports.
- Continuity: Today I learned about it. And now that I know - another lock-in thing - it takes another Mac, AND you have to trust it. And no, I don't want to establish that trust every time I pay a visit to a new doctor and have to sign a truckload of paperwork before they agree to see me.
- By-default app sandboxing: There are Linux distros that actually do that. And that's not specific to a DE/WM.
- Dynamic memory compression: Why would that be specifically a desktop feature? There's plenty of ports that can be compiled with dynamic memory allocation option (yeah, not necessarily specifically memory compression). Granted, memory management is a sore issue with www/firefox these days, but I don't think that memory management is totally nonexistent in the Open Source world. You do have to have a good handle on memory management techniques on different OS'es to be able to talk about why specifically 'Dynamic Memory Compression' is non-existent everywhere but Apple.
- Thunderbolt GPU offloading and Automatic GPU switching - This is a driver quality issue, not a desktop issue. Granted, Apple can handle modern GPU's better, and yes, that's most visible on the desktop. But, it's not a desktop issue, any DE/WM would be affected. Tying a DE/WM to a specific GPU driver is not good design.
- APFS (yes, the only stable filesystem comparable to ZFS): Yeah, and in Apple, you can't just swap out a filesystem, install all your old stuff on top of the new filesystem and party.
 
kpedersen said:
Can you copy that program across and still run it on a friend's Apple laptop? It should fail.
Click to expand...
This works for me on (M1->M1 copy), both under my login. Likely won't work if copied to a machine that doesn't have my credentials. This is no different from downloading a random binary from the 'Net. You have weaken your security the way cracauer@ mentioned.

This doesn't bother me; I just wish Apple would explain and apply the security by capabilities model cleanly and consistently or just move to an object capability model 100%. It would also force them to figure out how to reduce the pain of using ocaps (for the end-user).
 
bakul said:
This works for me on (M1->M1 copy), both under my login. Likely won't work if copied to a machine that doesn't have my credentials. This is no different from downloading a random binary from the 'Net. You have weaken your security the way cracauer@ mentioned.
Click to expand...

Cheers for testing. So because I don't have your login details (Apple's DRM key), I couldn't run a binary that you send me. You say I have to "weaken" my security to run it but it doesn't look like this is possible to do on Arm based macs unlike Intel (this is what remains to be tested).

As it stands, I can't run a program from you unless you go online and obtain Apple's permission. I think we may have different ideas about what constitutes security.

bakul said:
This doesn't bother me
Click to expand...
This heavily bothers me because I still use my old Apple II. As it stands, I will still be able to run my Apple II software in about 20 years whereas at that time, software won't run on an Arm based mac since Apple's DRM process (disguised as consumer security) will no longer support it. That seems completely backwards to me.
 
kpedersen said:
Cheers for testing. So because I don't have your login details (Apple's DRM key), I couldn't run a binary that you send me. You say I have to "weaken" my security to run it but it doesn't look like this is possible to do on Arm based macs unlike Intel (this is what remains to be tested).

As it stands, I can't run a program from you unless you go online and obtain Apple's permission. I think we may have different ideas about what constitutes security.


This heavily bothers me because I still use my old Apple II. As it stands, I will still be able to run my Apple II software in about 20 years whereas at that time, software won't run on an Arm based mac since Apple's licensing process will no longer support it. That seems completely backwards to me.
Click to expand...
astyle said:
This only confirms my resolve to never touch a Mac with a 10-foot barge pole 🤮
Click to expand...
 
This only confirms my resolve to never touch a Mac with a 10-foot barge pole 🤮
Click to expand...
Agreed. I really hope I am wrong about this iOS-style locked down bullsh*t but I am no longer surprised if it does prove true. Of course Apple has gone that way. If not today, then tomorrow at least.

Just sad that the landfills will be filling up slightly quicker due to this. Though at least the Linux/BSD port is making headway to pick up the trash left by Apple.
 
kpedersen said:
Cheers for testing. So because I don't have your login details, private signing key or Apple's DRM key, I couldn't run a binary that you send me. You say I have to "weaken" my security to run it but it doesn't look like this is possible to do on Arm based macs (this is what remains to be tested).
Click to expand...

I haven't paid much attention to what Apple actually does but typically "sudo xattr -rc <program or app or pkg>" does the job. Things are I think more involved if you want to debug your own programs :) But I usually debug my non-GUI programs on FreeBSD (and keep them portable to *BSD, Linux & MacOS. Windows I don't care about).
 
bakul said:
I haven't paid much attention to what Apple actually does but typically "sudo xattr -rc <program or app or pkg>" does the job.
Click to expand...
Hmm, I believe a little more will be needed unfortunately. Check out this:

https://github.com/Homebrew/brew/issues/9082

Basically, this describes the problem well. Codesign is 100% mandatory on Apple Arm. This means that packages built by brew will not work on other peoples m1 macs without every builder having a developer license.

Luckily, there is a workaround. I believe their solution is to resign every binary package when installed with the local machines "ad-hoc" signature. A bit annoying but in many ways, that isn't a bad solution. Lets hope Apple never disables the ability to do ad-hoc signing for macOS like they have for iOS.

(anyway, I feel I have derailed this topic a little. I'm going to shut up about my hang-ups with macOS for now ;))
 
I installed sioyek a few days ago using homebrew & had to do the xattr dance to run it. Running codesign --display on it reveals /Applications/sioyek.app: code object is not signed at all!

Will things change for the worse in MacOS in the future? Who knows. This is the usual security vs freedom fight. The majority of apple users are not very savvy computer users and would prefer avoiding malware. And that user semgment is who Apple is catering to.

The fact is, all of the platforms are far from ideal (from my PoV). Plan9: not enough apps, *BSD: poor GUI, Linux: poor GUI and changes far too much, Windows: probably too intrusive (I stopped caring in 2004), MacOS: more user pain. Each individual has to decide what they can live with.
 
astyle said:
OK, let's take a look:
Click to expand...

These are non arguments. Feature-to-feature, they don't exist in any comparable open source desktop experience. Drawing false comparisons or straw man arguments on missing features, licensing, or implementation details doesn't disprove my point. I am not going to waste my or my clients time doing postmortem configuration in a production environment either for desktop features. It should just work™️. ;)

By the way, the Wayland protocol was largely inspired by the APIs written in Quartz (Quartz Display Services and Quartz Event Services in particular); the designs are very similar. Apple just did the extra work (and properly so) to make it themselves instead of dishing the implementation out to other developers.
 
rootbert said:
joking aside, he probably finds most of his ideas and concepts in Linux nowadays compared to MacOS
Click to expand...
Last I heard, Ken was working at Google on Android, which is Linux.
Might it be that he is just eating his own dog food? He has certainly demonstrated precedent...
 
gpw928 said:
Last I heard, Ken was working at Google on Android, which is Linux.
Might it be that he is just eating his own dog food? He has certainly demonstrated precedent...
Click to expand...
hm, maybe, maybe not. Maybe we know his reasons one day. However, there are many good reasons to choose one of the OSes of this thread over the other. I totally understand those Apple fanboys to some point, however, would not even use that crap if someone would pay me money for that ... well actually, depends on the amount ;-)
 
Let's say he does C-development. That can be done on a Window/Mac/Linux. It's not that relevant.
His choice of Raspbian is particular.
 
malaizhichun said:
I'm throwing it away. And I'm going to Linux. To Raspbian in particular.
Click to expand...
I would also like to switch to ARM from my current setup, but what seems to be the problem at the moment is that there doesn't seem to be much powerful hardware that makes this possible.

All Raspberry Pi devices have really (extremely) weak hardware.

There are no affordable motherboards that support ARM Cortex-X3 for desktops, which is actually a shame that ARM is currently so unusable for desktops.
 
bakul said:
I suspect he does most of his coding in Go or C these days. Anyway, watch this 2019 Ken Thompson interview by Brian Kernighan
Click to expand...
I remember watching this and from Kerninghan's general actions to get all computers (and projectors) away from him; at least we know his preference of operating system.

None of them. He is done; he would rather a pen and paper ;)
 
I tend to share the growing disappointment with Apple and macOS. I have two macbooks, from around 2007 and 2017. I had no real complaints for the 2007 machine - when running a terminal it felt like Unix. Simply booting and then opening a terminal and running 'top' would show a hundred or so processes. A bit more than FreeBSD/Linux/Solaris running Gnome or KDE but not excessively so.

Fast forward 10 years. The 2017 machine has a lot more bling and less quality. It's a model with the ill fated Touch Bar (which forced me to write a script to restart it when the processes controlling it hang). The keyboard is flimsier. Repeating the above 'top' experiment and the number of processes is over 400. What the hell is all that crap? Using the machine for development has become significantly more difficult. Running dtrace requires changing the security settings and rebooting. Using lldb requires privileges. For comparison, no real problems with a default FreeBSD install, you have to lock things down to disable debugging. Then there's the DSC (dylib shared cache) - I see the security/performance benefits, but it really make tool development more difficult.
 
Last edited:
kpedersen said:
Probs best to ask Ken why he switched. He knows more than you and I.

But, some off the top of my head:

  • Mandatory online DRM activation during macOS (Ventura+) installation (when your OS is least protected)
  • Mandatory macOS developer DRM for executing your own code on aarch64/m1/m2. An executable compiled by you cannot run on my mac, even if I wanted to or disable gatekeeper unless you rent a developer license from apple (complex, read bottom here).
  • Windows (and macOS) arrogant spying on users and selling to highest bidder is unacceptable.
  • Windows requires online DRM during installation (when your OS is least protected)
  • Windows requires online account during installation (they are preventing bypasses each new release).
  • Windows programs can add themselves to firewall rules. Firewall rules aren't ordered which makes it quite unfit for purpose. So much so that I even suspect foul play in terms of preventing users from controlling internal spyware.
All of these combined either remove freedom from open computing. Or they open up users to major security and privacy concerns. Or they completely destroy lifespan of software via planned obsolescence. This is unethical.
Click to expand...
Mandatory macOS developer DRM for executing your own code on aarch64/m1/m2. An executable compiled by you cannot run on my mac, even if I wanted to or disable gatekeeper unless you rent a developer license from apple.
This is the one that really did it for me.
 
I'm happy with my gaming-desktop-pc. Why ? Even if i don't use all the features of the video-card. It's flexible. Easy to add other disks, extend, has lots of space, flexible bios.
 
kpedersen said:
Probs best to ask Ken why he switched. He knows more than you and I.

But, some off the top of my head:

  • Mandatory online DRM activation during macOS (Ventura+) installation (when your OS is least protected)
  • Mandatory macOS developer DRM for executing your own code on aarch64/m1/m2. An executable compiled by you cannot run on my mac, even if I wanted to or disable gatekeeper unless you rent a developer license from apple (complex, read bottom here).
  • Windows (and macOS) arrogant spying on users and selling to highest bidder is unacceptable.
  • Windows requires online DRM during installation (when your OS is least protected)
  • Windows requires online account during installation (they are preventing bypasses each new release).
  • Windows programs can add themselves to firewall rules. Firewall rules aren't ordered which makes it quite unfit for purpose. So much so that I even suspect foul play in terms of preventing users from controlling internal spyware.
All of these combined either remove freedom from open computing. Or they open up users to major security and privacy concerns. Or they completely destroy lifespan of software via planned obsolescence. This is unethical.
Click to expand...
You've said it all in a nutshell, along with the spyware and telemetry. It's not your computer any more.

A friend of mine does iphone dev using a mac, he has to pay just to be able to download a binary he's written on the mac to the phone. So he does as much as possible in the ide simulator. You're paying to work for them.
 
You must log in or register to reply here.
Back
Top