Abandoned Christmas trees are piling up on the sidewalks in the Silicon Valley suburbs, but I'm hoping that some of the season's goodwill hasn't been discarded with them. In fact, I'm counting on it - for I'm breaking both a personal and a Register house rule with the following story. It contains stuff you already know, or stuff you suspected was true, or stuff you have already found more comprehensively and eloquently expressed elsewhere.
Jan 03, 2002 It's Sticky: Although Spring Loaded folders and pop-up windows were relatively recent additions to the Mac UI, they're great examples of flexibility that disappeared in Aqua. If you need to move a file from a desktop into say a 'Work' folder in your Documents 'folder', you're asked to complete a three stage operation. Learn useful and powerful tips and tricks for using Mac Stickies. Find out how to highlight text, change list styles, add images a.
In 2018, Microsoft delivered the much-needed makeover to Sticky Notes with sync capabilities, file attachment, and a complete redesign. At the same time, the company made sure the users get to. Feb 23, 2021 Use a different font in your sticky note. You can change the font used on your sticky note to any of the regular Mac fonts. You can also make text bold, italic, change its size, and more. Here's how: To change text you've already typed into a sticky note, highlight it first. Click the Font menu at the top of the screen.
As a rule, we don't waste your time with solipsistic rants unless they impart some new information or ideas into the public realm [so get on with it - ed.].
Both John Siracusa at Ars Technica and Bruce Tognazzini have raised the same concerns, with Tog warning that Apple's dismal OS X user interface was leading the company into a New-Coke style disaster. But if we can indulge you, this is a battle-tested road report on rubbing along with OS X. That's eight months spent on our own personal kit, trying to justify the investment. And watching the gold CD-ROM cursor spinning, and spinning.
It's the UI, Stupid
Why should the UI matter? And why does it matter so particularly to Apple loyalists?
Well, satellite guru and erstwhile Kaleidoscope scheme author Lloyd Wood summed it up pretty sweetly for us. (You might have recall Wood from his celebrated demolition of Jon Katz).
The Mac had become nothing but a UI, he said, justifying his decision to abandon the platform. Behind the perfect UI, what technology is there hangs together thanks to string and chewing gum. And he's right. The technology behind MacOS is truly awful and should have been put out to pasture by the early nineties. What other modern OS goes into a coma when you linger over a menu for a moment too long? And Mac users have suffered unnecessary crashes, truncated file names (31 characters really isn't such a big deal anymore) far longer than they needed to. Much of that has been cured in OS X, but evidently all wasn't well.
However, I figured that given the human capacity to adjust to new environments, I'd slide into the new UI without too many bruises. This didn't happen, and a few weeks ago reader Tim Priest who set me thinking the unthinkable with these thoughts:
'OS X has some good features. At this time user interface is not one of them,' he wrote a month ago.
'Unfortunately, this is the one thing that has kept Apple buoyant for so long. I know Mac users that are now considering ditching the Mac based solely on the horrid user experience and usability issues that OS X is foisting upon them. I may well be one too.'
Which pretty much summed up how my experience. Then, shortly before Christmas, genial pragmatist Henry Norr confessed in the Chron: 'After months of forcing myself to use Mac OS X, I've gone back to Mac OS 9 and Office 2001.'
Death by a thousand cuts
And so did I, five weeks ago. With one simple click of the startup folder preference panel, we were home again.
I made a pretty simple calculation. I hadn't abandoned OS X because I was disappointed with a functionality deficit - it does a everything a modern OS should do. And then some - the near instant power-on/sleep of the Mac has been improved, and is unique in a modern desktop PC. And it has the best of the old and the new: Cocoa services and AppleScript are powerful environments, which again Apple should be proud of as unique to the platform.
No it's simple: it's the User Interface, Stupid. https://thundersoft.mystrikingly.com/blog/adobe-reader-pro-full-version. We'll be particularly cruel here and bracket performance in as a user interface issue. It's really what marketing types would call a 'user experience' issue, but if performance impairs the usage of the machine, then that's bad UI. And performance on OS X is really NOT GOOD.
Nor is it the file typing and meta data issue that's been so vexing users.
It's been the daily 'stickiness' that's been so infuriating: Aqua has been more a case of a death of a thousand cuts: there's no big flaw so obnoxious it's enough to cause a revolt , but it's felt like a constant hindrance, and the annoyances add up. Here are a few.
I've got a little list
1. It's Sticky: Although Spring Loaded folders and pop-up windows were relatively recent additions to the Mac UI, they're great examples of flexibility that disappeared in Aqua. If you need to move a file from a desktop into say a 'Work' folder in your Documents 'folder', you're asked to complete a three stage operation. Given the window clutter that might be in the way, that's probably reaching double figures.
But there's more to 'stickiness' than feature withdrawal. Nasticity april-16-2019 mac os. The best analogy for Aqua is of a map of the world in which individual cartographers were each drawing a continent, but working off different co-ordinate systems. There's little feel for a cohesive whole, or time-tested user labs over-ruling some of the absurdities.
For example, where does the Dock go? You'll soon find the practicalities overrule aesthetics: for two of the three locations cause niggling problems.
Unless it's been hidden manually, the Dock is always visible, and guaranteed to overlay the foreground application window. Neooffice 2017 4 – mac tailored openoffice based productivity suite. Now, many Carbon applications don't know where the Dock is, so if you maximise an application, the window's resize handle (and there's only one) is now inaccessible. So off you go, and hide the dock, just so you can grab the handle and resize the window?
No problem, you say, just put the Dock on the Left, where it looks kinda neat (and where, I notice, the Apple helpers in the San Francisco branch of CompUSA like to put it at the start of the day on the store's demo machines). But then you get another example of the mismatched UI klutziness: new window instances don't know where the Dock is either. And the Aqua geniuses have put the three control buttons (minimize, maximize, close) on the left hand side. So a new Finder window will appear with the windows controls obscured. That means giving each new window a little rightward shuffle. It's a tiny niggle, but amplified by repetition. My Dock's on the right, which means the arrows point right when the menu springs left, which is plain ugly. But it's the only way to survive.
Stickiness is manifest in other ways, too. A bugbear of mine is the watery-blue sliders in the scroll bars. They feel far more elusive than the utilitarian blocks of grey in the old MacOS, and every other OS.
2. It's Slow:I dare you. Reboot into classic, fire up IE and feel the difference. Despite the speed improvements in 10.1, Aqua behaves far too slowly. Scrolling in the Finder feels still feels jerky, even though the raw I/O performance of X makes far better use of the hardware than clunky Classic. (Try copying a well-populated folder).
But even throwing a 733Mhz G4, with half a GB of memory, at Aqua has worrying side effects. The sheer horsepower of producing some of the Aqua Eye Candy has caused me skips when replaying MP3 files. And I've experienced peculiar, unwanted cut-up effects in the Carbon Sound Studio which may be bugs, but I half suspect are serious timing issues introduced by the CPU cycle-sapping UI.
3. It's Patronising: Face it, you're using one of those large-print books created for adults with reading difficulties. Very useful for people with serious learning difficulties, of course, but immensely patronising for the rest of us, and few OS X reviewers - and John Siracusa is a noble exception - have brought up how big and dumb the new UI looks.
With OS X, it feels very much like your real estate has evaporated. I ran classic in 1024x768 (for the higher refresh rate), and the endless steppes of a 1096 pixel resolution practically gave me agoraphobia.
But in X, I need to crank up to 1280x1024 to get the same work done.
In truth it's down to perception as much as reality: the menu bar takes up no more space in X than in the vintage MacOS. However the default icon font remains absurdly large, and the solution to that has already been crushed by the next great drawback of OS X:-
4. Obey The Steve: Which is where the free-thinking, free-wheeling image Apple has promoted really collapses. Apple has decided that the individualists who use the software can't change a thing about it. You can't even decide not to display no desktop wallpaper, let alone replace the default shell. By contrast, in the wicked world of Windows, shell replacements (or enhancements) like Litestep or DesktopX. Some gaps have been plugged: ASM provides a pull down switcher, but I badly miss LiteSwitch, the keyboard switcher than also let you kill and hide apps as you Alt-Tabbed your way through the task list.
The Dock supports task switching from the keyboard, but incredibly, only in the order that applications appear in the dock. Which is next to useless.
Were Apple to document Quartz APIs many of these grumbles would go away. Kaleidoscope schemes could make a big difference here, for example. As it is, it's adding insult to injury. Apple is laying down quite a cynical challenge to its most loyal users: either trust us and go with us, or beetle off.
5. When Metaphors Roamed The Earth: Docks aren't necessarily evil. The popularity of the NeXT-alike shell WinSTEP on Windows, and the WindowMaker window manager on Linux shows that NeXT's original UI endures. It's a nice way to organise things.
But OS X's Dock is a truly terrible Dock, solely because of Apple's decision to base it for essentially incompatible UI tasks: launching, switching.
6. The Dock Must Go:
By insisting on some traits of NeXT-ish behaviour, but bowing to the most vociferous Apple loyalists, OS X can at times be a horrible hybrid, and you can reasonably argue that Apple has ruined not just one great UI, but two. NeXT veterans who know they're essentially using a port of the OS rue the loss of unique NeXT features, principally services.
(You can get a glimpse of how great NeXT services can be in the Stickies app - it can send text to a browser, email or rich text document with one click). But by basing the OS X shell on Carbon's immature APIs (it's only just become services-aware) Apple was presenting the worst face it could to the world. Which brings us to where we are now.
Budget cuts home to roost
What Apple can do and what Apple should do are two different questions. You can probably guess that I'm not as enamoured of the spatial desktop as some UI purists.
This is an office automation metaphor hangover from the 1970s that works great for folk using disconnected computers with a few dozens or at most hundreds of files. And it works when applications store stuff in discrete files, rather than their own data silo. For example your email client of choice almost certainly stores data in such a format that leaves the application itself as the only reasonable viewer and retrieval mechanism. (And, yes, Eudora stores its mailboxes in plain text format, but Sherlock isn't much use here).
I'd be happy to give up the Mac UI for something better, a UI that lets me tag and categorise information on the fly. We need ways of caching information, just long enough to personalise it.
Microsoft is promising to put a database at the heart of future versions of Windows (it may be SQL Server, it may not) and run the file system as a legacy device driver, which should help with data retrieval enormously. (As well as give Microsoft the default file format for every application for all time).
But Apple abandoned hope of matching such bold initiatives when Jobs axed the R&D budget, despite many man years of investment, when he resumed the leadership. One of the first casualties was OpenDoc, which wouldn't have solved the information overload problem of a Net-attached computer, but would have at least have laid the ground for new UIs ideas.
Apple doesn't need to turn the tables in quite such a fashion as Windows Blackcomb promises: BeOS didn't use a database as the native file storage but the rich file system attributes of BFS gave it many of the same properties. However BeOS was only capable of such spectacular real-time queries because the OS latencies were so low: BeOS journalled the file attributes on the fly, and unless you have a speedy OS, you'll have the crash and grind familiar to Sherlock or Fast Find users.
Sticky And Speedy Mac Osteoporosis
The best we can hope for is that the successor to HFS+, the Mac's current file system, includes many of these features. And that in the interim, the existing Finder/Dock combination is superseded by something more speedy, practical and graceful. ®
Bootnote:
Any suggestions for what to do with my G4? I'll give OS X another whirl with 10.2. It's by far my noisiest computer, and so makes the least lovely candidate for serving or routing duties. There's Linux of course, which I know well. But Linux on non-x86 platforms lacks the applications you expect like native Real, Flash and Yahoo IM clients, for example. It could be fun watching X and Gnome mature on Darwin.
There are still other reasons to covet Apple computers - the helpful community, the above average build quality (we'll charitably overlook the recent run of iffy mice and keyboards), and the buoyant after-market which means your investment is still worth something three years down the line - well you'll have your own favourites. But the Apple user interface is no longer one of them. In fact we have to conclude that with OS X, you're buying Apple in spite of the user interface, not because of it.
In computing, the sticky bit is a user ownership access rightflag that can be assigned to files and directories on Unix-like systems.
When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root user can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files.
The modern function of the sticky bit was introduced in 4.3BSD[discuss] in 1986, and is found in most modern Unix-like systems.
History[edit]
The sticky bit was introduced in the Fifth Edition of Unix (in 1974) for use with pure executable files. When set, it instructed the operating system to retain the text segment of the program in swap space after the process exited. This speeds up subsequent executions by allowing the kernel to make a single operation of moving the program from swap to real memory. Thus, frequently-used programs like editors would load noticeably faster. One notable problem with 'stickied' programs was replacing the executable (for instance, during patching); to do so required removing the sticky bit from the executable, executing the program and exiting to flush the cache, replacing the binary executable, and then restoring the sticky bit.
Currently,[when?] this behavior is only operative in HP-UX and UnixWare. Solaris appears to have abandoned this in 2005.[citation needed] The 4.4-Lite release of BSD retained the old sticky bit behavior, but it has been subsequently dropped from OpenBSD (as of release 3.7) and FreeBSD (as of release 2.2.1). No version of Linux has ever supported this traditional behavior; Linux performs caching of executable files in the same way as all files, so re-executing the program to flush the cache is not necessary.
Usage[edit]
The most common use of the sticky bit is on directories residing within filesystems for Unix-like operating systems. When a directory's sticky bit is set, the filesystem treats the files in such directories in a special way so only the file's owner, the directory's owner, or root can rename or delete the file. Without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of the file's owner. Typically, this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files. This feature was introduced in 4.3BSD in 1986, and today it is found in most modern Unix-like systems.
In addition, Solaris (as of Solaris 2.5) defines special behavior when the sticky bit is set on non-executable files Formating a usb. : those files, when accessed, will not be cached by the kernel. This is usually set on swap files to prevent access on the file from flushing more important data from the system cache. It is also used occasionally for benchmarking tests.[citation needed]
The sticky bit is also set by the automounter to indicate that a file has not been mounted yet. This allows programs like ls to ignore unmounted remote files.
| Operating System | Directories | Files |
|---|---|---|
| AIX 5.2[1] | indicates that only file owners can link or unlink files in the specified directory. | sets the save-text attribute. |
| Solaris 11[2] | If a directory is writable and has S_ISVTX (the sticky bit) set, files within that directory can be removed or renamed only if one or more of the following is true (see unlink(2) and rename(2)): the user owns the file, the user owns the directory, the file is writable by the user, the user is a privileged user. | If a regular file is not executable and has S_ISVTX set, the file is assumed to be a swap file. In this case, the system's page cache will not be used to hold the file's data. If […] set on any other file, the results are unspecified. |
| HP-UX[3] | If […] set on a directory, an unprivileged user cannot delete or rename others' files in that directory. | […] prevents the system from abandoning the swap-space image of the program-text portion of the file when its last user terminates. Then, when the next user of the file executes it, the text need not be read from the file system but can simply be swapped in, thus saving time. |
| Linux[4] | When […] set on a directory, files in that directory may only be unlinked or renamed by root or the directory owner or the file owner. | the Linux kernel ignores the sticky bit on files. |
| FreeBSD[5] | If […] set on a directory, an unprivileged user may not delete or rename files of other users in that directory. | The FreeBSD VM system totally ignores the sticky bit (S_ISVTX) for executables. |
| IRIX[6] | If […] set on a directory, then any files created in that directory will take on the group ID of the directory rather than the group ID of the calling process. mount(1M) may be used to enable this feature regardless of the mode of the directory. | If the sticky bit, S_ISVTX, is set on a file that is a dynamic loader for an ELF executable, then when the executable is exec'ed the old process's read only address spaces will be made available to the dynamic loader in the new process. This can improve program start up time considerably. The setting of the sticky bit on any other file has no effect. |
| Mac OS X (Leopard)[7] | A directory whose 'sticky bit' is set becomes an append-only directory […] in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each other's files. Any user may create a sticky directory. | The sticky bit has no effect on executable files. All optimisation on whether text images remain resident in memory is handled by the kernel's virtual memory system. |
| NetBSD[8] | A directory whose 'sticky bit' is set becomes a directory in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each other's files. | NetBSD does not currently treat regular files that have the sticky bit set specially, but this behavior might change in the future. |
| OpenBSD[9] | A directory with the `sticky bit' set places restrictions on file deletion: a file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the superuser. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each other's files. Any user may create a sticky directory. See chmod(1) for details about modifying file modes. Monkey tales games mac os. | Historically, an executable shareable file which had the sticky bit set was not immediately discarded from swap space after execution. The kernel hoarded the text segment of the file for future reuse, thus avoiding having to reload the program. This is no longer true on modern systems; the current virtual memory system keeps track of recently used executables, making the sticky bit for files redundant. The sticky bit can still be set on files, but without any effect. Only the superuser can set the sticky bit on a file, though the owner of the file may clear the sticky bit. |
| SCO UnixWare[10] | If a directory is writable and the sticky bit, S_ISVTX, is set on the directory, a process may remove or rename files within that directory only if one or more of the following is true:
| If a 0410 a.out executable file has the sticky bit (mode bit 01000) set, the operating system will not delete the program text from the swap area when the last user process terminates. If a 0413 a.out or ELF executable file has the sticky bit set, the operating system will not delete the program text from memory when the last user process terminates. In either case, if the sticky bit is set the text will already be available (either in a swap area or in memory) when the next user of the file executes it, thus making execution faster. |
Examples[edit]
The sticky bit can be set using the chmod command and can be set using its octal mode 1000 or by its symbol t (s is already used by the setuid bit). For example, to add the bit on the directory /usr/local/tmp, one would type chmod +t /usr/local/tmp. Or, to make sure that directory has standard tmp permissions, one could also type chmod 1777 /usr/local/tmp.
To clear it, use chmod -t /usr/local/tmp or chmod 0777 /usr/local/tmp (the latter will also reset the tmp directory to standard permissions).
In Unix symbolic file system permission notation, the sticky bit is represented by the letter t in the final character-place, replacing what would otherwise be x. For instance, on Solaris 8, the /tmp directory, which by default has the sticky-bit set, shows up as:
Sticky And Speedy Mac Os Update
If the sticky-bit is set on a file or directory without the execution bit set for the others category (non-user-owner and non-group-owner), it is indicated with a capital T (replacing what would otherwise be -):
See also[edit]
References[edit]
- ^'Archived copy'. Archived from the original on 2005-01-18. Retrieved 2009-01-19.CS1 maint: archived copy as title (link)
- ^'Synopsis - man pages section 2: System Calls'. Docs.oracle.com. 2011-11-01. Retrieved 2014-04-10.
- ^[1]Archived November 20, 2007, at the Wayback Machine
- ^'chmod(1) - Linux manual page'. Man7.org. Retrieved 2014-04-10.
- ^'chmod - FreeBSD'. Nixdoc.net. 1993-06-04. Retrieved 2014-04-10.
- ^'chmod - IRIX/standard/'. Nixdoc.net. Retrieved 2014-04-10.
- ^'Mac Developer Library'. Developer.apple.com. Retrieved 2014-04-10.
- ^'sticky - NetBSD Manual Pages'. Netbsd.gw.com. 2011-05-10. Retrieved 2014-04-10.
- ^'Manual Pages: sticky'. Openbsd.org. 2014-02-14. Retrieved 2018-02-04.
- ^'chmod(2)'. Uw714doc.sco.com. 2004-04-25. Retrieved 2014-04-10.
External links[edit]
- Unix File and Directory Permissions, 2010, by Wayne Pollock, archived from the original on February 3, 2012
