Thursday, January 05, 2017

This Blog Is Being Discontinued.

Thanks to Blogger's recent notice regarding the "advertisement" of the use of cookies by Web sites (including Blogger themselves):

"European Union laws require you to give European Union visitors information about cookies used on your blog. In many cases, these laws also require you to obtain consent.

As a courtesy, we have added a notice on your blog to explain Google's use of certain Blogger and Google cookies, including use of Google Analytics and AdSense cookies.

You are responsible for confirming that this notice actually works for your blog and that it is displayed. If you employ other cookies, for example by adding third-party features, this notice may not work for you. Learn more about this notice and your responsibilities."

I don't think that I would like to partake in those responsibilies, considering that the author of the Web pages resides neither in the United States nor the European Union. The same cannot be said, though, about the pages themselves.

So therefore, this Web site is now closed. It shall be destroyed soon, and I shall no longer make any more contributions to it.

It's not that I don't like blogging—on many occasions, the reason why I make these blogs is because there is something I would like documented, because I haven't found them documented anywhere else. It's simply the fact that I don't see why I should be responsible for something that is, quite frankly, out of my duristiction, and something I should not be imposed in doing. So this leaves me no choice but to discontinue the site due to this uncertainty.

Scavenge what you like... you have a while to do it. It'll be gone soon, for good.

All the best in whatever you find left on the Web that is without any responsibilities other than the Copyright laws of the countries the sites you visit are based.

Oh, and by the way, this site uses cookies in ways that I didn't anticipate nor endorse. Sorry!


Monday, May 30, 2016

Restarting My Thoughts, Again!

Sorry for the hiatus, but this time, it was due to my lack of care with my maintenance of some tools!

I noticed that the older versions of MarsEdit (2.4.4) that I used on my older machines no longer work with Google’s authentication mechanisms for Blogger.  This has left my older installations of MarsEdit practically useless.

However, the latest one (3.7.7) works, so there’s no excuse for me not to blog!  I’m now just limited to blogging on one particular machine.

More later as I conjure up more ramblings to dump here.



Friday, March 28, 2014

Microsoft Doing What I Suggested!

Many eons ago, I wrote that:

"... so, what's there left for Microsoft to do? Do what they did back in 1985... make software for Apple's hardware. While it is not hard to see that eventually, market share for Microsoft's Windows 8 operating system may gain popularity in the marketplace as people migrate their existing solutions to tablet computers (or at least, to Windows 8 and beyond), the initial first step for Microsoft should be to make some incarnation of Office that runs on an iPad. It'll buy Microsoft time to perfect their systems for tablets as the tablet manufacturers strive for market share in an Apple-dominated world, while offering an iOS product in the meantime to perk the interests of Office users everywhere.

So, Microsoft... how about it?"

It looks like Microsoft have done exactly that. Those who have a Microsoft Office 365 subscription are able to download and install Office (that is, Word, Excel and PowerPoint) onto their Apple iPhone, iPod or iPad, with no extra cost to the subscription!

For the first time since owning a Mac, I am genuinely impressed! Microsoft may have acknowledged that while Windows 8 may be in a bit of trouble, and it has demonstrated that it is not willing to deny Office users (and that's a large proportion of the global population) from working on devices they actually own. Who knows... maybe when Windows 8 picks up pace in the marketplace, Microsoft will be given the opportunity to re-develop their Office products for their touch-friendly Windows RT environment for both ARM- and x86-based portable devices, and realise the making of a successful transition into the mobile computing market, something that Microsoft are currently missing out on.


Labels: , , , ,

Sunday, March 23, 2014

The King of All Desktop User Interface Pests.

There is one thing that both Mac OS X and Windows are guilty of, and that's the poor implementation of notifications that come from background applications.

I am rather easily alarmed and enraged whenever a background application presents me with a window or dialogue box whilst I am typing in another window, and I continue typing into that new object just to discover instantaneously that:

  1. I have no longer been typing into my intended window,
  2. I may have modified some controls in the process of typing into that window by mistake, and
  3. I obviously hit a key that made the window that just appeared go away, without giving me a chance to see what it is I altered in that window!

And justly so; I cannot trust a computer system that tricks me into doing something I don't intend. Regardless of the purpose of the intended behaviour from the background application doing the deed, it is not reassuring when you activate something that you don't know what, or input data you did not intend, all because of a user interface that changes without warning by apps running in the background… and often more than once in the time of a second.

Windows 8 and iOS have both solved what I consider this as a serious user interface problem, because they both provide dedicated notification services that applications can exploit in ensuring that notifications are flagged to the user somehow, without getting in the way of what the user has been doing in another window. Notifications are out of the way—in another dedicated panel that cannot, by design, interrupt what you are currently doing—and can be called for at the user's convenience.

Both the Windows 8 desktop, and OS X 10.9 Mavericks, feature notifications services that applications can use to send notifications to users, but unfortunately, because notifications are a new concept to these environments, applications need to be re-engineered in order to use the services. Older applications that run under the new operating system environments will still exhibit this painful habit of throwing widgets in your face at the most unexpected moment and catching you off-guard.

However, it was in 1990, when Macintosh System 7 was born, that notifications were done right. System 7 introduced a very good implementation of a notification system for a desktop environment, using the application menu on the right side of the display, and the user interface implementation of MultiFinder which was already established long before. The menu that would normally be used for selecting which application you wanted to switch to could also show that a notification was pending for applications that were running in the background, in which case they would only perform their “alert me” operations when you brought them to the foreground, if they hadn't done so already.

“If they hadn't done so already”, here, means that they may have already displayed their window or dialogue box before posting the notification. But how would this not interfere with the user in the same way the current-generation operating systems do? System 7, right through to Mac OS 9.2.1, make all windows belonging to an application appear in their own “layer"—a behaviour introduced in MultiFinder since System 5. If a background application brings a window to the front, it never appears in front of any window belonging to the current foreground application, which is the application that has your attention. The window may appear at the front, but only in the context of that application; the window is never placed beyond the confines of its own layer. When the application is brought to the front by the user, that window will become the front-most window as the entire layer is brought to the front.

When Mac OS X replaced Mac OS 9 as the operating system for Macintosh computers, it introduced a flaw which has never been fixed to this day—a unified window stack. This allowed windows from all applications to appear in any position in the stack, without any management between prescribed "layers”. While this may have been useful in some circumstances where a user could more finely control the ordering of windows on the desktop without regard to which application a window belongs, this also introduced the serious user interface flaw, where a background application could bring a window to the front, in front of a foreground application—one that has the current keyboard focus. This caused the elevated window to acquire the keyboard focus and hijack your keyboard input without prior notice, and without your intention.

Windows offers the Multiple Document Interface (MDI) APIs, which could be used by developers to restrict windows to appear only inside its parent window, and thus prevent windows appearing in front of other windows belonging to other applications in the desktop user interface. With application developers—and Microsoft themselves—discouraging the use of MDI in Windows versions beyond Vista, users will run into this problem time and time again with no resolution in sight, unless software developers employ the notification techniques used in Windows 8 RT.

Macintosh users fare no better, except with one nice feature. In Mac OS X 10.2, a change had been introduced to the Dock which, when an application icon in the Dock is activated, allows the Window Manager to bring forward all windows belonging to an application, in the same stack order in which they originally appear. This feature allows a more sensible and compatible approach to bringing an application to the foreground in comparison to Mac OS 9 (which did run alongside Mac OS X at the time). In an effort to reduce confusion among users using both systems, the new feature made Mac OS X behave more like older Mac OS versions when it came to bringing applications to the front or hiding applications. But the changes do not prevent windows from being arbitrarily shuffled about as the user interacts with the system [without the Dock], and they do not prevent windows from background applications from spontaneously appearing over the currently active foreground window.

If there is one reason for not trusting a Mac or a Windows machine due to flaws in their user interfaces, this is definitely it. iOS is the only currently-shipping operating system that has had some significant attention to detail applied to its notification system, one that does not interfere with the user, and one that does not allow background applications make surprising appearances. While there are changes to Mac OS X and Windows which may help in avoiding spontaneously-appearing windows, developers of software for these systems, in combination with the operating system vendors who have allowed the flaws to appear in the first place, will need to change their software and their design habits to use the new services and avoid making these nasty traps.

I sincerely hope they do, because fixing this stupid problem is long overdue!


Labels: , , ,

Thursday, March 06, 2014

May the Real Steve Please Stand Up?

In a Wired article entitled "Microsoft Is a '2.5-trick Pony' According to Steve Ballmer", Steve himself is quoted in saying:

"I won't try to tell you that our record of innovation is perfect, but I'd say we've done more tricks than anybody else," [Steve Balmer] said. "Apple's done two, we've done two-and-a-half—half for Xbox."

Actually, Apple have half a "trick" over Microsoft if you understand what Steve Balmer's definition of a "trick" is: their first successful "trick" was the Apple II… a product that lasted as an available and supported platform for over 10 years. Apple's second "trick"—the Macintosh—was one that was developed and released whilst the Apple II was in its hey-day. And of course, Apple's third "trick" was their mobile devices and infrastructure based on what is now iOS.

Steve Balmer seemed to have missed the fact about Apple's first "trick"… probably because Steve wasn't working at Microsoft at the time the Apple II became the world's most successful computing product of the time, if not all time.



Monday, February 24, 2014

You'd Think the Computing Industry Would Stop Stereotyping Women Already After 40 Long Years!

The ad on the left is an ad for Honeywell's 316 of 1969—their repurposed 16-bit “kitchen computer”, which was as difficult to program as any other mainframe with no keyboard, no teletype or video display, and no apps. Apparently [the ad is] specially designed to appeal to women... somehow!

On the right, is Microsoft’s stab at an ad for people who want to be social. Or, to be exact, for women who want to be much more social, yet still have the same vital need for making preparations in the kitchen.

The more things change, the more they stay the same.


Labels: ,

Thursday, May 09, 2013

The Mac As We Know It Is Slipping Away.

The Macintosh as we know it, since its introduction in 1984, may soon disappear as an identity, as Apple transitions its Macintosh line of computers to something that bears a closer resemblance to the iPhone than anything else.

The MacBook Air and Retina MacBook Pro have already started towards this transition, with the iMac not far behind them. Many features that the MacBook Air has introduced along with OS X 10.7 Lion include:

  • solid-state storage memory, replacing disk storage,
  • much larger amounts of system memory; greater than 2 GB, and
  • much longer battery life; greater than 5 hours,

have given it potentially operational similarity with the iPhone, but in a much larger scale. While OS X still has the same operational aspects of earlier Mac OS X releases, there are some operating system features which could soon see major changes as the new hardware features make some of the Mac's existing system software features redundant, particularly:

  • virtual memory, due to markedly improved performance of solid-state memory devices and copious amounts of system memory, and
  • background process scheduling, in an active effort towards extending battery life.

And for Apple's mobile devices that have no internal spinning hard disk, and have less opportunity to be plugged into a power source for charging, these modifications to standard UNIX system services make excellent design sense; replacing the virtual memory system with active process termination facilities is a necessary modification to what is considered staple UNIX system services on an iPhone.

But the Mac has started to appear with the same features as iPhone, all centred around the absence of an internal hard disk drive. With Macs using solid-state storage in place of a hard disk, performance has improved tremendously as one of the longest-living bottlenecks in computing history has been absolved in recent years.

The issue at hand is whether the benefits of incorporating iOS system services into OS X is of benefit for improving system performance in mobile roles, at the cost of losing some existing Mac features may be substantial to compatibility and capacity for server and workstation roles.

It is unclear as to whether Apple will want to abandon the traditional and long-standing UNIX technologies used by their computers in high-performance computing services. Apple still make computers that are notbattery-operated, and may be used as servers or professional workstations in usage scenarios where high performance and reliability are desired. And even for their laptop computers which do have batteries and can benefit from the technologies that iOS has introduced to augment solid-state storage, reducing the versatility of the system software by imposing artificial limits to applications may not be in the best interests of users.

Traditional technologies for UNIX perform feats in computing that would otherwise not be possible on the hardware that the system runs on. Virtual memory services are what allow computers to run more applications, with larger data sets, than would otherwise fit in a computer system. Time sharing is the means by which computers can run many processes concurrently, thereby allowing computers to be busier and more useful in serving the processing requirements of one or more people.

What Apple are potentially proposing with future versions of OS X is an operating system that takes away these two staple capabilities from UNIX. For a mobile role, the reduction of such services makes sense: it reduces the size of the kernel, thereby saving on resources that would otherwise be taken up by services that cannot be used or aren't effective under the given usage scenarios. But for workstation and server roles, these services are of greater utility, since the plan here is to allow the computers to run as many processes and with as large datasets as possible, and run them efficiently.

And OS X is an operating system using a multi-context window system. The window system allows users to display and control many applications at once, since each view of every application is easily accessible. The need to have applications run concurrently is greater than for a mobile platform—for at least one user interface feature, this need is mandatory.

Interapplication drag-and-drop, a feature which arrived to the Macintosh with System 7, requires that the source application has execution context to prepare at the commencement of the drag-and-drop operation, the Macintosh Toolbox to obtain execution context in order for drag-and-drop to be conducted and data to be transferred, and then the target application to attain execution context in order to complete and receive the results of the drag. If the target application were to hang at all, then the application would never be able to respond to the drop event from the Macintosh Toolbox, and the feature wouldn't work. And it is possible for there to be more than one target application: try dragging a clipping over many application windows owned by different applications! If any of these target applications hang, then the entire drag-and-drop operation may cause the system to malfunction.

On Mac OS X, while drag-and-drop operates differently to how it is implemented on Mac OS, it is still a requirement for applications involved to obtain processing time in order to implement the feature. While applications run concurrently on Mac OS X to provide richer user interface feedback during a drag-and-drop operations, the premise of preparation, transfer and deposit are still there, requiring that applications have processing resources allocated to them.

On iOS, drag-and-drop across applications does not exist as a user interface feature. This is a reason or a consequence for the absence of continual concurrent processing.

Virtual memory is a feature which allows one or more users to work with data that cannot be accommodated for completely in system memory. Whether the memory requirements are due to running a large number of applications that exceed the capacity of system memory, or whether the datasets consumed by applications are large, or both, virtual memory allows computers to function without having to handle circumstances where memory resources have been exhausted, allowing applications to continue to run without interruption or special exception.

iOS changes this so that applications, for the first time on a UNIX platform in over 20 years, need to be prepared for handling low memory situations or risk being terminated by the kernel. For an operating system that was originally designed to help ensure the survivability of user programs, and thus simplify the programming model, iOS presents a backwards step in removing system support for virtual memory and induce instability by employing active process termination techniques.

The strategy that iOS uses is not without merit, however. iOS devices do not have a hard disk, and the life span of non-volatile storage is severe enough to warrant special treatment, making the use of a paging file impractical. And system memory sizes on iOS devices have already grown to a quarter of the addressable memory space that their processors allow.

On a modern Mac, the limits are even higher, given the use of advanced 64-bit architectures. Virtual memory, then, appears to be unnecessary at the face of it, but there are a multitude of other reasons why virtual memory is still a useful system service to have available, even on Macs without a hard disk. Users may have the need to run a large number of applications that work on large datasets concurrently. The chances of that being a concern is becoming smaller by the year as new Mac models grow in storage and system memory capacities; conversely, systems reach their useful life sooner when users needs grow beyond what they are capable of.

The ability to handle the amount of code and data processed by the CPU is not the only issue that is directly affected by the availability of virtual memory services. Macs also have other devices available to its disposal, including GPUs—through their drivers—which can also use the virtual memory subsystem in holding data for its needs during execution. Taking away the virtual memory subsystem also limits what the GPU can do.

In addition, current applications assume the presence of a working virtual memory system in OS X. If virtual memory services are removed, then applications need to be re-written in order to implement mitigation procedures for when system memory runs low. Thus changing the memory model of an operating system has direct consequences to system compatibility.

Particularly when some applications are not completely written under Apple's system frameworks. Some applications may be limited to POSIX, which does not support any of the additional features that OS X and iOS support, including Apple Events, Auto-save and Versioning, and Suspend and Resume, let alone any of the Mac's fundamental frameworks. Many of these applications are written as front-ends to POSIX tools that run in the background, such as Disk Utility and Network Utility. Changing traditional UNIX application environments, including the dismissal of virtual memory, may require that these applications and tools be re-written; a staggering amount of work.

A crucial aspect to changing something so entrenched in UNIX legacy that virtual memory is a service that affects every UNIX process on the system; not just Mac applications! There is no interface for POSIX applications to use to tell whether the Mac is running out of memory; the only thing that POSIX can do that is in the best interest of iOS automatic process termination ideals is to deliver a lethal signal and hope for the best. And it is not in the best interests to have programs written against POSIX re-written just to cater for events that will only happen on Apple's UNIX operating systems.

So far, there is no compelling reason to disable traditional virtual memory services from OS X. Even with high performance storage, virtual memory can still be useful in expanding the apparent system memory space to applications. Instead, the automatic termination of processes should be considered as an option for those applications that support Auto-save and Suspend and Resume services, introduced in OS X 10.7 Lion. There are times when the system may ask applications to quit, such as when a user logs out (either explicitly or through a normal system restart), or an application elects to terminate rather than use virtual memory services if the application or the system considers that it is cheaper for the application to quit and restart, rather than for the system to page the application out to disk or storage. Having both services available will allow existing applications to function as expected, whilst allowing new applications of the new system services and provide a potential compatibility bridge with iOS.

While there is some scope for the OS X platform to encompass some of the resource-saving features of iOS, they shouldn't take precedent over application—and UNIX—compatibility. As a matter of fact, iOS requires this to be true as well, since there are many system daemons operating on iOS that implement some of its services. It is important for Apple to realise that developers should be able to choose what system services are best for their applications, and not for Apple to force the adoption of these services through stringent licensing agreements and artificial restrictions.

In short, the Mac should stay a Mac, even if some of iOS does shine through. And it should stay as a UNIX '03 compliant system, too.


Labels: , , , ,