dewme
About
- Username
- dewme
- Joined
- Visits
- 932
- Last Active
- Roles
- member
- Points
- 15,798
- Badges
- 2
- Posts
- 6,115
Reactions
-
LabView design & test app abandons the Mac after four decades
Emerson has more than 10X the number of employees as National Instruments has. Emerson has grown substantially over the years through large acquisitions. They are a major player in industrial automation, process control, power distribution, etc., which generally don’t touch much of what Apple does.mikethemartian said:I just received an email that NI is part of Emerson now. I would have expected NI to be the larger company.The industries that they compete in and the software applications and tools that they produce are heavily oriented towards Microsoft Windows, and more recently, Linux. Their employees may use Macs for some of their work, but the vast majority of companies in those problem domains and markets are Windows clients, servers, and embedded servers. I’ve never seen a Mac based product used in a factory setting, but I’m sure there must be some out there.All of these companies are strapped for employees these days so they may simply be cutting back in areas where it’s possible to do so without jeopardizing the company and their customers.
-
iPad mini 7 could be a spec-bump instead of a full update
I also do not find the current iPad mini to be sorely lacking in any major way. It's noticeably faster than my 10.5" iPad Pro. I also use the mini both in SideCar mode and Universal Control mode alongside my Mac. I think Apple purposely treats the iPad mini as a niche product for folks who specifically need or prefer the smaller form factor and are willing to pay for the privilege of owning one. From a bang-for-the-buck perspective the base iPad on the lower end and the iPad Air on the higher end are much better deals. But if you're walking around with an iPad as a mobile interactive terminal for hours on end, for example, in an appliance, furniture, or automobile showroom and want more display or demo space than what a large smartphone offers, the iPad mini is a great fit. It's also a great book reader and couch computer.Eric_WVGG said:The iPad Mini is my favorite device and I will buy any new model sight-unseen (I'm staring at one in "sidecar" mode right now), but I have no idea why they'd bother with a mere spec-bump so soon after the current model. The performance is… fine?Sure do wish they'd switch to OLED though.
I used to think that the iPad mini could be an awesome mobile gaming platform, a scaled up iPod Touch so to speak, but I think the latest iPhone Pros easily satisfy that need, especially with younger people who are now biologically and permanently attached to their smartphones. For schools and kids, the base iPad is much more affordable and compatible with keyboard + trackpad cases that you can actually type on. I've tried a keyboard + trackpad case for the iPad mini and it wasn't a pleasant experience. Because of the mini's niche status the makers of higher quality keyboard + trackpad cases, for example Logitech, have abandoned their efforts to produce such products for the mini. Logitech did a decent keyboard case for the original iPad mini but it was a one & done deal.
About the only thing that slightly annoys me about the iPad mini is the odd proportion of the desktop space allotted to icons and widgets. I'm looking at my iPad Pro and iPad mini side-by-side in landscape orientation and they both have what appears to be the same amount of "gutter" around the area that contains the icons and widgets. While it looks okay on the larger iPad, the same gutter on the mini makes everything look squished together. Fortunately, it doesn't impact Apps.
What makes sense to me for an iPad mini upgrade would of course include a newer and more capable processor, increased storage options, and either Face ID or under-screen Touch ID. Putting the Touch ID in the power/home button was clever and it works very well for me - but only in portrait orientation. In landscape it's very clumsy (for me) when the mini is propped up with the cover. Touch ID wants you to cover the entire button with your finger but doing so is weird unless you are holding the mini in your hands and have associated fingers from both hands with Touch ID. Not a showstopper, but it could be better.
-
Apple releases iOS 17.0.3 & iPadOS 17.0.3 with overheating fixes
Great question.jcbigears said:I've never experienced a more bug-riddled update than iOS 17, and I'm pretty sure I've been through them all. I have had nothing but trouble with Siri, contacts, and watch-face complications. I would like to see an option of being able to roll back to a previous iOS but alas it isn't possible. Is it unusual to get three supplementary updates so quickly after the 17.0?
I'd say that in the past it would be unusual to see so many updates rolled out so quickly because doing releases used to be a lot more work and more costly. They probably would have waited a little longer and accumulated more bug fixes before releasing a bigger update. Today, a lot of software development organizations follow a continuous integration/continuous delivery (CI/CD or simply CD) model which, in theory, means that every build or every daily build is in a releasable state. In other words, if they had to ship the daily build, it would be good to go and fully tested. That's the goal, but I'm not sure Apple or very many software development organizations hit that goal perfectly. Getting closer to the goal still represents a significant improvement.
For CD to work software development organizations have to use a lot more automation, especially around regression testing, but in all aspects of their process from compilation, understanding dependencies impacted by code changes, code signing, integration, version control, change management, installation packaging, etc. There are usually still some processes that require manual testing and verification, but anything that can be reliably and predictably automated without sacrificing the fidelity of the entire software system or introducing variation helps speed up the process is fair game for automation.
So the simple answer is: because they've made the whole update process easier, faster, and less risky they can release far more often without sacrificing quality. While we are annoyed by the frequency of these updates, we are now exposed to the negative side effects of bugs for much shorter periods of time. In a world of zero day security exploits, this model has become a necessity for survival. This is why Apple has spent a great deal of effort on refining their CD process to the point where they can support their Rapid Security Response (RSR) update model. So far, so good. But like everything software related, it's still not perfect. Perhaps AI will help move us closer to perfect. -
Apple confirms iOS 17 fix for overheating iPhones is on the way
y2an said:Why is iOS not taking action on excessive energy use by apps and giving warnings, or slowing them down? That is, after all, why we have operating systems.That is an interesting question, but as far as I know, there is no process level or thread level energy/CPU load limits built into iOS (and iPadOS and macOS), or any other general purpose operating systems that I am aware of. There are specialized embedded operating systems that do energy monitoring and apply throttling or preemption as necessary to ensure that critical system functions are maintained while ancillary ones are preempted/deferred until additional energy is available. For example, a solar recharged battery powered remote telemetry device may cache data readings locally but only upload them to the remote monitoring site when there is sufficient energy available to run the communication devices, e.g., cellular modem and radio, without losing the data collection function.General purpose operating systems like iOS are built around a shared preemptive multitasking scheduler model. The scheduler only has as many CPU cores and hyper-threading (HT) logic available to it as the system provides. Obviously there are always many more processes/threads that are ready to run than there are available cores and HT logic. Additionally, there are some processes/threads that need to run more often to maintain the systems state, manage memory, manage interrupts, manage IO, interact with sensors, interact with the user, etc. Simply put, the operating system is providing an illusion that every process and app is running in its own dedicated machine with its own memory, storage, CPU, IO, user interface, etc., when in fact the system's hardware resources are time-shared (unequally) between every process and thread running on the real machine. The scheduler determines who gets to run at any given time.All processes/threads, both in the kernel and in user mode, get an opportunity to request the priority that they want to be scheduled. If all threads asked for the same priority and if every thread was always ready to run every time the scheduler came around to hand off a core to another thread, and if every thread used their full time quota, all processes/threads would get an equal share of the core/cpu. But that would be disastrous. Things that are critical to maintaining the system state, like pretty much everything done in the kernel, need to run much more often. Thus, the need for priorities and why things that are critical to maintaining the system state (kernel functions) get the highest priority when it comes to running.User mode processes, i.e., Apps we install, must also specify directly or by default the priority for all of the threads they create. How many threads do Apps create? It may be only a few, but it could be hundreds or more. Unfortunately there is no Activity Monitor on iOS, but on the Mac that I'm typing this on the kernel has 647 threads right now, Google Drive has 102 threads, and Firefox has 82 threads, as an example. The scheduler is responsible for making sure all of the threads that are ready to run are given cpu/core time. Of course the highest priority threads get a lot more cpu/core time, but the operating system also has starvation prevention algorithms to ensure even low priority threads do get some time in the cpu/core even when higher priority threads are ready to run. The "ready to run" point is important. Not all threads that exist are ready to run. These threads are often waiting on some event, signal, interrupt, etc., before they are ready to run. If a thread isn't ready to run it does not get scheduled.The Apps that we deal with, like Instagram, run in user mode and at a lower priority than kernel threads. All running Apps compete for core/cpu time against one another as well as the kernel threads. As long as the system has plenty of cores and not too many ready to run threads (varies by hardware capabilities) everyone is happy and the system is likely spending the bulk of its time idling. However, each App creator gets to set the priority of the threads they create and even the core to run inside. In some cases the App creator has determined through testing that their App runs better/faster/more responsively if some of their threads are run at a non-default higher priority. This changes the scheduling behavior on the machine and potentially reduces idle time so the CPU has to run at higher utilization levels, increasing heat.Jacking up the thread priorities in your App, or asking that your thread runs on a specific core, may result in other Apps running more slowly, or put more load on the CPU. But priority jacking isn't the only way to put more load on the CPU. Some developers are uncomfortable with multi-threading because it is hard to deal with concurrency issues, synchronization, mutual exclusion, locking. blocking, waiting, thread lifetime management, etc. So rather than using thread synchronization to provide a way to block while waiting on an event or signal, like an IO input or asynchronous response, they will use a high priority thread as a polling mechanism to constantly check for whatever it is they're waiting for. Polling always increases CPU utilization.Finally, why should we worry what Apps are doing in user mode space when the kernel is always a higher priority? Because operating system APIs (directly or indirectly) result in kernel level threads being created to service the user mode requests. This means that "badly behaved" (from an energy consumption perspective) user mode Apps can still result in the kernel having to schedule additional kernel threads to run and place more load on the overall system. As far as I know, the iOS kernel does not intervene in any way to ensure that Apps do not place excessive demands on the system. It will intervene when the "bad behavior" causes system issues like overheating. That's not to say that it couldn't intervene, but doing so would require cooperation from the Apps and the thread creation process, for example, providing a thread attribute that tells the operating system that the thread's priority can be reduced under certain system conditions.
-
iPhone 15 overheat complaints are inconsistent, and it's unclear what's going on
Everything you’re saying with respect to some apps making higher demands on the operating system and underlying hardware than other apps makes sense. Any app that creates lots of higher priority worker threads and keeps those threads running and doing work will absolutely increase the workload on the system. If those threads are also utilizing other system resources that consume power like the GPU, I/O including the radios and modem, various sensors, and of course the screen it only increases the power consumption and consequently the heat that needs to be dissipated from the device to prevent overheating.jdw said:I know AppleInsider often considers YouTubers a less than reliable source of information, but consider well what one respected tester has to say about the Instagram app consistently raising iPhone temperatures when doing nothing at all, which holds true among different iPhone models...
https://www.youtube.com/watch?v=P6X2ZIkYFsQ&t=478s
Nothing I read in the AppleInsider article seems to address the Instagram app, which as you know is not a gaming app. And like I said, the testing indicates a large temperature increase even when doing nothing. Since Apple vets all apps distributed in its app store, the question becomes how did Apple allow the Instagram app to get their approval? Does Apple bear no responsibility for allowing apps that overheat iPhones to continue to be distributed?
I would appreciate it if you folks at AppleInsider could test the Instagram app and then write a follow-up article sharing your detailed thoughts. Because in my opinion, if the Instagram app can cause heat to rise dramatically for no good reason at all, logic dictates that other non-gaming apps could do so as well. This needs serious investigation.
Thank you.
It’s an over generalization to say that only gaming apps can stress a system. Yes, some games tend to be very resource intensive and spin up a lot of higher priority threads because they are doing a lot of multiprocessing to maintain the computational dynamic models that define the game space and action. Plus they are constantly interacting with the user and need to be as responsive as possible. Basically, there’s a lot of processing going on both in the background and in the user interaction on the screen and through user controls so these apps are telling the operating system they want to run as many threads as possible as often as possible. The operating system tries to accommodate their needs to the extent that it can by scheduling run time quotas that meet the scheduling priorities that the app has specified when it creates its threads. When there is a mix of threads with varying priorities running concurrently (in a time sliced manner) this tends to work well, but if several apps ask for high priority scheduling all at the same time, the system will as fast as it can, consume more power, and generate more heat. Worst case, apps start running too slow in the eyes of the user.
On the other hand, many less interactive apps spin up a threads but a lot of these threads are doing less intensive background processing or waiting in an idle state to be woken up to respond to an event or interrupt. If those events and interrupts aren’t coming at a breakneck pace, perhaps because the user is typing or staring at the screen or little to nothing is changing that needs updating, the demands on the system are much lower.
At the same time, the operating system itself has to run all of its own threads and processes along with all of the I/O and background tasks that it needs to keep the system running and in a consistent state. Fortunately the operating system does assert its own precedence to satisfy its needs over those of the client apps with their processes and threads that have demands of their own.
I don’t know whether Apple’s app review process place restrictions on how much demand an app places on the system. Hopefully the app reviewers profile the resource demands and consumption that apps present and consider whether these make sense for the purpose and function of the app. An app that exhibits unusually high resource consumption could be indicative of an app that is doing something unusual or nefarious in the background, something that doesn’t makes sense based on the app’s advertised functionality. If this is the case I suppose they dig a little deeper and go back to the developer to inquire why the app is such a resource hog in light of what it is supposed to be doing.
Whether Instagram falls into this category is anyone’s guess. But if Instagram is consuming resources and placing unusually high demands on the system for the functionality it provides then I suppose users can inquire about this to the app developer or request additional information from Apple by reporting its behavior as a bug.
