Say there are 1000 homicides. According to you, 2/3 result in arrests. That would be 667. Again, according to you, 2/3 of those result in a conviction. That would be 445 convictions.
That would be considerably higher than the conviction rate for software piracy (-;
The rest of your post is snipped, because it completely fails to address the main point-- that homicide is prosecuted much more aggressively than
the vast majority of other crimes.
Sorry to sound like a typical slashdot troll, but does this come with Linux preloaded? I'm shopping for a laptop, and I *really* don't want to pay the Microsoft Operating System Tax(tm) for an OS I'm not going to use. Any recommendations on laptops with preloaded linux and places to buy them that *WON'T* charge me for Windows?
I get my computers from
ASL, and so do
my employers, so I've dealt with a number
of their machines. They do Linux laptops, and will
not charge you for Windows on a Linux-only system.
Kill some poor dude and the police might look for you, might send you to jail for a few years. And then again, might not.
About 2/3 of homicides result in an arrest, and about 2/3 of them result in succesful prosecution. The succesfully prosecuted cases nearly always result in a life prison sentence or the death penalty.
So, there's your answer: don't put the cart before the horse. Don't expect that someone will tell you that you need to split a function when it gets beyond X number of lines. Rather, look at the integrity of the system's modules. If I can leave you with one piece of advice, I hope it is this: design module interfaces not according to what services they provide, but what information they hide.
Actually, the questions he is asking are indeed very important. It's all well to say that code "should be well designed", and indeed, most books spend a lot of time talking about design principles for people with clean slates. Unfortunately, very few people have a clean slate to work with. Using a good design up front is not an option if you're not the one who did the upfront design.
We are either stuck with maintaning
poorly designed code, or even code that was designed well up-front, but needs a change in design to meet changing requirements. What a book like refactoring brings to the table is the process of incremental redesign. Redesigning code without rewriting it is a fine art, and refactoring basically explains how to do it.
If record companies did not make a profit selling tapes, they would either raise the price of tapes or stop selling them. Duh!
It's not that simple. Do you understand the difference between total costs and marginal costs ? Let me explain in more detail:
Suppose that selling CDs have the following costs:
Recording the music
Promoting the band
Administrative overhead associated with distribution
Artwork and packaging
Pressing CDs and purchasing blank distribution media
The costs of selling tapes are:
Recording the music
Promoting the band
Administrative overhead associated with distribution
Artwork and packaging
Copying the tapes and acquiring blank distribution media
Notice that the overlap here is considerable--
in particular, by the time you pay the costs for selling CDs, you've paid nearly all the costs for tapes..
So, supposing that you have a profitable CD business up and running. Then to add a supplementary tape business, you don't need to pay the total costs of the tape operation. You only need to pay for the marginal costs (in other words, you don't need to pay to record the music opr promote the band, because you did that when you set up the CD operation).
So it's entirely plausible that the expected revenue from selling tapes exceeds the marginal costs of adding a tape operation to a CD operation (which is what the record companies pay), but doe NOT exceed the total cost of running the tape operation.
If the price of the media is unimportant, why are CDs MORE expensive than tapes?
The assumption that the price of the media determines the selling price is false. Tapes are cheap because no-one would buy them if they were more expensive (because they offer less utility to the buyer)
Of course, they got greedy, and never lowered the price.
You've done no estimates of prices vs inflation, so you're not in any position to even make that claim. My guess is that prices are approximately flat, and the reason is that the bulk of the costs
are directly correlated with the price of living.
I can get CDs for ~$5.00. And you know what? The record clubs MAKE MONEY selling them at that price!
You're a smart buyer -- good for you. The fact that you can get them cheaply through this venue shows that the high prices are not a result of the record companies greed, but rather, that of an inefficient distribution model. By spending your money on someone with a low overhead distribution model than traditional retail outlets, you get a better deal.
Yes, I understand that record shop employees need to eat, but that doesn't mean that this should be happening. If the record only costs a couple thousand to make, then it can be sold overall at a lower price in order to recoup the expenses.
There could be a lot of reasons why you don't get a price reduction. For example, a more uniform pricing scheme entails less administration costs. I'm not proposing this as a reason, but simply pointing out that it's not at all obvious that retailers
will pass savings on to customers product for product. For example, if large record companies that produce large lines of low cost
recordings, they are cheaper on the shelves (for example, some record labels sell jazz recordings at about $10 or so). In the case where savings on an isolated recording aren't passed on, I'd put it down to laziness on the part of the record store.
Wilco's new "Yankee Hotel Foxtrot" album was recorded for some incredibly cheap sum, like a few thousand dollars. Yet it's sitting there with the same price tag at Best Buy as the huge manufactured pop albums.
There are other costs. For example, the employees at the record shop need to eat. In any case, this example is a long way from "proof" that record companies are colluding to keep prices high. Your other example just shows that the record shops are getting greedy. There could be some ominous agreement between other record companies and the record stores to keep prices of competing albums high, but one needs to make an argument to that effect.
No it isn't.
All that tells you is that selling tapes is not a viable business in its own right (meaning, if a record company stopped selling CDs and only sold tapes, they would not last very long). The reason that record companies can keep a relatively unprofitable tape selling business alive is that there is a substantial overlap in the costs of producing the tape and the costs of producing the CD.
AS well as the cd "single" that costs a hell of a lot less then the cd, and still has the same massive hype and advertising attached.
Again, you've already spent the money on the hype and marketting before you produce the single. The marginal cost of releasing it is relatively low. You don't have to pay those marketting costs more than once, you know.
Yes it costs a lot to make the stuff that goes onto a CD, but has that gone UP?
All prices go up, the price of paying salaries also goes up. It's called "inflation". The ignorant slashdot whiners have done a lot of whining, but posted no hard evidence that there is a rising trend in the cost of CDs relative to the cost of living.
Actually, no. All I've done is point out the publicly stated intentions of UL, then expounded on why they are not good for the community.
The only concrete issue you've pointed to that has
some legitimacy is their choice of RPM format.
My counter arguments are:
Binary compatibility issues, relating to choice of library version, choice of C++ compiler, , sonames (or rather, so-renaming), and package location pose a greater problem than RPM format.
You did present a counter argument of sorts to this (though I don't buy it)
Going outside the package management system means
you're not "distribution neutral", because you're
not taking advantage of the distributions dependency tracking capabilities. (I understand that you disagree with this, but that is my argument)
It is irrelevant that this extended standard is based upon open standards if it is being modified and imposed back upon the community in a non-open fashion as has been described here. If this were Microsoft everyone would be shouting "embrace and extend," for indeed that is exactly what is proposed here
I agree that this is an instance of "embrace and
extent" (sans destroy). I think there is an important distinction between this and simply attempting to subvert the standard by using a competing one -- to me, it's not irrelevant at all, because LSB compliant distributions will
be binary compatible with United.
The difference is, I don't really have a problem with that. This is the way standards evolve. Design by a committee doesn't work very well, and you need someone to blaze a trail and experimenting before committing something to a standard. For example, gcc has "embraced and extended" both C and C++, and the
extensions have for the most part had good consequences. So you could use the words "embrace and extend", but I'd contest a claim that this is necessarily a bad thing. Hence my comments about "dark mumblings" (sorry if that sounded harsh)
It is my opinion that any non-open approach to defining standards is a very negative thing for the community. The process is as important as the result, and the open, collaborative process here is being abandoned and supplanted by a coercive, closed process that is designed to benefit one or two entities, under the guise of serving the community.
Again, I disagree. The claim I'd contest is that
this is being sold as a replacement for LSB and
other standards. Standards codify existing practice, committees aren't very good at designing and innovating, but they are good for formalising and clarifying details about how things should be done. If United Linux was attempting to replace LSB, I'd be against it, but at this stage, I don't see evidence that supports such a claim.
That's their perogative. The funny thing is that'll blow up in their face if they ever try to legitimize digital downloads.
I'm not sure what you mean. They certainly run a risk of creating PR problems for themselves. I suppose they're counting on most people not caring too much about it, and taking a calculated risk.
I think it's a fair bet that pandering to the people who are
up in arms about their "right" to freeload isn't
a good business strategy. However, they need to
be careful that they don't give the impression that they're blowing off paying customers at the same time as they blow off the freeloaders.
I don't think it would destroy future digital download services though. The primary weakness in illegal file trading is that it depends on anonymity. If you remove the anonymity constraint, the picture changes substantially.
Actually I did read the article. My comment stands. It was a way of saying "if they take arms in enforcing copyrights, they may find those same arms used against them."
I don't see how you can "use the same arms against them", because they are not attempting to download copyrighted content from your computer (-; What they are doing is NOT really a "DoS" attack, but rather, exploiting the fact that the
system relies on anonymity.
Basically, the one thing about your statement that is absolutely correct is that the freeloaders are taking advantage of anonymity to illegaly distribute copyrighted material, and the record companies are fighting back using those same arms (that would be, the anonymity of the system).
So what you're saying makes sense, but you appear confused about who has the defensive and who has the offensive agenda.
This is not illegal, so why do the record companies need a new law?
I think this is a good question. I suppose the
answer is that if there's a law, it doesn't leave
much to a courts imagination, and the record companies are seeking clarification. I think you're basically right though-- the law doesn't really put anything new on the table.
Someone posts the IP addresses of the "legit hackers" on the web? You can bet that all the script kiddies will come out of the woodwork then...
As for the dummy files, what about a system that allows people to A) vouch for their songs, and B) give an MD5 hash?
As soon as they drop their anonymity, they're easy targets for the RIAA who can go after the large offenders in court. The whole problem with this mass piracy is that it depends on anonymity, so the record cos can abuse that anonymity, just like the freeloaders are.
Umm okay. They can have that right if I can have the right to DoS the RIAA for infringing on my fair use rights.
Read the damn article! It's not saying that they
can ping-flood P2P networks. It's basically saying that they can act as anti-social participants by putting dud-files on there. The beautiful thing about this is that the record companies can use anonymous cowardliness against anonymous cowards. Basically, if the freeloaders can take advantage of the anonymity that's necessary for something as
underhand and sleazy as this, then so can the record companies.
I wonder how it would be possible to DoS P2P services without destroying legitimate uses for P2P as well...
Ans: read the article
Additionally, wouldn't DoSing P2P services slow the Internet as a whole, harming all legitimate users of the Internet?
Ans: read the article.
Basically, the point is that the record companies can put dud files on the network. It only hurts people who try to download the copyrighted titles.
Based on my experience (I've been using GNU/Linux since 1993) it is correct. Even ill-behaved binaries packaged specifically for some ancient version of Red Hat, like the Sybase 11.9.2
binaries, can be made to work with, for example, the current release of Gentoo
I suppose can be made to work is the key
point that I missed the first time. This is true,
provided that the binaries are really compatible.
The reason that binaries are usually compatible is
that vendors either don't use any libraries besides libc
and raw Xlib, or they statically link. Neither
solution is terribly satisfactory.
We can get it working, but it is more trouble than it is worth because of the way Sybase has chosen to package it
The same argument applies with binaries packaged in this "distribution neutral" manner. You can
make it work, but it would be nicer if it just
worked without manual intervention.
t worst, your installation script needs to ask a human being (the person installing the software) where the
other software it requires is located (be it KDE, Gnome, or what have you). It should be doing this regardless, and getting permission before it does any mucking about with the installed (and
presumably functioning) system, and it most certainly should not be making assumptions about any system it is installing upon.
You're entitled to an opinion on the degree to which installation should be automated, but
it's worth noting that your opinion does not
appear to reflect either the opinion of the market
which purchases distributions that make such assumptions in post-install scripts, or the users
who drive that market.
Furthermore, if your packaging, or your binary, requires modification to existing init scripts, then it is broken.
I didn't say it should. However, it could certainly modify other files (eg:/etc/ld.so.conf, ) As for installing init scripts, at present different distributions put them in different places. There are similar issues with other things.
Another problem with installing binary tarballs is
that once you do that, you're outside the package management system. There are obvious problems with this.
ibstdc++ is the only real problem, and even it is easilly resolvable using either chrooted environments, or environments with a modified ld.so.conf configuration in userspace.
libstdc++ dependencies cascade to all C++ programs installed on your system, and all libraries that are C++ based. And it's not the only problem. Any library potentially has the same issues. As for "easily", I don't think a separate
chrooted environment per application is an "easy"
solution. Modifying the configuration of ld.so.conf doesn't help a whole lot, because
it's not going to automatically create a parallel subsystem of libraries based on the other libstdc++ version, and it's going to make the other libstdc++ version unavailable.
nd that is the most extreme example. The other examples you cite can be addressed with symbolic links (ideally in a subdirectory added to the app's LD_LIBRARY_PATH specific to that app, so that
the overall system isn't cluttered).
You can't address different soname conventions with symbolic
links. If an application wants a library called
libqt-gcc3.1.so.3, you're not going to get away with relabelling some other libqt. The soname is
built into the library.
You could have a special LD_LIBRARY_PATH
workaround for cases where you merely have two incompatible libraries with the same soname (eg compiled against different g++ versions), but that means you're going to have to install all the required libraries for that
application in that directory -- so you're essentially back to the statically linked solution.
Even this doesn't always work. For example, KDE creates a.qtrc that tells qt to load certain plugins. So if you're running a gcc 3.1 Qt and a gcc 2.9x qt, they're going to clash because the gcc 3.1 qt will try to load plugins built for the gcc 2,9x Qt and/or vice versa.
This simply isn't true. RPM is most emphatically NOT distribution neutral, even if volunteer developers have spent many man-hours writing packages like "alien" in order to make RPMs accessible to
the majority of distros out there which do not use RPM.
I didn't say that it was "distribution neutral".
tar.gz IS distribution neutral. A well packaged binary, with all necessary libraries installed in its own/opt subdirectory and a run script that sets the
library resolution environment appropriately goes a very long way toward making a binary distribution neutral.
If it doesn't live under the distributions packaging system, it's not distribution neutral. How do I know that uninstalling or upgrading library (X) won't break my "distribution neutral" tarball ? I don't, unless the tarball was statically linked, or ships its own libraries, or
ships with such a spartan set of dependencies that
I can remember them.
This is a null argument. It is akin to [insert favorite religion here] saying that if everyone believed as they do the world would have peace.
No it isn't. it makes an important point-- that
binary compatibility addresses the issues
that you keep whining about.
First, Red Hat (and UL) change, and they change fairly quickly.
Bogus assumption. If UL is based on LSB and the
other distributions are based on LSB, it's reasonable to expect that the LSB based distributions have a substantial overlap in compatibility with united. On the other hand, if distributions want to follow Redhat, they are, as you say, on a treadmill.
Second, there are other approaches which, in some cases (like the source based distros such as Source Mage and Gentoo) work better than anything Red Hat or UL is going to be able to come up with
because their very paradigm is superior. Coercing them to adhere to Red Hat's notion of how things should be means giving up much of the technnical merit that makes Source Mage and Gentoo
signficiantly more stable and better performing than, for example, Red Hat (or any other binary-based distro, for that matter).
They're within their rights to do things differently, but that's a tradeoff you make. You're either compatible with the market leaders, or you're technically superior (whatever that means) and pay the price for being incompatible.
We have some degree of standardization already (LSB compliance, LFS, etc.). We do not need proprietary standards in addition to that,
You're "heap closing". You have not demonstrated that United doesn't add any value, or that LSB and LFS address the problems that United are addressing. You haven't shown that United is going
to add incompatibilies, while I have pointed out that United supplements, and not replaces the standards you mention. All you've done is offered dark mumblings, unsupported speculation, and conspiracy theories.
This is an obvious troll, and you sir, have been
suckered. I'm not sure what's funnier -- the troll
itself or the dimwits who took it seriously. What is
clear from the amounts of responses this troll gets
is that the troll is clearly more intelligent than
the respondents !
It doesn't matter what's bogus, the only thing that matters is the thing that gets someone to write you a check. If you go out of business because nobody buys your product, you can't be crying about how bogus the marketplace is and make it all better.
If you look at it that way, corporate customers are
not like cheapskate slashdot lusers who whine about how something is "too expensive" on the basis of
some ill-founded claim that they think the product
"should be" cheaper. They're only interested in
value for money. If a commercial Linux distribution
provides better value to the customer than competiting alternatives (like a free distribution, or a free distribution with separately purchased support, or Microsoft or Sun), then they will go for it. Corporations are not very interested in nonsensical moral arguments about how much someone "should" charge,
As I pointed two sentences later (which you chose to completely remove, since it completely rebuts the point you made based upon my edited comments), binaries can in general be made to work with any distribution, regardless of packaging system or file organization, if the binary is provided in a tarball, along with a list of required dynamic libraries and their versions.
This does not advance your argument, because it is simply incorrect. I was do you a favor by snipping this (-;
Of course, the binaries themselves may work, but then again, may not-- for example, what if libstdc++ was compiled with different C++ compilers ? Or if a
library does something has an ABI change without a change of soname ? What if different vendors
choose different sonames for the same library ? (eg I recently used libqt-gcc-3.1.so.3 for a gcc 3.1 based Qt. Someone else might use a different
name for a gcc 3.1 based qt. )
Assuming these issues don't prove to be a problem, and you do actually have binary compatible packages, you're still some way from
having a package that the average user will find useful. For example, what if the package needs to install init scripts, or configuration files, or
files for KDE/GNOME, or run some post-install scripts to work properly, etc ? Having the actual binaries ius only a small part of the picture. If you'd done any packaging, you'd know this.
So no, I'm not snipping context to make you look bad, I'm snipping it to address the main line
of argument.
If United Linux is based upon the
LSB, then why not certify things as "LSB compliant and allow them to work with any distro ?
If you read the article, you'd be able to answer
this correctly, instead of spouting speculative
conspiracy theories. The answer is that LSB does
not address some issues like internationalisation, for example. So as far as
your definition of "work" is concerned (meaning
binaries link properly), they would "work with
any distro", but for the intents and purposes
of United Linux's more ambitious goals (internationalisation, for example), they would
not.
The answer is rather obvious, if unpleasant: because UL intends to have additional, distro-specific standards to which software vendors will be required to adhere for certification, which may well mean (and, perhaps, even be designed such) that such software will be less compatable with other distributions
I don't see how it could be less compatible. At worst, it could handle things like internationalisation, installing configuration/desktop files, etc a little differently. But you've stated that these are things that you don't consider to be very important anyway (and things that don't work correctly today, for that matter), so I don't see why you're making such a fuss about it.
When releasing binary packages, one can package them in a distriubution-neutral format (tar.gz for example, NOT rpm or deb), and provide in the README an exhaustive list of the required libraries and versions said package needs to run, with or without hints for installation on various distros (the latter are nice, but not required for functionality). This is the CORRECT
Correct to you maybe. All this amounts to is that you have binary packages which are equally broken on all distributions. The point is that
there's no such thing as "distribution neutral".
An RPM package can easily be converted to a
binary tarball (slackware ships a utility for this), but without more integration, you're still
stuck with a package where the install requires
a fair degree of manual intervention.
BTW, without some degree of standardisation, it also means commerical software is stuck with libc-only, static binaries, (basically this is the way it's been) or incompatibility (because no-one will have all the right libraries)
OR, one can package their software such that it is designed ONLY to work with [Red Hat | UL], taking choice away from their customer
If Redhat were binary compatible with everyone
else , I don't see how you could credibly claim
that the packages "only worked with Redhat", unless you expect some distribution integration,
which you don't get today.
And no, it's not a problem if the packages are
RPM only, because it is trivial to convert an
RPM to a binary tarball. What is highly nontrivial is actually doing something useful with that binary tarball.
It's very simple. They don't write the software, so they are a third party. Full price is what you'd expect to pay to a first party OS vendor like Sun or Microsoft.
Which is a bogus way of computing price, because it
makes the obviously false assumption that (a) the products are comparable (they are not. Microsoft do their own packaging, build management and integration, and the products they do that with are less numerous than a Linux distribution), and (b) there are no other factors which can/should impact price.
No CD or iso image carries a promise of support. Hell, there is a disclaimer of no warranty and no support in nearly every software package that will be on the UnitedLinux CD.
That might be true, but the fact remains that customers might expect a certain quality of service associated with a certain brand name. That in itself would probably give them some kind of
case.
With the car analogy, I was just making the point that using someone else's trademark to sell a product isn't against the law unless you're misrepresenting the product you're selling as something it's not.
Right -- so when you say you're selling "United Linux", when united linux is actually a product that is supplemented by support, then you are
misrepresenting the trademark.
Slashdot Mirror
That would be considerably higher than the conviction rate for software piracy (-; The rest of your post is snipped, because it completely fails to address the main point-- that homicide is prosecuted much more aggressively than the vast majority of other crimes.
I get my computers from ASL, and so do my employers, so I've dealt with a number of their machines. They do Linux laptops, and will not charge you for Windows on a Linux-only system.
The difference is that most distributors don't ship braindead kernels nowadays.
About 2/3 of homicides result in an arrest, and about 2/3 of them result in succesful prosecution. The succesfully prosecuted cases nearly always result in a life prison sentence or the death penalty.
Cheers,
You had to recompile it to get sound to work.
Actually, the questions he is asking are indeed very important. It's all well to say that code "should be well designed", and indeed, most books spend a lot of time talking about design principles for people with clean slates. Unfortunately, very few people have a clean slate to work with. Using a good design up front is not an option if you're not the one who did the upfront design. We are either stuck with maintaning poorly designed code, or even code that was designed well up-front, but needs a change in design to meet changing requirements. What a book like refactoring brings to the table is the process of incremental redesign. Redesigning code without rewriting it is a fine art, and refactoring basically explains how to do it.
It's not that simple. Do you understand the difference between total costs and marginal costs ? Let me explain in more detail:
Suppose that selling CDs have the following costs:
The costs of selling tapes are:
Notice that the overlap here is considerable-- in particular, by the time you pay the costs for selling CDs, you've paid nearly all the costs for tapes.. So, supposing that you have a profitable CD business up and running. Then to add a supplementary tape business, you don't need to pay the total costs of the tape operation. You only need to pay for the marginal costs (in other words, you don't need to pay to record the music opr promote the band, because you did that when you set up the CD operation).
So it's entirely plausible that the expected revenue from selling tapes exceeds the marginal costs of adding a tape operation to a CD operation (which is what the record companies pay), but doe NOT exceed the total cost of running the tape operation.
If the price of the media is unimportant, why are CDs MORE expensive than tapes?
The assumption that the price of the media determines the selling price is false. Tapes are cheap because no-one would buy them if they were more expensive (because they offer less utility to the buyer)
Of course, they got greedy, and never lowered the price.
You've done no estimates of prices vs inflation, so you're not in any position to even make that claim. My guess is that prices are approximately flat, and the reason is that the bulk of the costs are directly correlated with the price of living.
I can get CDs for ~$5.00. And you know what? The record clubs MAKE MONEY selling them at that price!
You're a smart buyer -- good for you. The fact that you can get them cheaply through this venue shows that the high prices are not a result of the record companies greed, but rather, that of an inefficient distribution model. By spending your money on someone with a low overhead distribution model than traditional retail outlets, you get a better deal.
There could be a lot of reasons why you don't get a price reduction. For example, a more uniform pricing scheme entails less administration costs. I'm not proposing this as a reason, but simply pointing out that it's not at all obvious that retailers will pass savings on to customers product for product. For example, if large record companies that produce large lines of low cost recordings, they are cheaper on the shelves (for example, some record labels sell jazz recordings at about $10 or so). In the case where savings on an isolated recording aren't passed on, I'd put it down to laziness on the part of the record store.
There are other costs. For example, the employees at the record shop need to eat. In any case, this example is a long way from "proof" that record companies are colluding to keep prices high. Your other example just shows that the record shops are getting greedy. There could be some ominous agreement between other record companies and the record stores to keep prices of competing albums high, but one needs to make an argument to that effect.
No it isn't. All that tells you is that selling tapes is not a viable business in its own right (meaning, if a record company stopped selling CDs and only sold tapes, they would not last very long). The reason that record companies can keep a relatively unprofitable tape selling business alive is that there is a substantial overlap in the costs of producing the tape and the costs of producing the CD.
AS well as the cd "single" that costs a hell of a lot less then the cd, and still has the same massive hype and advertising attached.
Again, you've already spent the money on the hype and marketting before you produce the single. The marginal cost of releasing it is relatively low. You don't have to pay those marketting costs more than once, you know.
All prices go up, the price of paying salaries also goes up. It's called "inflation". The ignorant slashdot whiners have done a lot of whining, but posted no hard evidence that there is a rising trend in the cost of CDs relative to the cost of living.
The only concrete issue you've pointed to that has some legitimacy is their choice of RPM format. My counter arguments are:
It is irrelevant that this extended standard is based upon open standards if it is being modified and imposed back upon the community in a non-open fashion as has been described here. If this were Microsoft everyone would be shouting "embrace and extend," for indeed that is exactly what is proposed here
I agree that this is an instance of "embrace and extent" (sans destroy). I think there is an important distinction between this and simply attempting to subvert the standard by using a competing one -- to me, it's not irrelevant at all, because LSB compliant distributions will be binary compatible with United. The difference is, I don't really have a problem with that. This is the way standards evolve. Design by a committee doesn't work very well, and you need someone to blaze a trail and experimenting before committing something to a standard. For example, gcc has "embraced and extended" both C and C++, and the extensions have for the most part had good consequences. So you could use the words "embrace and extend", but I'd contest a claim that this is necessarily a bad thing. Hence my comments about "dark mumblings" (sorry if that sounded harsh)
It is my opinion that any non-open approach to defining standards is a very negative thing for the community. The process is as important as the result, and the open, collaborative process here is being abandoned and supplanted by a coercive, closed process that is designed to benefit one or two entities, under the guise of serving the community.
Again, I disagree. The claim I'd contest is that this is being sold as a replacement for LSB and other standards. Standards codify existing practice, committees aren't very good at designing and innovating, but they are good for formalising and clarifying details about how things should be done. If United Linux was attempting to replace LSB, I'd be against it, but at this stage, I don't see evidence that supports such a claim.
I'm not sure what you mean. They certainly run a risk of creating PR problems for themselves. I suppose they're counting on most people not caring too much about it, and taking a calculated risk. I think it's a fair bet that pandering to the people who are up in arms about their "right" to freeload isn't a good business strategy. However, they need to be careful that they don't give the impression that they're blowing off paying customers at the same time as they blow off the freeloaders.
I don't think it would destroy future digital download services though. The primary weakness in illegal file trading is that it depends on anonymity. If you remove the anonymity constraint, the picture changes substantially.
Not a whole lot. The primary goal is clearly to push the noise/signal ratio past a certain level, not to saturate the network.
I don't see how you can "use the same arms against them", because they are not attempting to download copyrighted content from your computer (-; What they are doing is NOT really a "DoS" attack, but rather, exploiting the fact that the system relies on anonymity.
Basically, the one thing about your statement that is absolutely correct is that the freeloaders are taking advantage of anonymity to illegaly distribute copyrighted material, and the record companies are fighting back using those same arms (that would be, the anonymity of the system). So what you're saying makes sense, but you appear confused about who has the defensive and who has the offensive agenda.
I think this is a good question. I suppose the answer is that if there's a law, it doesn't leave much to a courts imagination, and the record companies are seeking clarification. I think you're basically right though-- the law doesn't really put anything new on the table.
As soon as they drop their anonymity, they're easy targets for the RIAA who can go after the large offenders in court. The whole problem with this mass piracy is that it depends on anonymity, so the record cos can abuse that anonymity, just like the freeloaders are.
Read the damn article! It's not saying that they can ping-flood P2P networks. It's basically saying that they can act as anti-social participants by putting dud-files on there. The beautiful thing about this is that the record companies can use anonymous cowardliness against anonymous cowards. Basically, if the freeloaders can take advantage of the anonymity that's necessary for something as underhand and sleazy as this, then so can the record companies.
Ans: read the article
Additionally, wouldn't DoSing P2P services slow the Internet as a whole, harming all legitimate users of the Internet?
Ans: read the article. Basically, the point is that the record companies can put dud files on the network. It only hurts people who try to download the copyrighted titles.
I suppose can be made to work is the key point that I missed the first time. This is true, provided that the binaries are really compatible. The reason that binaries are usually compatible is that vendors either don't use any libraries besides libc and raw Xlib, or they statically link. Neither solution is terribly satisfactory.
We can get it working, but it is more trouble than it is worth because of the way Sybase has chosen to package it
The same argument applies with binaries packaged in this "distribution neutral" manner. You can make it work, but it would be nicer if it just worked without manual intervention.
t worst, your installation script needs to ask a human being (the person installing the software) where the other software it requires is located (be it KDE, Gnome, or what have you). It should be doing this regardless, and getting permission before it does any mucking about with the installed (and presumably functioning) system, and it most certainly should not be making assumptions about any system it is installing upon.
You're entitled to an opinion on the degree to which installation should be automated, but it's worth noting that your opinion does not appear to reflect either the opinion of the market which purchases distributions that make such assumptions in post-install scripts, or the users who drive that market.
Furthermore, if your packaging, or your binary, requires modification to existing init scripts, then it is broken.
I didn't say it should. However, it could certainly modify other files (eg: /etc/ld.so.conf, ) As for installing init scripts, at present different distributions put them in different places. There are similar issues with other things.
Another problem with installing binary tarballs is that once you do that, you're outside the package management system. There are obvious problems with this.
ibstdc++ is the only real problem, and even it is easilly resolvable using either chrooted environments, or environments with a modified ld.so.conf configuration in userspace.
libstdc++ dependencies cascade to all C++ programs installed on your system, and all libraries that are C++ based. And it's not the only problem. Any library potentially has the same issues. As for "easily", I don't think a separate chrooted environment per application is an "easy" solution. Modifying the configuration of ld.so.conf doesn't help a whole lot, because it's not going to automatically create a parallel subsystem of libraries based on the other libstdc++ version, and it's going to make the other libstdc++ version unavailable.
nd that is the most extreme example. The other examples you cite can be addressed with symbolic links (ideally in a subdirectory added to the app's LD_LIBRARY_PATH specific to that app, so that the overall system isn't cluttered).
You can't address different soname conventions with symbolic links. If an application wants a library called libqt-gcc3.1.so.3, you're not going to get away with relabelling some other libqt. The soname is built into the library. You could have a special LD_LIBRARY_PATH workaround for cases where you merely have two incompatible libraries with the same soname (eg compiled against different g++ versions), but that means you're going to have to install all the required libraries for that application in that directory -- so you're essentially back to the statically linked solution.
Even this doesn't always work. For example, KDE creates a .qtrc that tells qt to load certain plugins. So if you're running a gcc 3.1 Qt and a gcc 2.9x qt, they're going to clash because the gcc 3.1 qt will try to load plugins built for the gcc 2,9x Qt and/or vice versa.
This simply isn't true. RPM is most emphatically NOT distribution neutral, even if volunteer developers have spent many man-hours writing packages like "alien" in order to make RPMs accessible to the majority of distros out there which do not use RPM.
I didn't say that it was "distribution neutral".
tar.gz IS distribution neutral. A well packaged binary, with all necessary libraries installed in its own /opt subdirectory and a run script that sets the
library resolution environment appropriately goes a very long way toward making a binary distribution neutral.
If it doesn't live under the distributions packaging system, it's not distribution neutral. How do I know that uninstalling or upgrading library (X) won't break my "distribution neutral" tarball ? I don't, unless the tarball was statically linked, or ships its own libraries, or ships with such a spartan set of dependencies that I can remember them.
This is a null argument. It is akin to [insert favorite religion here] saying that if everyone believed as they do the world would have peace.
No it isn't. it makes an important point-- that binary compatibility addresses the issues that you keep whining about.
First, Red Hat (and UL) change, and they change fairly quickly.
Bogus assumption. If UL is based on LSB and the other distributions are based on LSB, it's reasonable to expect that the LSB based distributions have a substantial overlap in compatibility with united. On the other hand, if distributions want to follow Redhat, they are, as you say, on a treadmill.
Second, there are other approaches which, in some cases (like the source based distros such as Source Mage and Gentoo) work better than anything Red Hat or UL is going to be able to come up with because their very paradigm is superior. Coercing them to adhere to Red Hat's notion of how things should be means giving up much of the technnical merit that makes Source Mage and Gentoo signficiantly more stable and better performing than, for example, Red Hat (or any other binary-based distro, for that matter).
They're within their rights to do things differently, but that's a tradeoff you make. You're either compatible with the market leaders, or you're technically superior (whatever that means) and pay the price for being incompatible.
We have some degree of standardization already (LSB compliance, LFS, etc.). We do not need proprietary standards in addition to that,
You're "heap closing". You have not demonstrated that United doesn't add any value, or that LSB and LFS address the problems that United are addressing. You haven't shown that United is going to add incompatibilies, while I have pointed out that United supplements, and not replaces the standards you mention. All you've done is offered dark mumblings, unsupported speculation, and conspiracy theories.
This is an obvious troll, and you sir, have been suckered. I'm not sure what's funnier -- the troll itself or the dimwits who took it seriously. What is clear from the amounts of responses this troll gets is that the troll is clearly more intelligent than the respondents !
If you look at it that way, corporate customers are not like cheapskate slashdot lusers who whine about how something is "too expensive" on the basis of some ill-founded claim that they think the product "should be" cheaper. They're only interested in value for money. If a commercial Linux distribution provides better value to the customer than competiting alternatives (like a free distribution, or a free distribution with separately purchased support, or Microsoft or Sun), then they will go for it. Corporations are not very interested in nonsensical moral arguments about how much someone "should" charge,
This does not advance your argument, because it is simply incorrect. I was do you a favor by snipping this (-; Of course, the binaries themselves may work, but then again, may not-- for example, what if libstdc++ was compiled with different C++ compilers ? Or if a library does something has an ABI change without a change of soname ? What if different vendors choose different sonames for the same library ? (eg I recently used libqt-gcc-3.1.so.3 for a gcc 3.1 based Qt. Someone else might use a different name for a gcc 3.1 based qt. ) Assuming these issues don't prove to be a problem, and you do actually have binary compatible packages, you're still some way from having a package that the average user will find useful. For example, what if the package needs to install init scripts, or configuration files, or files for KDE/GNOME, or run some post-install scripts to work properly, etc ? Having the actual binaries ius only a small part of the picture. If you'd done any packaging, you'd know this.
So no, I'm not snipping context to make you look bad, I'm snipping it to address the main line of argument.
If United Linux is based upon the LSB, then why not certify things as "LSB compliant and allow them to work with any distro ?
If you read the article, you'd be able to answer this correctly, instead of spouting speculative conspiracy theories. The answer is that LSB does not address some issues like internationalisation, for example. So as far as your definition of "work" is concerned (meaning binaries link properly), they would "work with any distro", but for the intents and purposes of United Linux's more ambitious goals (internationalisation, for example), they would not.
The answer is rather obvious, if unpleasant: because UL intends to have additional, distro-specific standards to which software vendors will be required to adhere for certification, which may well mean (and, perhaps, even be designed such) that such software will be less compatable with other distributions
I don't see how it could be less compatible. At worst, it could handle things like internationalisation, installing configuration/desktop files, etc a little differently. But you've stated that these are things that you don't consider to be very important anyway (and things that don't work correctly today, for that matter), so I don't see why you're making such a fuss about it.
When releasing binary packages, one can package them in a distriubution-neutral format (tar.gz for example, NOT rpm or deb), and provide in the README an exhaustive list of the required libraries and versions said package needs to run, with or without hints for installation on various distros (the latter are nice, but not required for functionality). This is the CORRECT
Correct to you maybe. All this amounts to is that you have binary packages which are equally broken on all distributions. The point is that there's no such thing as "distribution neutral". An RPM package can easily be converted to a binary tarball (slackware ships a utility for this), but without more integration, you're still stuck with a package where the install requires a fair degree of manual intervention. BTW, without some degree of standardisation, it also means commerical software is stuck with libc-only, static binaries, (basically this is the way it's been) or incompatibility (because no-one will have all the right libraries)
OR, one can package their software such that it is designed ONLY to work with [Red Hat | UL], taking choice away from their customer
If Redhat were binary compatible with everyone else , I don't see how you could credibly claim that the packages "only worked with Redhat", unless you expect some distribution integration, which you don't get today. And no, it's not a problem if the packages are RPM only, because it is trivial to convert an RPM to a binary tarball. What is highly nontrivial is actually doing something useful with that binary tarball.
Which is a bogus way of computing price, because it makes the obviously false assumption that (a) the products are comparable (they are not. Microsoft do their own packaging, build management and integration, and the products they do that with are less numerous than a Linux distribution), and (b) there are no other factors which can/should impact price.
That might be true, but the fact remains that customers might expect a certain quality of service associated with a certain brand name. That in itself would probably give them some kind of case.
With the car analogy, I was just making the point that using someone else's trademark to sell a product isn't against the law unless you're misrepresenting the product you're selling as something it's not.
Right -- so when you say you're selling "United Linux", when united linux is actually a product that is supplemented by support, then you are misrepresenting the trademark.