From now on, I want to be able to filter out any "Top 10" list from some random blogger. Generally, these lists have at least five things that I've already heard about, and five more that I honestly couldn't give a damn about.
It may not actually be an ABI issue. I know that for awhile after the GCC upgrade, Gentoo had patches all over the place just to get standard stuff to compile. So sometimes it's that old code actually doesn't work.
I rather like the fact that (e.g.) you can just globally define USE="-doc" and can avoid any documentation being built.
True, that's a missing feature, but the difference is, it applies at compile time, even if it's something stupid like documentation, even if all it changes is a dependency.
That's often it -- for example, Thunderbird will depend on Enigmail if compiled with crypt support, but ultimately, Enigmail is a separate package, and Thunderbird will be built exactly the same way, crypt or not.
What I would prefer, really, is conditional dependencies -- if you install "HTML documentation", then all programs which can have HTML documentation now suggest their html-doc packages. I don't know if this kind of thing exists, though -- sure, you could do it with Portage, but there'd be no way to go back and re-check it later (install package foo, then install html-docs-all, then have it automatically go back and install foo-html-docs).
A binary-default Portage could just use the USE flag as an instruction to download a certain binary patch and apply it to the package archive before installation.
Maybe so, but I'm not sure I want the same format. USE flags have become huge, way too big to really work well as a single environment variable. They're also so often irrelevant -- does OpenOffice care about Matrox support, for example?
I also don't think it would be as flexible, but maybe it's already overkill.
Yeah. Sure. Microsoft is scared of competition in a free market. Because they've failed at it so dramatically in the past.
Actually, they haven't had it in the past.
What they've had in the past is one little leg-up from a deal in which they screwed IBM, and obscene lock-in to maintain that lead when their products were behind their competitors almost all the time, often ridiculously far behind. I have no doubt that they can produce quality products -- just look back at Windows 98 (which is when I switched to Linux), and Windows 2000. It's just that they don't even seem to bother to make their stuff work until competition forces them to, by being enough better that people start to switch away.
Their response is standard operating procedure, and nobody is losing any sleep over the subject.
We have a name for that -- embrace, extend, extinguish.
If they wanted to compete with a level playing field, they'd have started with ODF -- in fact, they'd have started with an open standard in the first place, rather than creating a sort-of open one because governments start threatening to use their competition.
They aren't scared of linux either. They acknowledge the threat, and they move against it. But that's not fear, that's just business.
Notice how they've moved against Linux, though. It isn't by creating a superior product.
It's actually mostly with BS marketing campaigns. From "we have the way out", an anti-Unix website that actually ran on Linux servers, to "We have a bunch of patents that Linux infringes on", to "Open source is communism"...
Actually, I do. The trouble is, it's already breaking the law to do that (DMCA), and generally, enabling this kind of functionality on my Linux trivially gives me the ability to rip them.
The point I'm making is that there are legitimate hassles to being a good little consumer.
Maybe it's easy to get wrong, but I don't think it's hard to get right. Ubuntu does it well, and Gentoo does it decently.
True, but some people don't trust big corporations to be impartial when it comes to software distribution.
Would these be the same people who bought a Mac?
With self-updating capabilities becoming more and more pervasive in the Mac world (even though I agree that having a central API for that would be nice) the drawbacks are rather small, at least as far as I am concerned.
The drawbacks are no shared libraries, and no one-click to update. You have to trust the app to self-update, and you're hosed if it doesn't. You can't easily add auto-update to an app that doesn't have it already, or check everything for updates without running through every single app and clicking a "check for updates" button. It's also slightly less bandwidth-efficient when there are no updates, or only a few.
currently my Fink is unusable because I don't have the exact build of the GCC it requires and installing said version would require me to download a 900 MiB archive from Apple in order to do a downgrade.
I would suggest that this is because Fink is too slow with upgrades, not because there's something wrong with the design. (I do think there's something wrong with the design, though; the GUI is nowhere near simple enough to replace app bundles.)
Not everyone wants to join the Apple Developer Connection so they can install GnuCash.
True, it'd fall flat on its face unless it was installed and working by default, with no registration required -- just like Software Update.
Maybe a Ports/Portage variant that defaults to using binary packages. That way semi-casual users get their shell apps and power users get the power of USE flags.
USE flags are overrated, and I say this as a long-time Gentoo user. In fact, it was in discovering this and a few other facts that I decided to go with Ubuntu.
Let's take a few random examples:
matroska -- adds support for mkv files. Ok, you might save some tiny amount of space by disabling this. And then as soon as you download an mkv file, you'll have to recompile half your multimedia apps in order to play it.
nptl -- there's really no reason you'd ever want this disabled on a modern Linux system, unless you really want to go back to a 2.4 kernel. And on OS X, you probably can't use it anyway.
X -- Here's a perfect example of the difference between Gentoo and a good Debian system. On Gentoo, if you disable X, you don't get any X libraries at all. This saves a lot of space and time upgrading, with a slight loss of functionality -- even on a server box, I might want something to work with X forwarding. But it'll probably work pretty well -- until you find that one little program that needs X to compile, even if it's not needed once it's running. Back in the days of XFree, this meant game over -- it meant you now had to compile and install the entire X distribution, including an X server and a bunch of video drivers, for a headless box, even if you were only ever going to use that app in commandline mode.
Nowdays X isn't such a problem, because X.org is split into smaller pieces. But on Ubuntu, it can be chopped up by file, not by source package. This means if something needs a particular X lib, it can get just that one X lib, and nothing else. It also helps with plugin systems -- for example, suppose you don't want vorbis support in, say, xmms or something similar. On Gentoo, this means recompiling xmms to add or remove that support. But xmms uses a plugin system, which means that on Ubuntu, there's a single.so that can be packaged separately -- one package to be removed if you don't want Vorbis, one to be added ba
The purpose they serve is to provide a means for converted legacy documents to retain information that would otherwise be lost.
Not true. Read my comment here. The idea is to extend the style engine to be able to support most of the arbitrary crap, so that actual "SpacingLikeWord95" can be implemented as a style in that particular document, and need not be retained for posterity in every single implementation of ODF (or OOXML) -- but implementations that don't truly understand SpacingLikeWord95 will still be able to present the document properly, or search/index it based on arbitrary properties like that.
Those fields are deprecated, not just optional
You know, in most standards, deprecated stuff is deprecated specifically because it is going to be taken out, so the "depricated" notice is to tell you to stop using them before they are removed permanently.
If that's really what Microsoft is doing, then they are basically doing exactly what I suggested (take them out), just more slowly.
and are actively suggested that they NOT be implemented
Then why are they in the fucking standard (and in Word 2007) if they're not supposed to be implemented?
They're not intended to be used in any NEW documents, and I find it highly unlikely that Microsoft would let any apps create deocuments with them.
Ok, so not only are they not meant to be implemented in an office suite, they're not even supposed to ever show up in a document. So take them out of the standard. No need to have a six thousand page standard filled with crap like that.
The whole purpose of the new file format standards is to allow documents to be read long after the applications that created them are dead and buried.
Which is exactly why these legacy tags are a mistake, if they were ever intended for anything other than lock-in.
Since, as you say, it's suggested that you NOT implement them, that means old documents, even in the new standard, will only be readable as long as some version of Microsoft Office is still around. So, if MS Office is ever dead and buried, these documents die with them.
Which kills the whole point of having a new standard in the first place, according to you. (Another good reason for standards is to allow interchange between competing products, but that's obviously not Microsoft's intent here.)
If OASIS had considered this problem, and addressed it in ODF, say by allowing application defined supplmentary tags for legacy support purposes
They do. It's called namespaces.
They are not included in the standard, of course, for obvious reasons. But they are there, even if I think the problem would be better solved with styles.
You know, I'm not convinced you're trolling, but I'm also not convinced that OOXML serves any useful purpose. The only reason we're even having this conversation is that Office supports OOXML and not ODF. Were it not for that, OOXML wouldn't be given a second thought.
Your argument is basically the same as saying "Why do we need a bold tag in HTML, why can't we just specify a style that uses a heavier weight?"
The difference is, HTML is not and never was intended to preserve a document pixel-perfect, the way PDF does. People do not have an unreasonable expectation that bold will look exactly the same on all browsers.
In fact, if you read the spec, you find that it does not expect identical implementations. They do provide an image of what it might look like, but the spec is intentionally vague in order to be flexible.
However, as I understand it, the reason for all this cruft in the OOXML "standard" is so that old documents may be preserved pixel-perfect, in complete implementations -- in other words, in Word 2007, since no one else can produce a complete implementation. And here's the huge difference -- if you look at the language of the HTML spec, it's intended that different browsers might display bold text differently. But if you look at the OOXML spec, it's intended that anyone implementing the SmallCapsLikeWord95 tag (or whatever) should implement it exactly like Word 95.
In other words, the HTML spec is exactly as vague as the standard is intended to be, while the OOXML spec wants you to implement it in a very specific way, but they won't tell you how.
Word processing documents are not just words with formatting (though many people treat them that way), they have tables of contents, links, indexes, styles, etc... semantic markup.
You just answered your own question:
Let's take an example. Suppose you have 10,000 legal documents written in Word 95, and many of them use "small caps" to indicate a specific legal meaning. Now, let's convert the documents to ODF, and those "small caps" are merely converted to a smaller font.
Well, I would actually define a style that is "SmallCapsLikeWord95", but which also defines that the capital letters use a smaller font. It may mean you need a more powerful style engine than ODF currently has -- but by "more powerful", I mean allowing a style to specify a separate font size for caps and lowercase, not having a built-in style that requires every implementation to carry around cruft from Word95.
The result: ODF can have a simpler implementation, while still preserving all the information you want it to -- including being able to search for all your SmallCaps stuff. And maybe now you start using styles properly -- you rename that "SmallCapsLikeWord95" style in the new document to something that reflects what you want small caps to mean.
Mostly because I have not seen any candidates weigh in on technical issues that I care about:
DRM
The DMCA (please legalize DeCSS for things which don't already violate copyright)
Trusted Computing (a step further -- please don't let them restrict what I can run on MY hardware)
Open standards (ODF)
Net neutrality (be very clear here, as the term now means two opposite viewpoints)
Voting machines (Diebold needs to die)
Software patents (Abolish them until reform, at least)
Length of IP (patents and copyrights), especially on software
Frivolous lawsuits (MAFIAA) and DMCA notices (Uri Geller)
Campaign finance reform (no one should be allowed to buy legislation)
I think I've got everything. The trick is to write a letter that is short enough to actually be read, long enough to explain the above to a layman, and polite enough that it doesn't insult the layman's intelligence -- and then to fire it off to all the candidates I would consider in the first place, and see if I get a real response.
Other than, say, being occasionally used by Word, creating documents which break under other implementations, making it look like a bug in those implementations?
two apps demanding specific versions of a library that can't be slotted (granted, that is less common these days).
I'd even go so far as to say that where it does happen, it's possible to work around. There are ways, in startup scripts, to force an app to use a specific library, or to force ld.so to search a specific folder for a library.
When using packages, it is possible to gain all of the advantages of an app bundle, by simply having the package install the equivalent of an app bundle. The converse is not true -- app bundles cannot reasonably do dependencies.
Both Portage/OS X and Fink can be quite capricious, especially when you use both in order to overcome the holes in their package trees.
Which is why I continue to blame Apple for this mess. Apple is, effectively, the OS X distro maintainer; they combine basic things like Darwin and Quartz with a few apps of their own (Finder, Quicktime, Safari) into something that is supposed to "just work" out of the box. They also provide Software Update, which maintains this distro very well. But they don't provide any way to support third-party apps, or uninstallation (and reverse dependencies) for the apps that they do manage.
If Apple were to, say, pick up Fink -- or Apt, or Portage, or anything -- and develop a nice, slick GUI for it, have Software Update use it, and make it possible to add third-party repositories, then this problem wouldn't exist. Fink and Portage would also not exist in any big way.
Also, global dependencies only work when the packages appear in the package tree.
True enough. Ubuntu makes this easy. I'm on Kubuntu right now, and while I usually prefer the commandline, I can go to Adept, click "Managed Repositories", go to "Third-Party Software", and manually type in the URL for a repository. I have several already, including a repository which provides Wine for 64-bit Linux, and they seem to work well together with the main ones.
It's true, that's not actually as convenient, but I'm convinced that's a limitation of the UI, not the system.
What's more, having software registered with Apple doesn't seem to be a big deal. Considering the above, it doesn't even have to be Apple. And considering that just about everything Mac is on VersionTracker somewhere, it seems people actually welcome registering their software with a third party if it means they might have more users.
As for being as convenient as a drag-and-drop bundle -- that only works for a local disk. Basically, if you pop in the CD, and the app is well-behaved, then you can simply drag the.app bundle off the CD and into Applications, and you're done. You can even run it off the CD.
But if you're downloading it from the Internet, you have to download some sort of archive, most commonly a dmg. That means you have to download the dmg, mount it, drag and drop, unmount it, and throw it away. Most people don't understand this process at all, and in fact, I often see people simply mounting the dmg and running it from there. Worse, some open source versions come in.dmg.gz, which adds a third step, and a third temporary file you have to delete on your own.
My humble suggestion is, when you pop in an install disc, prompt the user if they want to install. Then, have a standard set of steps, including setting up that vendor's repository for use in updates. Provide a standard place to uninstall packages, by default have it hide anything the user didn't manually install (libraries and reverse dependencies are hidden). You could even prompt the user to remove the repository, but I think it'd be better to simply remove unused repositories automatically, unless the user manually added them.
Installing apps from the Internet could be made similarly easy -- add a new protocol and handler for Safari, something like app://http://example.com/path/to/repo:nameofapp. You then prompt the user if
Workaround: After following that link, go to the Address Bar and hit enter. Since the referral is now coming from the same URL as the image itself, it'll work this time.
I believe the book was "A Mote in God's Eye", where I first saw this concept explored.
It also seemed to be one of the more hard science fiction books -- for instance, though there was faster-than-light travel between systems, travel within a system was still sublight, and without any sort of artificial gravity or "inertial dampening" -- if you want gravity, you accelerate, and there are couches to let you accelerate faster (3g or so), but when you're not moving, everything's weightless.
(Getting even more offtopic, I wonder if Firefly might've worked just as well without artificial gravity. It'd be difficult to do, though.)
They usually don't even know that such settings exist as they just maintain a list of all installed files.
On Linux, global configuration settings are files. Usually they are treated specially, and are not cleaned up, but apt, at least, allows you to force a purge there.
What it doesn't clean up automatically (but should be able to) is per-user config settings, usually kept in dotfiles (~/.foo). But either those or the systemwide config files are usually only a few kilobytes.
So yes, using the uninstall dialog or the package manager's uninstall function is 100% equivalent to deleting the application bundle.
Assuming that the application bundle was all that was ever installed. Which, if it was, is often wasteful -- it means every application that uses a library not distributed with OS X must include that library in its own application bundle. That means wasted disk space and wasted RAM, but at least all of it is gone when you delete it.
Add to that the fact that any changes made to third-party configuration files (like an X extension changing/etx/X11/xorg.conf)
Not likely. The ONLY time I ever see anything changing xorg.conf these days is installing a video driver, so the only time you'd want to change it is when installing a new video card of a different brand. How often does that happen in the lifetime of an OS?
Where this starts to get problematic is stuff that actually does change the system -- for instance, something that adds a preference pane, a menu, a kernel extension, or maybe a framework or a codec for QuickTime to use. These are handled automatically on Linux via package managers, and on Windows via uninstallers (when they exist/work), but rarely on OS X -- I usually have to Google for how to uninstall that particular app.
The difference is between leaving around a few k of config files that don't hurt anyone, and leaving around actual configuration changes that break the system when you remove the software, assuming you even can.
Again if you had the ability to have rational discourse you wouldn't have confused me with someone else.
That's invalid. It implies that long-term memory of random strangers has anything at all to do with reasoning power, or the other way around.
There is a story about Newton: At one point, he hosted a party, had some friends over, left the room to get drinks for everyone... They found him, hours later, in his lab, working, having completely forgotten about the party -- the one he was hosting. No one questions his ability to reason, but certainly, he was a bit forgetful.
Notice how instead of a straw man, this time you opened with a direct attack on me.
Right, I am sorry for confusing you with someone else. I do believe it would have been an appropriate response to the anonymous coward I originally replied to.
Regardless...
Perhaps you felt attacked by my comment on your lack of reasoning skills
That is true. Perhaps you meant it as an attack. I honestly can't see how you couldn't, given the way in which it was delivered.
Let me translate it into five-year-old, to show you the emotional impact it might have: "Hi, you're too stupid to be my friend. Come back when you're smarter."
And, of course, the typical kindergarten-teacher lecture for you: "If you don't have anything nice to say, don't say anything at all."
Of course, we're not five years old anymore, and I won't run away crying from an attack like that. In fact, I can take constructive criticism without feeling threatened by it -- but that was not constructive.
I might have written a response more like this one -- calm, analytical, and more likely to be correct -- but when you opened with an attitude of such superiority that you couldn't be bothered to write a pointed reply, I didn't feel that I had any obligation to do the same.
however this lack of reasoning was obvious from your post, it is a fact.
Kindly demonstrate it, then.
Do you even know what a strawman argument is?
Yes, usually. Sometimes I have to go look it up to be absolutely sure. Now I'm sure, and it was not a strawman.
Memory segmentation has absolutely nothing to do with installing/uninstalling applications.
That is true. But it does make a convenient analogy. Analogies are not automatically strawmen. Quoting Wikipedia:
Oversimplify a person's argument into a simple analogy, which can then be attacked.
That is one type of strawman, and probably what you mean here. I believe it doesn't apply. Burden's on you to show that I am oversimplifying. Hint: "Everything should be made as simple as possible, but no simpler."
Interesting. You immediately follow that up with another fallacy, that I'm too lazy to look up the formal name for (well, quasi-official name for an informal fallacy):
You bringing it in as an arguing point shows you really have little in the way of support for the point you *do* want to argue.
It shows nothing of the kind. All it really shows, unless you can read minds, is that I brought it in as an arguing point. Anything beyond that is pure speculation on your part -- maybe it was convenient. Maybe I just wanted to incite this argument. Maybe I was possessed for a moment, or maybe I'm even lower than you think, and I copy-and-pasted the whole post.
But I don't have to speculate: The reason is that I didn't feel like putting a huge amount of time, energy, and thought into writing up solid, concrete points -- not when a single analogy will do.
You'll notice, it's done nicely. No one has yet convinced me that a lack of a standard uninstaller is a
I'm sorry, on windows that just runs a vendor supplied script.
True enough. At least there usually is one.
On OS X, there are only two standard, easy ways for a vendor to provide such a script: Either as part of the original install.pkg (meaning you have to insert the install disc or re-download the installer in order to uninstall), or by dragging the.app to the Trash. Beyond that, and you're entirely on your own, meaning the user probably has to dig through your distribution -- either the folder they downloaded, or somewhere in Applications -- for an uninstaller.
In fact, I believe OS X has a perfectly elegant way to uninstall apps installed with the.pkg (or was it.mpkg? It's been awhile), and some people have pointed this out to me. Unfortunately, Apple doesn't provide any kind of interface for this (not even CLI) -- you have to download some third-party software, some of it free now, in order to get a GUI for it.
What do you really need in an "installer" program, for OS level support? Ultimately, any changes made by this program, or by any program on the system in response to activities by this program, have to be tracked at the OS kernel level -- that means that any Open/write/close traces need to be monitored.
That's not sufficient, if you're really going to give it root. All it has to do then is open/write/close a binary or a script, then relax until that binary/script is run -- probably without the "installer" bit set. It can probably figure out how to trigger that automatically, but I'm assuming, for the benefit of the doubt, that you're also following fork/exec like a hawk.
The bottom line? You can't have an installer program if you want any chance of an OS -- Operating SYSTEM level tracking.
That's actually not what I'm asking, in the anal-retentive "The OS is the kernel" way. I'm just asking for some really decent userland support for this.
That means packages with no installer scripts.
Well, a strict interpretation actually allows installer scripts. They just have to be sufficiently sandboxed.
It's not that hard, really. Just have them run as a user with no write privileges except to their own temporary install directory. They can still examine the system and make decisions about where they're going to put things, but ultimately, they can't write directly to the rest of the system.
Which is exactly what Gentoo's Portage does -- except, of course, ebuilds also allow post-installation scripts, because some software effectively requires it, but these are rarely used, at least in the packages I've seen.
However, I think Linux takes a fairly sane middle ground, considering the state of most software today. Software is packaged by a distro maintainer, which means that if there's an installation script, it's going to be done by the distro maintainer, and it's likely to be very small -- much smaller than on a system like Windows (where the simplest things require Registry changes). A very small install script means a very small uninstall script, too. And because the distro maintainers do everything, you can generally trust them to get it right -- there's all sorts of common scripts, like a script to rebuild the initramfs image when a driver is installed or removed.
In practice, the only cruft that ends up being left behind these days is config files, and that's both tiny and optional -- you can, in fact, force apt to remove those for you automatically, too.
Certainly, it won't protect you from someone who deliberately writes a malicious package, but nothing will, anyway. The problem here is one of incompetence. OS X makes it fundamentally hard to do uninstallers well, at least as far as the end-user is concerned. Windows makes it entirely too easy to write uninstallers that don't catch everything, or installers that
Frankly I think of it as a compliment to the operating system that it can support a user who has 20-30 programs open and his biggest problem is finding out which one of them is playing the music....
Well, he also has a brand-spanking-new MacBook (dual core and everything) that performs about as well as the old eMacs in the office, which are something like 700 mhz. Maybe a little worse, even.
Now, this is not a problem for him, but I do think he could save a little money on hardware if he would get in the habit of actually closing stuff when he's done with it.
If I remember correctly, when you have that many apps open in Windows the problem is finding out which one of them is making the music a) Skip, b) Freeze the entire system, or c) emanate from popup ads in spyware.
No, get rid of the spyware and it'll be about the same with any modern OS.
Even worse, most Windows users I know have about 50 icons in their taskbar that slow the system down incredibly.
Here, I'm a little skeptical. See, I have 10 icons in my KDE taskbar, and most of them do nothing but eat RAM. You could claim that slows the system down incredibly, but not only do I have 2 gigs of RAM, I have an OS that knows how to swap well.
Then again, Windows memory management tends to suck, so maybe it is faster with those removed. But then, I never installed much on my Windows system to begin with.
From what I've used (and I have, extensively), OSX tends to lend itself to easier organization.
Well, once you install virtual desktops. And with Beryl, I've got most of the OS X features I was missing.
But the Point is: the system works as well as the user lets it.... PEBKAC
Yet, the root: PEBKAC.
Agreed. But recall, I was replying to someone who was either a troll or a moron. The original quote was:
the cares and worries of real Mac users transcend implementation details
I'm sorry, but the only way you completely transcend implementation details is by buying a new computer when you have a problem, and hiring someone else to move your data over. That would tend to get expensive...
But then, I guess Mac users have money. That's why they bought a Mac.
Even an Ajax app running in Safari requires a graphics layer.
True enough, but consider the difference between running X on Linux and running some svgalib app.
QuartzExtreme is certainly going to be heavy. I'm sure they can strip it down enough to be fast on the iPhone, but remember -- it's not enough to run on a computer from 1996. For the iPhone to work, it has to also feel like a computer from 2008.
I know that one reason that the Mac has a small marketshare is that one is expected to buy software for the Mac, but can usually steal software for a MS Windows machine
Wrong. It's that I expect things like an uninstaller, virtual memory, dynamic memory allocation, and so on, to either be part of the OS, or to be free pieces of software.
There's tons of freeware for Windows, and just about all of the software on Linux is free. But on the Mac, every little thing that I usually get -- legally -- for free, is some little $10 or $20 piece of crap.
And, if one is a geek, it is not too difficult to install stuff. Do a search on the name, and drag the files the trash.
For a geek to confuse "install" with "uninstall" is a bit bizarre...
Anyway, that won't necessarily remove everything it installed, and it certainly won't tell you whether it'll break something else. That's what a package manager is for.
Maybe when you get past your hurt ego, you'll be willing to explain to me why a lack of memory segmentation is an OS issue, but a lack of a standard uninstaller is a developer issue. (Yes, standard. You mention two ways to uninstall, one of which is non-obvious and inconvenient as hell for the user.)
the cares and worries of real Mac users transcend implementation details
Yes, I can see that. It's not healthy.
Just a simple example: I share my Internet with a couple of Mac users. One actually seems to be afraid of me and all human contact -- it's a disorder, and it's very sad, but it means he's not a problem.
The other is just smart enough to know to bother me when his Internet is slow, because I might have a huge torrent open.
And just stupid enough to run something like 20-30 apps at once, with 50 or 100 windows, at least. I'm not kidding.
So, because he doesn't care or worry about implementation details, roughly half the time he bugs me about the Internet, I can actually throttle my torrent so his browsing is good. And the other half the time, I have to tell him to for God's sake close some programs, maybe reboot!
Perhaps the saddest case here was when he had some music playing, and could not, for the life of him, figure out what program was playing it. Eventually, he had to use the old Windows solution-to-everything: reboot.
You know, I'm a programmer, I run Linux, and I typically have maybe four or five programs open, maybe two of which are capable of playing music, none of which are capable of doing it without my consent.
The Mac programming culture is such that things generally play along without the user having to be such a fucking anal-retentive prick.
Oh, bullshit, on both counts.
The Mac programming culture is such that things generally play along with the user, until they don't. When they don't, there's nothing you can do about it, unless you are a Mac/Unix guru, in which case there's very little you can do about it.
And what's "fucking anal-retentive" is that this is exactly the sort of reaction I see from Mac users every time we suggest that there might be some slight flaw in their holy OS. (Never mind that some of the best new features in Leopard are things we already have in Linux and Solaris...)
Oh, true, it's not everyone, but so far, I can count one person who replied to me in this discussion with helpful information and without actually attacking me. A second person provided somewhat helpful information while attacking me, which is normal for the Linux community. I also have one or two replies agreeing with me, and even an anti-Mac troll. And two Mac trolls.
So, of those who actually appear to be Mac users, that's at least 25-50% trolls who replied to my post. People who have nothing better to do than post Anonymous Coward on Slashdot, attacking anyone who disses the Mac. I call that anal-retentive.
Still looking for the "maximize" button when your Mac has "zoom" instead?
Wow, way to miss the point AND look like a retard. No wonder you posted Anonymous, you coward.
No, I'm talking about the fullscreen extension. Since the Mac wasn't designed for one-track minds, you should have no problem figuring out what two words put together means. A compound word! *gasp*
Yes, I'm talking about FULL SCREEN. Not "maximized". Not "zoomed". Full fucking screen. Why is this difficult for you, oh Multi-Track-Mind?
And there is an extension which allows windows in OS X to be forced fullscreen and back, whether they have that capability natively or not. Obviously some apps already do this -- video players, of course. Obviously, others do not -- terminals, for example.
Take the hint, switcheurs: If you can't cope with multiple windows, GTFO. The Mac wasn't designed for one-track minds.
You're talking to someone who works on a 1600x1200 Linux machine, with four virtual desktops -- oh, I'm sorry, "spaces", that feature you're drooling over in Leopard, which probably won't be out yet for another year...
One of those virtual desktops typically has six terminal windows, three IM windows, and sometimes a browser open, not overlapping. Or four terminals, IM, browser, and an MMO, with my email on another desktop, and maybe a PDF or a package manager on a third... Yes, I know how to deal with multiple windows.
So one day, I decided to look for a way to make a window go fullscreen. Because, you know, unlike Linux or Windows, it's not enough for OS X to waste one side of the screen for its menu bar. It has to then waste another side of it for the Dock -- something you all orgasm over because it's so cool and new and different and... oh wait, it's been done in WindowMaker on Linux for years, and it wasn't even invented there.
And as it turned out, this extension was buggy and not as useful as I thought. I could even say you were right here -- I wanted to go back to piles of windows, instead of just the one fullscreen.
Only, there was no fucking uninstall. I had to do it manually -- a difficult process to even find a good walkthrough, and still quite a bit of messing in the commandline to get it done. And I'm comfortable with a Unix commandline -- if I say it's difficult, trust me, it is.
Remember that the Mac was designed by artists, for artists...
Yeah, I guess an artist would just love opening up a terminal and typing twenty cryptic commands just to get the same usable interface back.
Oh wait -- maybe it's because Apple assumes that such creative people would never want to install software. Because, you know, actually using your computer is such a square thing. You'd rather sit around in good taste and masturbate to your bouncy icons and your rounded corners.
And you'll be doing the rest of us a favor, too; you leave Macs to Mac users, and we'll leave beige to you.
Explain to me how it hurts you (other than your pathetic ego) that I have a Powerbook. Never mind that it won't work anymore, and Apple refuses to fix it -- I have one, and I probably know more about how to use and abuse it than you ever will.
But then, I guess I never will, since I'm not a fucking artist. Oh wait -- joke's on you, asshole. I'm a programmer. And I guess if the Mac isn't right for me, then you won't be getting any software from me.
And I don't know about you, but I use a computer to run software, not to stare at an OS and troll about how good my farts smell.
Good job of blaming the OS for developer problems.
You sound like the type who, back before OS X, when a single app could bring down the whole system because there was no memory segmentation, would say "Good job of blaming the OS for developer problems." While meanwhile I'd be sitting over on Windows or Linux or even Solaris, watching the same "developer problems" simply result in a segfault or illegal operation, crashing that one app.
Apple clearly states that any app which is installed via pkg should come with an easy to use uninstaller or be able to be uninstalled via the original pkg.
Easy to use doesn't mean standard. On Windows or Linux, I can open up a central list of installed packages and uninstall from there. Apple's encouraging the old Windows way of doing this, which is to have a separate uninstall program -- hopefully somewhere near where the app is installed -- that's developed along with the app, or licensed from a third party (InstallShield)...
You know, maybe you should think about why the pkg format exists in the first place. Why have a standard format?
Well, it's simple: When I get any OS X app, in any form, unless it's some crazy custom script, I know that to install it, I either doubleclick on the.pkg, or open the.dmg/.zip/whatever and drag the.app to Applications.
But when I uninstall, if I can uninstall at all, I have to think about where I put the.pkg (if there is one), or hunt around for an uninstaller, or drag the.app to Trash and go hunting around for whatever crap it left behind.
Compare that to Linux, or even Windows -- add/remove programs, click "uninstall". Done.
Given the choice between having the OS force a database for all applications or having two choices for application install, dmg (etc...) for self contained-drag and drop install/uninstall and pkg (for things that require elevated privs or scripts), I'd surely take the one with multiple options.
Given that no OS I know of actually enforces one option over the other, I'd say you're talking out your ass.
I'd much rather have the choice of an OS-maintained, or at least common, database of installed apps and how to uninstall them -- without having to keep the original pkg around (how retarded is it that you have to pop in the original install disc in order to uninstall? Maybe the whole REASON you want to uninstall is that you lost the disc needed to run the app?)
One thing that really bothered me on OS X was its complete and total lack of an uninstall feature. This was especially annoying, as I'd hoped that the "drag to trash" was really a fancy GUI for some sort of real package manager.
I mean, sure, if your app is entirely self-contained, you can just drag it from Applications to Trash and be done with it -- at least that's no worse than Linux, where per-user preferences are left alone, but nobody really cares, since it's only a few K of disk space and doesn't affect anything else.
But what do you do about the random app that installs kernel extensions, browser extensions, and generally insinuates itself among all your stuff? You know, the cool stuff like Insomnia, the SMS-to-HID driver, or the force-any-window-to-fullscreen extension? Or even multi-desktops, or something as simple as a VPN?
Often, the uninstall instructions for these are at least as complicated and unnecessary as anything you hear people complaining about for installing software on Linux.
Oh wait, I forgot -- there's a proud Mac tradition of making you pay $20, $50, or $100 for random bits of third-party software to implement stuff that should have been in the OS to begin with. In the past, it was things like dynamic RAM allocation and swap space, and now, it's an uninstaller.
(You could complain that Windows is the same way, needing third-party stuff like anti-virus, but most of what you need on Windows is either bundled with the OS or available for free, often open source. And you don't really need anti-virus. On the Mac, it's always this truly basic functionality that I guess isn't needed by people who want it to "just work".)
In any case, mod me offtopic if you will, but maybe this proves that Apple was right not to include an uninstaller. Maybe most people just don't need to uninstall anything, ever, so it's too much work to include yet another feature that may confuse grandma, even if it makes us geeks grind our teeth at the mere thought...
Slashdot Mirror
From now on, I want to be able to filter out any "Top 10" list from some random blogger. Generally, these lists have at least five things that I've already heard about, and five more that I honestly couldn't give a damn about.
It may not actually be an ABI issue. I know that for awhile after the GCC upgrade, Gentoo had patches all over the place just to get standard stuff to compile. So sometimes it's that old code actually doesn't work.
True, that's a missing feature, but the difference is, it applies at compile time, even if it's something stupid like documentation, even if all it changes is a dependency.
That's often it -- for example, Thunderbird will depend on Enigmail if compiled with crypt support, but ultimately, Enigmail is a separate package, and Thunderbird will be built exactly the same way, crypt or not.
What I would prefer, really, is conditional dependencies -- if you install "HTML documentation", then all programs which can have HTML documentation now suggest their html-doc packages. I don't know if this kind of thing exists, though -- sure, you could do it with Portage, but there'd be no way to go back and re-check it later (install package foo, then install html-docs-all, then have it automatically go back and install foo-html-docs).
Maybe so, but I'm not sure I want the same format. USE flags have become huge, way too big to really work well as a single environment variable. They're also so often irrelevant -- does OpenOffice care about Matrox support, for example?
I also don't think it would be as flexible, but maybe it's already overkill.
Actually, they haven't had it in the past.
What they've had in the past is one little leg-up from a deal in which they screwed IBM, and obscene lock-in to maintain that lead when their products were behind their competitors almost all the time, often ridiculously far behind. I have no doubt that they can produce quality products -- just look back at Windows 98 (which is when I switched to Linux), and Windows 2000. It's just that they don't even seem to bother to make their stuff work until competition forces them to, by being enough better that people start to switch away.
We have a name for that -- embrace, extend, extinguish.
If they wanted to compete with a level playing field, they'd have started with ODF -- in fact, they'd have started with an open standard in the first place, rather than creating a sort-of open one because governments start threatening to use their competition.
Notice how they've moved against Linux, though. It isn't by creating a superior product.
It's actually mostly with BS marketing campaigns. From "we have the way out", an anti-Unix website that actually ran on Linux servers, to "We have a bunch of patents that Linux infringes on", to "Open source is communism"...
Actually, I do. The trouble is, it's already breaking the law to do that (DMCA), and generally, enabling this kind of functionality on my Linux trivially gives me the ability to rip them.
The point I'm making is that there are legitimate hassles to being a good little consumer.
Maybe it's easy to get wrong, but I don't think it's hard to get right. Ubuntu does it well, and Gentoo does it decently.
Would these be the same people who bought a Mac?
The drawbacks are no shared libraries, and no one-click to update. You have to trust the app to self-update, and you're hosed if it doesn't. You can't easily add auto-update to an app that doesn't have it already, or check everything for updates without running through every single app and clicking a "check for updates" button. It's also slightly less bandwidth-efficient when there are no updates, or only a few.
I would suggest that this is because Fink is too slow with upgrades, not because there's something wrong with the design. (I do think there's something wrong with the design, though; the GUI is nowhere near simple enough to replace app bundles.)
True, it'd fall flat on its face unless it was installed and working by default, with no registration required -- just like Software Update.
USE flags are overrated, and I say this as a long-time Gentoo user. In fact, it was in discovering this and a few other facts that I decided to go with Ubuntu.
Let's take a few random examples:
matroska -- adds support for mkv files. Ok, you might save some tiny amount of space by disabling this. And then as soon as you download an mkv file, you'll have to recompile half your multimedia apps in order to play it.
nptl -- there's really no reason you'd ever want this disabled on a modern Linux system, unless you really want to go back to a 2.4 kernel. And on OS X, you probably can't use it anyway.
X -- Here's a perfect example of the difference between Gentoo and a good Debian system. On Gentoo, if you disable X, you don't get any X libraries at all. This saves a lot of space and time upgrading, with a slight loss of functionality -- even on a server box, I might want something to work with X forwarding. But it'll probably work pretty well -- until you find that one little program that needs X to compile, even if it's not needed once it's running. Back in the days of XFree, this meant game over -- it meant you now had to compile and install the entire X distribution, including an X server and a bunch of video drivers, for a headless box, even if you were only ever going to use that app in commandline mode.
Nowdays X isn't such a problem, because X.org is split into smaller pieces. But on Ubuntu, it can be chopped up by file, not by source package. This means if something needs a particular X lib, it can get just that one X lib, and nothing else. It also helps with plugin systems -- for example, suppose you don't want vorbis support in, say, xmms or something similar. On Gentoo, this means recompiling xmms to add or remove that support. But xmms uses a plugin system, which means that on Ubuntu, there's a single .so that can be packaged separately -- one package to be removed if you don't want Vorbis, one to be added ba
Not true. Read my comment here. The idea is to extend the style engine to be able to support most of the arbitrary crap, so that actual "SpacingLikeWord95" can be implemented as a style in that particular document, and need not be retained for posterity in every single implementation of ODF (or OOXML) -- but implementations that don't truly understand SpacingLikeWord95 will still be able to present the document properly, or search/index it based on arbitrary properties like that.
You know, in most standards, deprecated stuff is deprecated specifically because it is going to be taken out, so the "depricated" notice is to tell you to stop using them before they are removed permanently.
If that's really what Microsoft is doing, then they are basically doing exactly what I suggested (take them out), just more slowly.
Then why are they in the fucking standard (and in Word 2007) if they're not supposed to be implemented?
Ok, so not only are they not meant to be implemented in an office suite, they're not even supposed to ever show up in a document. So take them out of the standard. No need to have a six thousand page standard filled with crap like that.
Which is exactly why these legacy tags are a mistake, if they were ever intended for anything other than lock-in.
Since, as you say, it's suggested that you NOT implement them, that means old documents, even in the new standard, will only be readable as long as some version of Microsoft Office is still around. So, if MS Office is ever dead and buried, these documents die with them.
Which kills the whole point of having a new standard in the first place, according to you. (Another good reason for standards is to allow interchange between competing products, but that's obviously not Microsoft's intent here.)
They do. It's called namespaces.
They are not included in the standard, of course, for obvious reasons. But they are there, even if I think the problem would be better solved with styles.
You know, I'm not convinced you're trolling, but I'm also not convinced that OOXML serves any useful purpose. The only reason we're even having this conversation is that Office supports OOXML and not ODF. Were it not for that, OOXML wouldn't be given a second thought.
The difference is, HTML is not and never was intended to preserve a document pixel-perfect, the way PDF does. People do not have an unreasonable expectation that bold will look exactly the same on all browsers.
In fact, if you read the spec, you find that it does not expect identical implementations. They do provide an image of what it might look like, but the spec is intentionally vague in order to be flexible.
However, as I understand it, the reason for all this cruft in the OOXML "standard" is so that old documents may be preserved pixel-perfect, in complete implementations -- in other words, in Word 2007, since no one else can produce a complete implementation. And here's the huge difference -- if you look at the language of the HTML spec, it's intended that different browsers might display bold text differently. But if you look at the OOXML spec, it's intended that anyone implementing the SmallCapsLikeWord95 tag (or whatever) should implement it exactly like Word 95.
In other words, the HTML spec is exactly as vague as the standard is intended to be, while the OOXML spec wants you to implement it in a very specific way, but they won't tell you how.
You just answered your own question:
Well, I would actually define a style that is "SmallCapsLikeWord95", but which also defines that the capital letters use a smaller font. It may mean you need a more powerful style engine than ODF currently has -- but by "more powerful", I mean allowing a style to specify a separate font size for caps and lowercase, not having a built-in style that requires every implementation to carry around cruft from Word95.
The result: ODF can have a simpler implementation, while still preserving all the information you want it to -- including being able to search for all your SmallCaps stuff. And maybe now you start using styles properly -- you rename that "SmallCapsLikeWord95" style in the new document to something that reflects what you want small caps to mean.
Mostly because I have not seen any candidates weigh in on technical issues that I care about:
I think I've got everything. The trick is to write a letter that is short enough to actually be read, long enough to explain the above to a layman, and polite enough that it doesn't insult the layman's intelligence -- and then to fire it off to all the candidates I would consider in the first place, and see if I get a real response.
What possible purpose can they serve?
Other than, say, being occasionally used by Word, creating documents which break under other implementations, making it look like a bug in those implementations?
I'd even go so far as to say that where it does happen, it's possible to work around. There are ways, in startup scripts, to force an app to use a specific library, or to force ld.so to search a specific folder for a library.
When using packages, it is possible to gain all of the advantages of an app bundle, by simply having the package install the equivalent of an app bundle. The converse is not true -- app bundles cannot reasonably do dependencies.
Which is why I continue to blame Apple for this mess. Apple is, effectively, the OS X distro maintainer; they combine basic things like Darwin and Quartz with a few apps of their own (Finder, Quicktime, Safari) into something that is supposed to "just work" out of the box. They also provide Software Update, which maintains this distro very well. But they don't provide any way to support third-party apps, or uninstallation (and reverse dependencies) for the apps that they do manage.
If Apple were to, say, pick up Fink -- or Apt, or Portage, or anything -- and develop a nice, slick GUI for it, have Software Update use it, and make it possible to add third-party repositories, then this problem wouldn't exist. Fink and Portage would also not exist in any big way.
True enough. Ubuntu makes this easy. I'm on Kubuntu right now, and while I usually prefer the commandline, I can go to Adept, click "Managed Repositories", go to "Third-Party Software", and manually type in the URL for a repository. I have several already, including a repository which provides Wine for 64-bit Linux, and they seem to work well together with the main ones.
It's true, that's not actually as convenient, but I'm convinced that's a limitation of the UI, not the system.
What's more, having software registered with Apple doesn't seem to be a big deal. Considering the above, it doesn't even have to be Apple. And considering that just about everything Mac is on VersionTracker somewhere, it seems people actually welcome registering their software with a third party if it means they might have more users.
As for being as convenient as a drag-and-drop bundle -- that only works for a local disk. Basically, if you pop in the CD, and the app is well-behaved, then you can simply drag the .app bundle off the CD and into Applications, and you're done. You can even run it off the CD.
But if you're downloading it from the Internet, you have to download some sort of archive, most commonly a dmg. That means you have to download the dmg, mount it, drag and drop, unmount it, and throw it away. Most people don't understand this process at all, and in fact, I often see people simply mounting the dmg and running it from there. Worse, some open source versions come in .dmg.gz, which adds a third step, and a third temporary file you have to delete on your own.
My humble suggestion is, when you pop in an install disc, prompt the user if they want to install. Then, have a standard set of steps, including setting up that vendor's repository for use in updates. Provide a standard place to uninstall packages, by default have it hide anything the user didn't manually install (libraries and reverse dependencies are hidden). You could even prompt the user to remove the repository, but I think it'd be better to simply remove unused repositories automatically, unless the user manually added them.
Installing apps from the Internet could be made similarly easy -- add a new protocol and handler for Safari, something like app://http://example.com/path/to/repo:nameofapp. You then prompt the user if
Workaround: After following that link, go to the Address Bar and hit enter. Since the referral is now coming from the same URL as the image itself, it'll work this time.
I believe the book was "A Mote in God's Eye", where I first saw this concept explored.
It also seemed to be one of the more hard science fiction books -- for instance, though there was faster-than-light travel between systems, travel within a system was still sublight, and without any sort of artificial gravity or "inertial dampening" -- if you want gravity, you accelerate, and there are couches to let you accelerate faster (3g or so), but when you're not moving, everything's weightless.
(Getting even more offtopic, I wonder if Firefly might've worked just as well without artificial gravity. It'd be difficult to do, though.)
On Linux, global configuration settings are files. Usually they are treated specially, and are not cleaned up, but apt, at least, allows you to force a purge there.
What it doesn't clean up automatically (but should be able to) is per-user config settings, usually kept in dotfiles (~/.foo). But either those or the systemwide config files are usually only a few kilobytes.
Assuming that the application bundle was all that was ever installed. Which, if it was, is often wasteful -- it means every application that uses a library not distributed with OS X must include that library in its own application bundle. That means wasted disk space and wasted RAM, but at least all of it is gone when you delete it.
Not likely. The ONLY time I ever see anything changing xorg.conf these days is installing a video driver, so the only time you'd want to change it is when installing a new video card of a different brand. How often does that happen in the lifetime of an OS?
Where this starts to get problematic is stuff that actually does change the system -- for instance, something that adds a preference pane, a menu, a kernel extension, or maybe a framework or a codec for QuickTime to use. These are handled automatically on Linux via package managers, and on Windows via uninstallers (when they exist/work), but rarely on OS X -- I usually have to Google for how to uninstall that particular app.
The difference is between leaving around a few k of config files that don't hurt anyone, and leaving around actual configuration changes that break the system when you remove the software, assuming you even can.
Alright, I'll bite. (I'm going to regret this.)
That's invalid. It implies that long-term memory of random strangers has anything at all to do with reasoning power, or the other way around.
There is a story about Newton: At one point, he hosted a party, had some friends over, left the room to get drinks for everyone... They found him, hours later, in his lab, working, having completely forgotten about the party -- the one he was hosting. No one questions his ability to reason, but certainly, he was a bit forgetful.
Right, I am sorry for confusing you with someone else. I do believe it would have been an appropriate response to the anonymous coward I originally replied to.
Regardless...
That is true. Perhaps you meant it as an attack. I honestly can't see how you couldn't, given the way in which it was delivered.
Let me translate it into five-year-old, to show you the emotional impact it might have: "Hi, you're too stupid to be my friend. Come back when you're smarter."
And, of course, the typical kindergarten-teacher lecture for you: "If you don't have anything nice to say, don't say anything at all."
Of course, we're not five years old anymore, and I won't run away crying from an attack like that. In fact, I can take constructive criticism without feeling threatened by it -- but that was not constructive.
I might have written a response more like this one -- calm, analytical, and more likely to be correct -- but when you opened with an attitude of such superiority that you couldn't be bothered to write a pointed reply, I didn't feel that I had any obligation to do the same.
Kindly demonstrate it, then.
Yes, usually. Sometimes I have to go look it up to be absolutely sure. Now I'm sure, and it was not a strawman.
That is true. But it does make a convenient analogy. Analogies are not automatically strawmen. Quoting Wikipedia:
That is one type of strawman, and probably what you mean here. I believe it doesn't apply. Burden's on you to show that I am oversimplifying. Hint: "Everything should be made as simple as possible, but no simpler."
Interesting. You immediately follow that up with another fallacy, that I'm too lazy to look up the formal name for (well, quasi-official name for an informal fallacy):
It shows nothing of the kind. All it really shows, unless you can read minds, is that I brought it in as an arguing point. Anything beyond that is pure speculation on your part -- maybe it was convenient. Maybe I just wanted to incite this argument. Maybe I was possessed for a moment, or maybe I'm even lower than you think, and I copy-and-pasted the whole post.
But I don't have to speculate: The reason is that I didn't feel like putting a huge amount of time, energy, and thought into writing up solid, concrete points -- not when a single analogy will do.
You'll notice, it's done nicely. No one has yet convinced me that a lack of a standard uninstaller is a
True enough. At least there usually is one.
On OS X, there are only two standard, easy ways for a vendor to provide such a script: Either as part of the original install .pkg (meaning you have to insert the install disc or re-download the installer in order to uninstall), or by dragging the .app to the Trash. Beyond that, and you're entirely on your own, meaning the user probably has to dig through your distribution -- either the folder they downloaded, or somewhere in Applications -- for an uninstaller.
In fact, I believe OS X has a perfectly elegant way to uninstall apps installed with the .pkg (or was it .mpkg? It's been awhile), and some people have pointed this out to me. Unfortunately, Apple doesn't provide any kind of interface for this (not even CLI) -- you have to download some third-party software, some of it free now, in order to get a GUI for it.
That's not sufficient, if you're really going to give it root. All it has to do then is open/write/close a binary or a script, then relax until that binary/script is run -- probably without the "installer" bit set. It can probably figure out how to trigger that automatically, but I'm assuming, for the benefit of the doubt, that you're also following fork/exec like a hawk.
That's actually not what I'm asking, in the anal-retentive "The OS is the kernel" way. I'm just asking for some really decent userland support for this.
Well, a strict interpretation actually allows installer scripts. They just have to be sufficiently sandboxed.
It's not that hard, really. Just have them run as a user with no write privileges except to their own temporary install directory. They can still examine the system and make decisions about where they're going to put things, but ultimately, they can't write directly to the rest of the system.
Which is exactly what Gentoo's Portage does -- except, of course, ebuilds also allow post-installation scripts, because some software effectively requires it, but these are rarely used, at least in the packages I've seen.
However, I think Linux takes a fairly sane middle ground, considering the state of most software today. Software is packaged by a distro maintainer, which means that if there's an installation script, it's going to be done by the distro maintainer, and it's likely to be very small -- much smaller than on a system like Windows (where the simplest things require Registry changes). A very small install script means a very small uninstall script, too. And because the distro maintainers do everything, you can generally trust them to get it right -- there's all sorts of common scripts, like a script to rebuild the initramfs image when a driver is installed or removed.
In practice, the only cruft that ends up being left behind these days is config files, and that's both tiny and optional -- you can, in fact, force apt to remove those for you automatically, too.
Certainly, it won't protect you from someone who deliberately writes a malicious package, but nothing will, anyway. The problem here is one of incompetence. OS X makes it fundamentally hard to do uninstallers well, at least as far as the end-user is concerned. Windows makes it entirely too easy to write uninstallers that don't catch everything, or installers that
Well, he also has a brand-spanking-new MacBook (dual core and everything) that performs about as well as the old eMacs in the office, which are something like 700 mhz. Maybe a little worse, even.
Now, this is not a problem for him, but I do think he could save a little money on hardware if he would get in the habit of actually closing stuff when he's done with it.
No, get rid of the spyware and it'll be about the same with any modern OS.
Here, I'm a little skeptical. See, I have 10 icons in my KDE taskbar, and most of them do nothing but eat RAM. You could claim that slows the system down incredibly, but not only do I have 2 gigs of RAM, I have an OS that knows how to swap well.
Then again, Windows memory management tends to suck, so maybe it is faster with those removed. But then, I never installed much on my Windows system to begin with.
Well, once you install virtual desktops. And with Beryl, I've got most of the OS X features I was missing.
Agreed. But recall, I was replying to someone who was either a troll or a moron. The original quote was:
I'm sorry, but the only way you completely transcend implementation details is by buying a new computer when you have a problem, and hiring someone else to move your data over. That would tend to get expensive...
But then, I guess Mac users have money. That's why they bought a Mac.
True enough, but consider the difference between running X on Linux and running some svgalib app.
QuartzExtreme is certainly going to be heavy. I'm sure they can strip it down enough to be fast on the iPhone, but remember -- it's not enough to run on a computer from 1996. For the iPhone to work, it has to also feel like a computer from 2008.
Wrong. It's that I expect things like an uninstaller, virtual memory, dynamic memory allocation, and so on, to either be part of the OS, or to be free pieces of software.
There's tons of freeware for Windows, and just about all of the software on Linux is free. But on the Mac, every little thing that I usually get -- legally -- for free, is some little $10 or $20 piece of crap.
For a geek to confuse "install" with "uninstall" is a bit bizarre...
Anyway, that won't necessarily remove everything it installed, and it certainly won't tell you whether it'll break something else. That's what a package manager is for.
From what I understand, the iPhone will mostly be running widget-type apps -- essentially AJAX apps on top of Safari.
I could be entirely wrong, though. But I still strongly doubt it'll be anything as heavy as Quartz.
Maybe when you get past your hurt ego, you'll be willing to explain to me why a lack of memory segmentation is an OS issue, but a lack of a standard uninstaller is a developer issue. (Yes, standard. You mention two ways to uninstall, one of which is non-obvious and inconvenient as hell for the user.)
Yes, I can see that. It's not healthy.
Just a simple example: I share my Internet with a couple of Mac users. One actually seems to be afraid of me and all human contact -- it's a disorder, and it's very sad, but it means he's not a problem.
The other is just smart enough to know to bother me when his Internet is slow, because I might have a huge torrent open.
And just stupid enough to run something like 20-30 apps at once, with 50 or 100 windows, at least. I'm not kidding.
So, because he doesn't care or worry about implementation details, roughly half the time he bugs me about the Internet, I can actually throttle my torrent so his browsing is good. And the other half the time, I have to tell him to for God's sake close some programs, maybe reboot!
Perhaps the saddest case here was when he had some music playing, and could not, for the life of him, figure out what program was playing it. Eventually, he had to use the old Windows solution-to-everything: reboot.
You know, I'm a programmer, I run Linux, and I typically have maybe four or five programs open, maybe two of which are capable of playing music, none of which are capable of doing it without my consent.
Oh, bullshit, on both counts.
The Mac programming culture is such that things generally play along with the user, until they don't. When they don't, there's nothing you can do about it, unless you are a Mac/Unix guru, in which case there's very little you can do about it.
And what's "fucking anal-retentive" is that this is exactly the sort of reaction I see from Mac users every time we suggest that there might be some slight flaw in their holy OS. (Never mind that some of the best new features in Leopard are things we already have in Linux and Solaris...)
Oh, true, it's not everyone, but so far, I can count one person who replied to me in this discussion with helpful information and without actually attacking me. A second person provided somewhat helpful information while attacking me, which is normal for the Linux community. I also have one or two replies agreeing with me, and even an anti-Mac troll. And two Mac trolls.
So, of those who actually appear to be Mac users, that's at least 25-50% trolls who replied to my post. People who have nothing better to do than post Anonymous Coward on Slashdot, attacking anyone who disses the Mac. I call that anal-retentive.
Wow, way to miss the point AND look like a retard. No wonder you posted Anonymous, you coward.
No, I'm talking about the fullscreen extension. Since the Mac wasn't designed for one-track minds, you should have no problem figuring out what two words put together means. A compound word! *gasp*
Yes, I'm talking about FULL SCREEN. Not "maximized". Not "zoomed". Full fucking screen. Why is this difficult for you, oh Multi-Track-Mind?
And there is an extension which allows windows in OS X to be forced fullscreen and back, whether they have that capability natively or not. Obviously some apps already do this -- video players, of course. Obviously, others do not -- terminals, for example.
You're talking to someone who works on a 1600x1200 Linux machine, with four virtual desktops -- oh, I'm sorry, "spaces", that feature you're drooling over in Leopard, which probably won't be out yet for another year...
One of those virtual desktops typically has six terminal windows, three IM windows, and sometimes a browser open, not overlapping. Or four terminals, IM, browser, and an MMO, with my email on another desktop, and maybe a PDF or a package manager on a third... Yes, I know how to deal with multiple windows.
So one day, I decided to look for a way to make a window go fullscreen. Because, you know, unlike Linux or Windows, it's not enough for OS X to waste one side of the screen for its menu bar. It has to then waste another side of it for the Dock -- something you all orgasm over because it's so cool and new and different and... oh wait, it's been done in WindowMaker on Linux for years, and it wasn't even invented there.
And as it turned out, this extension was buggy and not as useful as I thought. I could even say you were right here -- I wanted to go back to piles of windows, instead of just the one fullscreen.
Only, there was no fucking uninstall. I had to do it manually -- a difficult process to even find a good walkthrough, and still quite a bit of messing in the commandline to get it done. And I'm comfortable with a Unix commandline -- if I say it's difficult, trust me, it is.
Yeah, I guess an artist would just love opening up a terminal and typing twenty cryptic commands just to get the same usable interface back.
Oh wait -- maybe it's because Apple assumes that such creative people would never want to install software. Because, you know, actually using your computer is such a square thing. You'd rather sit around in good taste and masturbate to your bouncy icons and your rounded corners.
Explain to me how it hurts you (other than your pathetic ego) that I have a Powerbook. Never mind that it won't work anymore, and Apple refuses to fix it -- I have one, and I probably know more about how to use and abuse it than you ever will.
But then, I guess I never will, since I'm not a fucking artist. Oh wait -- joke's on you, asshole. I'm a programmer. And I guess if the Mac isn't right for me, then you won't be getting any software from me.
And I don't know about you, but I use a computer to run software, not to stare at an OS and troll about how good my farts smell.
You sound like the type who, back before OS X, when a single app could bring down the whole system because there was no memory segmentation, would say "Good job of blaming the OS for developer problems." While meanwhile I'd be sitting over on Windows or Linux or even Solaris, watching the same "developer problems" simply result in a segfault or illegal operation, crashing that one app.
Easy to use doesn't mean standard. On Windows or Linux, I can open up a central list of installed packages and uninstall from there. Apple's encouraging the old Windows way of doing this, which is to have a separate uninstall program -- hopefully somewhere near where the app is installed -- that's developed along with the app, or licensed from a third party (InstallShield)...
You know, maybe you should think about why the pkg format exists in the first place. Why have a standard format?
Well, it's simple: When I get any OS X app, in any form, unless it's some crazy custom script, I know that to install it, I either doubleclick on the .pkg, or open the .dmg/.zip/whatever and drag the .app to Applications.
But when I uninstall, if I can uninstall at all, I have to think about where I put the .pkg (if there is one), or hunt around for an uninstaller, or drag the .app to Trash and go hunting around for whatever crap it left behind.
Compare that to Linux, or even Windows -- add/remove programs, click "uninstall". Done.
Given that no OS I know of actually enforces one option over the other, I'd say you're talking out your ass.
I'd much rather have the choice of an OS-maintained, or at least common, database of installed apps and how to uninstall them -- without having to keep the original pkg around (how retarded is it that you have to pop in the original install disc in order to uninstall? Maybe the whole REASON you want to uninstall is that you lost the disc needed to run the app?)
One thing that really bothered me on OS X was its complete and total lack of an uninstall feature. This was especially annoying, as I'd hoped that the "drag to trash" was really a fancy GUI for some sort of real package manager.
I mean, sure, if your app is entirely self-contained, you can just drag it from Applications to Trash and be done with it -- at least that's no worse than Linux, where per-user preferences are left alone, but nobody really cares, since it's only a few K of disk space and doesn't affect anything else.
But what do you do about the random app that installs kernel extensions, browser extensions, and generally insinuates itself among all your stuff? You know, the cool stuff like Insomnia, the SMS-to-HID driver, or the force-any-window-to-fullscreen extension? Or even multi-desktops, or something as simple as a VPN?
Often, the uninstall instructions for these are at least as complicated and unnecessary as anything you hear people complaining about for installing software on Linux.
Oh wait, I forgot -- there's a proud Mac tradition of making you pay $20, $50, or $100 for random bits of third-party software to implement stuff that should have been in the OS to begin with. In the past, it was things like dynamic RAM allocation and swap space, and now, it's an uninstaller.
(You could complain that Windows is the same way, needing third-party stuff like anti-virus, but most of what you need on Windows is either bundled with the OS or available for free, often open source. And you don't really need anti-virus. On the Mac, it's always this truly basic functionality that I guess isn't needed by people who want it to "just work".)
In any case, mod me offtopic if you will, but maybe this proves that Apple was right not to include an uninstaller. Maybe most people just don't need to uninstall anything, ever, so it's too much work to include yet another feature that may confuse grandma, even if it makes us geeks grind our teeth at the mere thought...