auxio

dutchlord said:

As if there was a performance problem. I never had performance issues with any Intel/M powered mac. Even my 8 year old Macbook Pro still handles any workflow. It reminds me of another Apple obsession making devices thinner. Apple should focus on more usefull features like extended battery life, satellite internet, cloud backup, touch screen MacBooks etc

The ole, "everyone is the same as me" argument.

Are you building machine learning models? Making movies in 8K? Building high resolution 3D models? Then did you consider that perhaps you don't actually need to buy a MacBook Pro? The word "Pro" is unfortunately just a status symbol for a lot of people who don't truly understand what it means.

avon b7 said:

auxio said:

sirdir said:

If apple had done what they originally promised and opened iMessage and Facetime, there wouldn’t be a problem. 
I’m not a big fan of EU sticking their noses into businesses either, but if they need to be forced to do the right thing… That’s what’s going to happen. It’s the same as with USB-C. If they’d done the obviously right thing years ago, there wouldn’t be a law now. 

Where was USB-C again in 2012 when Apple introduced Lightning?

This was the convoluted state of USB at that time:



It took Apple to show the USB group how to design a connector "right". But pride and/or poor long term memory would never allow people to admit that.

To be fair, everyone already knew how to design a reversible connector. The designers of the original USB variants deliberately ruled out a reversible connector because it would have increased manufacturing costs and it was important to get industry onboard. 

Once it had established itself as 'universal' the reversible connector could be planned. 

It wasn't the costs, it was mainly that there were so many competing interests and they were trying to make everyone happy. Different power requirements for different devices, form factors, etc.

I worked on both the Firewire and USB drivers for Linux and the USB communication/bus control protocols were far far more complicated. Not surprising that, even still with USB-C and having learned from the past, there are still all sorts of bugs and quirks in the driver stack on most OSes. The complexity of USB is part of the reason Apple went in their own direction at the time.

zimmie said:

The power distribution is pretty weird. The power supply has plenty of headroom, but you only get two aux power connectors for GPUs, and they have a weird capacity (120W each, rather than the more common 75W or 150W each). Some GPUs (e.g, the Radeon RX Vega 64) draw exclusively from the aux power connectors, which can cause the system to brown out, even though it has plenty of power budget left (the 75W allocated to the slot isn't used). Wouldn't be safe to draw more over the two aux connectors, which is why there should have been more than two.

A bit late to the discussion, but I was able to put a modern GPU in mine using the Pixlas Mod (splicing another line off the PSU). As you said, the PSU has plenty of headroom it's just not exposed by the motherboard. No one really could have anticipated the amount of power modern GPUs draw back then.

I've been having this experience all along. My problems turned out to be due to the fact that I was trying to use an external hard drive for it. Specifically a USB-C drive. After reading this thread on MacRumors, I switched to a Thunderbolt drive and everything has worked fine since.

BiCC said:

bwilllius said:

The linked documentation describes super awful API calls to creation date and modification date of a file. Also getting free space is now a sin. All calls are harmless.

The MacOS kernal is a Sandbox.  Getting access to free space is going Blockchain style.  I would just like to add - if a kernal is a Sandbox you are 100 percent correct, the API calls are harmless. Why is Apple not giving you access to memory is mindboggling. Through JavaScript you can do a lot, and Apple admits it for URL. I think the management at Apple are spacing out!!  It's out reaching.  Good on you b.

Honestly have no idea what you're talking about. Let's define these words:

Kernel - The core of the operating system which manages system resources (CPU time, memory, access to devices, etc) for things which need to use them. Applications typically don't know/care about what happens at this level, and almost never directly interact with it.

Sandbox - A contained environment in which applications run. Applications get their own reserved storage, memory, etc and can't access the resources allocated to other applications (or the operating system). This is typically done at a higher level in the tech stack than the kernel, which has no knowledge of what applications even are. The kernel only knows how to manage access to low level hardware/resources for whatever is using them on the system (could be a device driver, could be a system daemon, could be an application, doesn't matter).

So calling the kernel a sandbox is meaningless. They're two completely separate concepts.

And applications always have access to memory/storage to do whatever they need to. What Apple is doing is limiting is apps which ask "how much memory/storage is left on the entire system?". The vast majority of apps don't need to care about how much is left, only that they have access to what need. The kernel is the only thing which needs to know how to manage memory based on how much is left on the system.

And then you throw in the term JavaScript, an interpreted programming language typically contained within a web browser environment. So the web browser controls what it has access to. Which is typically far less than what a native/non-web application has access to because the web browser can only give it access to things which are common across every single platform it runs on (from tiny embedded Linux systems to Mac Pros). The lowest common denominator of all those systems.

"Apple admits it for URL" - what does that even mean? A URL is an address for a resource on the internet (web page, image, etc). Sure, it's been hijacked as a means for web apps to send data (URL parameters), which are a classic source of buffer overflow security issues, but URLs have nothing to do with how much an app can do on the system.