What's an everyday impossible task? It's an eminently desirable task that should be trivially achievable but is just about impossible in common computer systems. ---- '''Multiplexing audio''' For example, listening to two songs or pieces of music at the same time. You double click on one mp3 and it plays. Then you double-click on another mp3 and it stops the first from playing. What the hell is this bullshit? Application-centrism is command-orientation, which is Imperative programming, which is NOT OO. '''If I play MP3's using the QuickTime Player, I can play and listen to multiple MP3's at the same time. Maybe because QuickTime *is* object oriented.''' * Yeah, there's that. Then again there's the fact that quicktime player is crap, with no possibility of enqueuing anything and awkward controls. [I've only one soundcard, and one set of speakers, on my system (not to mention one set of ears). It's an example of SingletonPattern. Of course, with audio you can mix two streams together (in most cases, the result will sound like crap). OTOH, there are other things in computer-land which truly are singletons (or which would become utterly useless if multiplexed).] ''Most users, probably prefer the behavior that only one MP3 plays at a time.'' Most users should have the option, without needing to resort to workarounds. I've run into the identical issue with networking, heard exactly the same replies with regards to multiple video monitors before that was common place, etc. And, for the record, I've seen people start cursing when the internet radio gets cut out when they try to view a training video at work. And I curse all the time when apps reuse a browser window to display their 'welcome' pages. Finally, note that most users would expect that double-clicking an mp3 should ''enqueue'' it, not replace the one already playing; while expecting a double click on a mpeg to show up in a new window. --WilliamUnderwood (btw, BlueAbyss, like Rome, won't be built in a day) ''Click on "Allow Multiple Instances" in your winamp preferences. "Problem" solved.'' [Problem "solved" you mean --cwillu] ''Try using Winamp with any of the DJ cross-mixing plugins, you can play up to 16 mp3's simultaneously'' The fact that you need a tortuous workaround to perform an utterly trivial task is exactly what I call bullshit. The idea of using an application to access basic operating systems functions (multiplexing of hardware and basic queueing) is revolting. And the idea of limiting multiplexing to "up to 16" audio channels is revolting too. What would people think if internet explorer displayed "up to 16" pages simultaneously? ''ok. how about just running media player and winamp at the same time? Playing multiple songs at once(unless dj'ing) isn't trivial, and usually sounds quite bad. I suppose you think using three mice simultaneously on the same computer should be trivial too?'' Having multiple pointers that can be controlled by separate mice should be trivial. And running media player and winamp only lets you play 2 things at once. In addition, it focuses your attention on "applications" instead of where it should be, the objects themselves. ---- '''Running tasks securely''' Create a subuser to run a task securely. People understood the merits of infinitely extensible hierarchies over flat tables way back in the 70s. Three decades later, no one working on Unix has cottoned on to infinitely extensible hierarchies of users being better than a single flat table of them. ''Extensible hierarchies are largely unneeded by using groups. It's the middle # in chmod 755'' Don't bullshit about computer security with me kid. Not only are extensible hierarchies necessary (and groups are complete bullshit since they can no more be defined by users than users can) but extensible hierarchies are simply not good enough. -- RK ---- Edit an email message after it's been sent. Like having a ''private'' wiki page you share only with whomever you specify. (comment deleted as too stupid to respond to) ---- '''Reversibility''' No history. Can't undo commands. Can't undo changes to files. Can't go back to where you were before in the shell / filesystem browser (backspace in windows and cd .. in Unix both take you up, not back). Can't go back to where you were in the RefactoringBrowser; is it a browser or isn't it? Why all this pain? Because programmers think that an irrelevant abstract concept of "root directory" (which is actually just an ''implementation detail'' since object systems are restricted to hierarchies) matters more than the concrete concepts of "past" and "present". ''What about undo commands, journaling file systems, backups, or RevisionControlSystem''''''s, cd $'' Journaling has nothing to do with history and undo only exists in special cases, when an applications programmer bothers to think it might be worth having. As for RevisionControlSystem''''''s and other such "applications", have you ever seen a normal user take advantage of them? Do you think there's a reason why? ''Maybe you should look at the definition of JournalingFileSystem - The word Journal should be a tipoff that it does have something to do with history. I have seen normal users use CVS for everything from word documents to images to emails. They use it when they want to be able to undo changes to files.'' I wrote the page on LoggingFileSystem on this wiki and I know exactly what journaling is all about; NOT history. LOGGING is about history, though only GROSS history at that. Journaling is just about reliability, which is irrelevant. ---- '''Deadness, not liveness''' See a reference, can't follow it. Dead references instead of live ones. For example, you see a reference to another method in the RB (up arrow indicates the present method overrides a higher one) but the reference is dead and can't be followed to its source.