"On Windows they call it Administrator, on Linux they call it Root. It's the same thing, the user account that has no restrictions on it. Every user wants to run that way, because seeing a "permission denied" message on their own box just isn't going to make them consider the system user-friendly."
Except it's not quite the same. On Linux, graphical apps, at least the ones that are part of the distro's admin tools, prompt for the root password if they are started by a regular user. Windows XP, as far as I've been able to tell, doesn't do this. Ordinary *nix apps are designed to run with user-level privileges, and this has been so from the beginning. Many Windows apps, however, are written with a permissive environment like Windows 95/98 in mind, so apps do things that only work if the "Program Files" directory is writable. Most Linux distros have a regular user account created as part of the installation. Any additional users created as part of a Windows XP installation have Administrator privileges by default.
On a typical Linux box, running as a regular user is usually the path of least resistance. The opposite is true for Windows XP.
"I generally respect RMS, but I have a problem with this. Like it or not Sun (and others via the JCP) set the Standard for Java. I fail to see how using the Standard is falling into a trap.
The real reason Java would be unusable in Stallman's "Free World" is because the current, free compiler is sub-standard."
And the current free compiler is substandard because Sun sets both the standard and creates the reference implementation. By the time the GJC guys have seen the latest updates to the standard, Sun has already implemented them in its own reference implementation. Inevitably, that means the GJC developers will *always* be chasing taillights.
Why don't IBM and Blackdown have this problem? Because they use Sun's code as a starting point.
So long as the status quo remains, it will be impossible for there to be multiple independant complete implementations of the current Java standard.
"The XFree86 client libs are not affected by the license change, so if there's a GPL compatibility problem with XFree86 right now, what is it? Let's have it."
If you don't care about upgrade paths, I suppose there is no problem, since the problem with using XFree86 4.4.0 right now is that the upgrade path is legally uncertain. David Dawes has been non-committal about whether the XFree client libs will be under the new GPL-incompatible license in the future. Given that the XFree client libs are under the old license at all is a grudging concession on his part, there is at least a medium-size risk that he will outright make the whole of XFree86 GPL-incompatible, so that a Linux distributor can no longer distribute GPL'd apps linked to the client libs of a future version of XFree86, say, version 4.4.2.
"As could the Xorg developers. What's your point?"
While the Xorg developers could theoretically put their X implementation under a GPL-incompatible license, it would take a sea change for that to happen. Not only have they made the effort to provide a viable GPL-compatible alternative to XFree86, but it would be against the interests of several of the Xorg members to change the license to something GPL-incompatible.
On the other hand, David Dawes has been non-committal about keeping the XFree86 libs under the old license. He might very well put out a XFree86 4.4.1 that was completely GPL-incompatible.
Will those distros continue to go with XFree86 now that the X.Org Foundation is not just talking about it but is also actually delivering a forward moving, credible alternative?
And what is this alternative? A rebranded XFree86 4.3.0.1 with the various updates that could be easily found online?
Nope. The alternative is a cleaned-up fork of XFree86 4.4RC2, binary-compatible with XFree86 4.4.0.
X.org, on the other hand, has only so far made some noise about not wanting to be forced to give XFree86 some well-deserved credit
It's not the giving of credit that's the issue; it's the matter of GPL compatibility. Cute strawman.
applied some debatable updates to the code (using an unstable freetype2 is probably not wise)
Freetype 2.1.7 is the latest stable release of Freetype2. Not everyone uses the Linux version number scheme where an odd-numbered minor version number indicates a development version rather than a stable version.
"I was wondering what people think about David Dawes' statement to the effect that the big Linux Vendors were already planning to jump to X.org, because the collection of vendors can push it in directions that make the companies happier."
Dawes' info is outdated. X.org is not the vendor-only consortium that it used to be.
David Dawes has played a bit coy, however, on whether the new license will eventually get applied to the XFree libraries. He could pull the rug out from under us later.
It's called a distraction. Instead of the Bush administration pointing up at the sky and blurting "Ooh, look, birdies!" when the press start grilling it on how bad it's doing on the economy, Iraq, and terrorism, it makes noise about Evil Pornographers(TM) instead.
I've tried SUSE with GNOME. Not impressed. For example, while Red Hat's up2date applet works in both GNOME and KDE, SUSE's equivalent of the same app (SuSEWatcher) does not. I vaguely remember other stuff being broken as well.
"Does the belief that gambling is a vice have to be predicated on religion in everyone's mind? It clearly has roots there, but not everyone who opposes its legalization is religious."
I'm not so sure the belief that gambling is a vice even has its *roots* in religion. In the U.S. at least, it is a belief propagated by Christian culture but is not a part of Christianity proper; there is certainly no prohibition against it in Scripture itself. Christian culture seems to have picked up the belief from somewhere else.
If it is corrupted, your whole OS won't even boot.
While I somewhat agree on this point, I have to note that corrupted config files will also prevent Linux from booting.
The difference is that the files that will keep Linux from booting if corrupted are mostly static. Rarely, for example, is/etc/inittab edited. So, the likelihood that these files will suddenly be corrupted is fairly low.
The Registry is anything but static. Apps write to it all the time. That increases the likelihood that one wrong write will mess up the whole thing.
There do seem to be some improvements listed. Foremost appears to be the ability to view a scaled version of the desktops in full screen instead of just the little icons in the pager.
"Sun needs its tight control over Java in order to, well, tightly control it. Remember what happened when Microsoft tried to "embrace and extend" Java with Windows extentions, Sun was able to kick Microsoft completely out of the Java business."
Sun's leverage was not its control over the source to the JVM, but that the Java standard was well enough defined that it could be established that MS's extensions were out of compliance with the standard, and thus MS could not legally call their J++ VM "Java."
"Open Source would allow Microsoft to create WinJava so long as they released the source, which might not be that hard of a thing to do. I don't think Sun wants to go there..."
Why not, especially if Sun were allowed to reincorporate MS's extensions into the "canonical" JVM? "Embrace, extend, and extinguish" is only a good strategy if one can own the extensions. A properly drafted copyleft license would have made Java open enough to be a commodity while discouraging incompatible proprietary extensions.
"I do see Bruce talking about how he would like a 'cottage industry' to write apps for UserLinux.
But I do not see anywhere where he says that QT could not support this."
However, Perens *does* say that making KDE *the* GUI SDK of UL would raise the barrier to entry into that "cottage industry," and he's right; the cottage industry industry will be limited to those able and willing to afford Qt. That would shut out the small software shops.
The difference between one and two GUIs may spell profitability or bankruptcy for
some of our service providers. [emphasis mine]
It's not whether Perens LLC can support KDE, it's whether the smallest of the service providers can support KDE.
From you again:
And then you have all of the KDE developers on the list who were *more* than willing to provide all the effort required.
Effort required to to what? The KDE developers can choose to act as a de facto service provider of a KDE-based version of UL. That has no bearing on the fact that it costs more to support both KDE and GNOME than just GNOME alone.
"And no where has Bruce said that all UL service providers would be required to support the entire UL base system in toto."
Oh, no, he's just implied it very strongly. From
Bruce Perens:
"We should consider _reducing_the_support_burden_ to be a very important goal.
It makes it much easier for either customer internal staff or our support
providers to support the system
if they have some limit on the gamut of
products they must support, and reduces the support cost to the
customer. Knowing two complete GUIs is expensive, so expensive that I think
it could make a difference between viability and nonviability for support
providers - especially small ones. If our support providers aren't
viable, neither is the project." [emphasis mine]
Now back to what you said:
If service providers are smaller, less experienced, etc., than Perens LLC, they can choose to support a subset of the UL base.
That's very unhelpful for the users of UserLinux. Imagine looking for UL service providers and not being sure if the subset that they support is the same subset for which you need support, especially since it makes a service provider look bad if it says outright that it only supports less than the whole of UL. If UL-branded service providers are required to support the whole of UL, then you at least have a fair idea of what to expect from a provider, and service providers who can support a superset of UL will likely broadcast that fact, as it will look good as a selling point.
"As Perens LLC pretty much *is* the UL project at this point, I'd say it is a significant change."
You don't get it, do you? Perens LLC is *one* UL service provider, and it is not supposed to remain the only one. Perens LLC has the resources to support KDE, and a customer incentive to do so. There is no guarantee that another service provider can say the same.
"we also have to look at the fact that UserLinux seems to almost be like a distribution that's *intended* to be repackaged / redistributed by other companies for their own markets."
Hardly any "almost" about it. UserLinux is supposed to be repackaged / redistributed by other companies. The whole point of UserLinux is that it is supported by a web of companies.
"Is a blown excuse because... come one did you even look at the article? Bruce's company *is* going to be supporting KDE on UL so that kinda deflates the whole, "too hard to support both..." argument... don't you think?"
Nope. It's one thing to for Bruce Perens to say that Perens LLC will support UserLinux+KDE. He knows his own resources and what he can handle. It is another thing altogether to declare that *all* UserLinux service providers will be able to support both GNOME and KDE. Some service providers may simply be smaller, less experienced, etc., than Perens LLC.
"So if Windows XP was just an OS nothing else, you would need to download/buy a browser, file decompresser, media player, text editor, calculator, personal firewall, back-up utility, the list goes on."
Except that an OEM could handle the preinstallation of those sorts of things, and when it comes to providing an app to "write papers," that is often what OEMs do. Think about it? Is MS Word--used for writing papers--bundled with Windows XP? Obviously not. Do computers from Dell, Compaq, etc. often come with Word preinstalled? Certainly. Just because it is convenient to have certain pieces of software ready to go on the computer does not mean that those pieces of software have to be part of WinXP.
"But XF86Config can be configured by all sorts of GUI utilities."
However, those GUI utilities are only so good at parsing the XF86Config file, especially in the corner cases. If it were in XML, then the designers of tools wouldn't have to create their own parsing routines, which are often fragile, but instead simply use a more reliable off-the-shelf parser.
Slashdot Mirror
Maybe those dwarves should do a stage show where they dance around an 18" tall model of Stonehenge. ;)
"I will say that you should not have to read to use a file dialog box in a GUI."
Well, you don't have to read to use GNOME's Open File dialog, just use mouse clicks. Ctrl+L is for experts.
"On Windows they call it Administrator, on Linux they call it Root. It's the same thing, the user account that has no restrictions on it. Every user wants to run that way, because seeing a "permission denied" message on their own box just isn't going to make them consider the system user-friendly."
Except it's not quite the same. On Linux, graphical apps, at least the ones that are part of the distro's admin tools, prompt for the root password if they are started by a regular user. Windows XP, as far as I've been able to tell, doesn't do this. Ordinary *nix apps are designed to run with user-level privileges, and this has been so from the beginning. Many Windows apps, however, are written with a permissive environment like Windows 95/98 in mind, so apps do things that only work if the "Program Files" directory is writable. Most Linux distros have a regular user account created as part of the installation. Any additional users created as part of a Windows XP installation have Administrator privileges by default.
On a typical Linux box, running as a regular user is usually the path of least resistance. The opposite is true for Windows XP.
"I generally respect RMS, but I have a problem with this. Like it or not Sun (and others via the JCP) set the Standard for Java. I fail to see how using the Standard is falling into a trap.
The real reason Java would be unusable in Stallman's "Free World" is because the current, free compiler is sub-standard."
And the current free compiler is substandard because Sun sets both the standard and creates the reference implementation. By the time the GJC guys have seen the latest updates to the standard, Sun has already implemented them in its own reference implementation. Inevitably, that means the GJC developers will *always* be chasing taillights.
Why don't IBM and Blackdown have this problem? Because they use Sun's code as a starting point.
So long as the status quo remains, it will be impossible for there to be multiple independant complete implementations of the current Java standard.
"If Sun (under MS's influence) tries to corrupt or hamstring Java, IBM, Blackdown et al will simply fork it, and everybody will start using theirs."
And how are IBM and Blackdown going to have the legal authority to fork the code?
"The XFree86 client libs are not affected by the license change, so if there's a GPL compatibility problem with XFree86 right now, what is it? Let's have it."
If you don't care about upgrade paths, I suppose there is no problem, since the problem with using XFree86 4.4.0 right now is that the upgrade path is legally uncertain. David Dawes has been non-committal about whether the XFree client libs will be under the new GPL-incompatible license in the future. Given that the XFree client libs are under the old license at all is a grudging concession on his part, there is at least a medium-size risk that he will outright make the whole of XFree86 GPL-incompatible, so that a Linux distributor can no longer distribute GPL'd apps linked to the client libs of a future version of XFree86, say, version 4.4.2.
"As could the Xorg developers. What's your point?"
While the Xorg developers could theoretically put their X implementation under a GPL-incompatible license, it would take a sea change for that to happen. Not only have they made the effort to provide a viable GPL-compatible alternative to XFree86, but it would be against the interests of several of the Xorg members to change the license to something GPL-incompatible.
On the other hand, David Dawes has been non-committal about keeping the XFree86 libs under the old license. He might very well put out a XFree86 4.4.1 that was completely GPL-incompatible.
*That's* the point.
Nope. The alternative is a cleaned-up fork of XFree86 4.4RC2, binary-compatible with XFree86 4.4.0.
It's not the giving of credit that's the issue; it's the matter of GPL compatibility. Cute strawman.
Freetype 2.1.7 is the latest stable release of Freetype2. Not everyone uses the Linux version number scheme where an odd-numbered minor version number indicates a development version rather than a stable version.
"I was wondering what people think about David Dawes' statement to the effect that the big Linux Vendors were already planning to jump to X.org, because the collection of vendors can push it in directions that make the companies happier."
Dawes' info is outdated. X.org is not the vendor-only consortium that it used to be.
David Dawes has played a bit coy, however, on whether the new license will eventually get applied to the XFree libraries. He could pull the rug out from under us later.
It's called a distraction. Instead of the Bush administration pointing up at the sky and blurting "Ooh, look, birdies!" when the press start grilling it on how bad it's doing on the economy, Iraq, and terrorism, it makes noise about Evil Pornographers(TM) instead.
I've tried SUSE with GNOME. Not impressed. For example, while Red Hat's up2date applet works in both GNOME and KDE, SUSE's equivalent of the same app (SuSEWatcher) does not. I vaguely remember other stuff being broken as well.
"Does the belief that gambling is a vice have to be predicated on religion in everyone's mind? It clearly has roots there, but not everyone who opposes its legalization is religious."
I'm not so sure the belief that gambling is a vice even has its *roots* in religion. In the U.S. at least, it is a belief propagated by Christian culture but is not a part of Christianity proper; there is certainly no prohibition against it in Scripture itself. Christian culture seems to have picked up the belief from somewhere else.
The difference is that the files that will keep Linux from booting if corrupted are mostly static. Rarely, for example, is /etc/inittab edited. So, the likelihood that these files will suddenly be corrupted is fairly low.
The Registry is anything but static. Apps write to it all the time. That increases the likelihood that one wrong write will mess up the whole thing.
The Enlightenment window manager does that already. Look at the lower left corner of of this screenshot.
"Sun needs its tight control over Java in order to, well, tightly control it. Remember what happened when Microsoft tried to "embrace and extend" Java with Windows extentions, Sun was able to kick Microsoft completely out of the Java business."
Sun's leverage was not its control over the source to the JVM, but that the Java standard was well enough defined that it could be established that MS's extensions were out of compliance with the standard, and thus MS could not legally call their J++ VM "Java."
"Open Source would allow Microsoft to create WinJava so long as they released the source, which might not be that hard of a thing to do. I don't think Sun wants to go there..."
Why not, especially if Sun were allowed to reincorporate MS's extensions into the "canonical" JVM? "Embrace, extend, and extinguish" is only a good strategy if one can own the extensions. A properly drafted copyleft license would have made Java open enough to be a commodity while discouraging incompatible proprietary extensions.
"Never, never, never, put an option only in a contex menu. It is very bad design."
The "Rename" feature is also available from the "Edit" menu in the Nautilus menubar.
"I do see Bruce talking about how he would like a 'cottage industry' to write apps for UserLinux.
But I do not see anywhere where he says that QT could not support this."
However, Perens *does* say that making KDE *the* GUI SDK of UL would raise the barrier to entry into that "cottage industry," and he's right; the cottage industry industry will be limited to those able and willing to afford Qt. That would shut out the small software shops.
Wrong. From On the GUI Selection in UserLinux:
It's not whether Perens LLC can support KDE, it's whether the smallest of the service providers can support KDE.
From you again:
Effort required to to what? The KDE developers can choose to act as a de facto service provider of a KDE-based version of UL. That has no bearing on the fact that it costs more to support both KDE and GNOME than just GNOME alone.
Oh, no, he's just implied it very strongly. From Bruce Perens:
Now back to what you said:
That's very unhelpful for the users of UserLinux. Imagine looking for UL service providers and not being sure if the subset that they support is the same subset for which you need support, especially since it makes a service provider look bad if it says outright that it only supports less than the whole of UL. If UL-branded service providers are required to support the whole of UL, then you at least have a fair idea of what to expect from a provider, and service providers who can support a superset of UL will likely broadcast that fact, as it will look good as a selling point.
"As Perens LLC pretty much *is* the UL project at this point, I'd say it is a significant change."
You don't get it, do you? Perens LLC is *one* UL service provider, and it is not supposed to remain the only one. Perens LLC has the resources to support KDE, and a customer incentive to do so. There is no guarantee that another service provider can say the same.
"we also have to look at the fact that UserLinux seems to almost be like a distribution that's *intended* to be repackaged / redistributed by other companies for their own markets."
Hardly any "almost" about it. UserLinux is supposed to be repackaged / redistributed by other companies. The whole point of UserLinux is that it is supported by a web of companies.
"Is a blown excuse because... come one did you even look at the article? Bruce's company *is* going to be supporting KDE on UL so that kinda deflates the whole, "too hard to support both..." argument... don't you think?"
Nope. It's one thing to for Bruce Perens to say that Perens LLC will support UserLinux+KDE. He knows his own resources and what he can handle. It is another thing altogether to declare that *all* UserLinux service providers will be able to support both GNOME and KDE. Some service providers may simply be smaller, less experienced, etc., than Perens LLC.
"So if Windows XP was just an OS nothing else, you would need to download/buy a browser, file decompresser, media player, text editor, calculator, personal firewall, back-up utility, the list goes on."
Except that an OEM could handle the preinstallation of those sorts of things, and when it comes to providing an app to "write papers," that is often what OEMs do. Think about it? Is MS Word--used for writing papers--bundled with Windows XP? Obviously not. Do computers from Dell, Compaq, etc. often come with Word preinstalled? Certainly. Just because it is convenient to have certain pieces of software ready to go on the computer does not mean that those pieces of software have to be part of WinXP.
"But XF86Config can be configured by all sorts of GUI utilities."
However, those GUI utilities are only so good at parsing the XF86Config file, especially in the corner cases. If it were in XML, then the designers of tools wouldn't have to create their own parsing routines, which are often fragile, but instead simply use a more reliable off-the-shelf parser.