Microsoft won the browser war because IE4 beat the hell out of any other browser that was available at the time.
Actually, no. IE4 was more or less equivalent to Netscape 4 (although Communicator really was crap). IE4 was also bundled with Windos, so all the newbies started using it.
In fact, IE4 beats the hell out of the latest Netscape 4.7x release on any platform.
Hmmm... Let's see here:
# apt-cache search netscape
[... mozilla and other random packages...]
navigator-base-477 - Navigator base support for version 4.77
navigator-nethelp-477 - Navigator online help for version 4.77
navigator-smotif-477 - Netscape Navigator 4.77 (static Motif)
netscape-base-477 - 4.77 base support for netscape
netscape-ja-resource-477 - Netscape 4.77 Japanese resources.
netscape-java-477 - Netscape Java support for version 4.77
netscape-ko-resource-477 - Netscape 4.77 Korean resources.
netscape-smotif-477 - This installs a standard set of netscape prog
# apt-cache search internet explorer
camserv - stream video out onto the web
wwwoffle - World Wide Web OFFline Explorer
#
Yep! By not existing, IE4 beats Netscape 4 on my Linux box! </SARCASM> (yes, i realize there could be a version available but not packaged for Debian. However, there isn't)
Even on Windows, i still find IE and Netscape 4 about equivalent for most purposes. It's amazing how little DHTML is actually used, as long as you avoid sites whose only purpose in life is to flash and blink at you (or to show off DHTML).
Mozilla easily beats any IE release.
Re:There is nothing wrong with RPMs. Only packager
on
Is RPM Doomed?
·
· Score: 1
your final source package [emphasis mine]
Ah! I had thought you were talking about binary packages. Especially since Debian doesn't have source 'packages' (just.tar.gz sources with diffs) i tend to consider packages to be binary things.
Well, if you use a package style like libc6 does, then it's easy enough. Otherwise... hmmm... ok, you got me there. Personally, i just put my patch online and expect people who want to compile to know enough to download and apply it to the standard sources;)
Re:The problem with ANY packaging system....
on
Is RPM Doomed?
·
· Score: 1
Unless we start vet'ing packages for compliance with that simple idea, no package manager created can solve the problem.
In other words, until the packager actually makes sure the package versions make sense, no package manager can solve the problem of stupid versioning. Sounds about right to me, although i worry about a distro that thinks it can get away without verifying the package versions...
BTW, if 1.5 really was not backward-compatible with 1.4 (and upstream was impervious to clues), i suspect they'd make a "libpease1.5" package.
How would you create a.deb if you needed/usr/bin/foo and it could be supplied by Foo.deb or FooAndNarf.deb? Which package would you tie to?
Depends: foo | foo-and-narf
If foo is something generic, like "web broswer", then "Depends: web-browser" and have foo, foo-and-narf, baz, mozilla, etc. all "Provides: web-browser". Or, if foo-and-narf is just a nonstandard replacement for the widely-used foo, it might be able to get away with "Provides: foo" and leave all the other packages with a simple "Depends: foo" (dpkg had/has a few issues with versioned dependencies in this case).
No, i'm not a Debian developer, i just pay attention.;)
Re:There is nothing wrong with RPMs. Only packager
on
Is RPM Doomed?
·
· Score: 2, Informative
this means it's very easy to take a Red Hat package, which contains pristine, original source + patches, and add my own local patches leaving the RH patches in their own "pristine" state. This is harder to do in dpkg -- requires some slight-of-hand at least.
I don't remember needing any slight of hand to do this. apt-get source foo, gets the pristime source and the patches. Copy the patched source dir, make my changes, and diff against the original patched source dir. There i go. Later, get the upgraded version (apt-get source foo automatically only downloads the new diffs, using the old upstream sources (unless, of course, it's a new upstream version)), apply the patch, and there i go again.
If you don't want to use apt-get, download the.tar.gz,.diff.gz, and.dsc files by hand and dpkg-source the.dsc to have it unpack for you. Or do it by hand with standard tools, you'll just have to remember to chmod +x debian/rules that way.
I'm having a great deal of trouble seeing your technical superiority here. The only possibility i see here is if rpm would automatically try to apply my patch after applying the distro's patches, which likely as not is going to fail anyway. Please explain.
Re:Binary Distros Are Dead
on
Is RPM Doomed?
·
· Score: 2, Interesting
most of the issues raised are inherent to binary based distros
Poor dependencies. Nope, not inherent, and can hit source-based distros too.
Poor upgradability. Nope, not inherent, and can hit source-based distros too.
Incompatible changes to the package format. Nope, not inherent.
Incompatible file locations. Nope, not inherent, and can hit source-based distros too.
Upgrades can break things. Inherent, but hits source-based distros just as easily.
Ok, perhaps i missed something in the article. Where are these issues inherent to binary distributions that source distros don't suffer from?
The software is compiled against the exact library versions installed on your system, so no subtle incompatabilities arise due to slightly mis-matched binaries. This eliminates a whole class of bugs, and a whole host of problems that can affect stability and reliability.
At install. However, wither you lose this when you upgrade the library, or you have to recompile every single app that uses the library whenever the library changes. Damn, i would hate to upgrade anything X depends on in a system like that, 2 weeks until the upgrade is complete! (assuming my old box doesn't run out of disk space first).
A non-stupidly-written library will be very easy to handle in dependencies (remember, minor version changes indicate backwards-compatible API changes, so app recompile shouldn't be necessary), a stupidly-written one somewhat harder. Either way, a good packaging system can easily handle this modulo human error. In fact, there's less chance for error when a few knowledgeable people handle all the compiling, as opposed to having everyone try it on their own. And when something does go wrong, everyone is likely to have the same problem, so more eyes can look for it.
Upgrades are very easy. In the case of Source Mage they are virtually automatic (you select the package to update and everything is taken care of for you), in the case of Gentoo they are less automatic and require some care, but are nevertheless easier than with any binary distribution I've ever tried (and I've used all the major ones at one time or another),
Somehow, i doubt recompiling everything from source (automated or not) is easier than apt-get dist-upgrade. Definately not easier than tracking unstable (as, based on your comments here, you're effectively doing with either of your favorite source-based distros).
Security is improved in one way: the ease and ability to keep up with security updates. Binary distros are still trying to get this to work smoothly (and mostly not succeeding, or requiring a tradeoff like Debian Stable, in which one must run 2 year-old software to enjoy that level of security). This is really a side effect of the previous point, but is significant enough to deserve sepearate mention.
Well, it would be deserving if it made any sense. You're comparing bleeding-edge source distros with tested-almost-to-the-point-of-absurdity binary distros. Try comparing to Debian unstable instead, it would be somewhat more accurate.
You also neglect the fact that the updated code needs to be compiled eventually (since source-based pushes this to the user, they get 'release' ahead a little here), tested for breakage (from your description they just throw the source up without any testing, i hope this is wrong), packaged (a little more time here), and uploaded to the repository (which can take some time, depending on procedures in place).
and with Gentoo the flexibility of having multiple versions of libraries and even runtime apps is very useful.
I have multiple versions of many libraries on my Debian system here. A few apps too (e.g. gcc, autotools). I don't really need multiple versions of most apps. Does Gentoo make everything multi-versonable, even when config file formats (.foorc in $HOME, for example) change incompatibly and other sharing problems like that?
in contrast to binary distros that typically require 3-6 months (worse for some distros. I still recall the Debian developers irate answer to a user's question on when thye could expect X 4.2 support in the experimental version of Debian ("unstable"), to the effect of "leave me alone, it will be months!")
On the other hand, you're leaving out the part about X being a very large, very complex set of programs that needs quite a bit of time to package properly and ensure upgrades will actually function. You're also leaving out the part about the X packagers having to maintain the 4.1 version at the same time, especially since 4.2 cannot be tested well enough in time to make it into frozen. Further, you're leaving out the part where all this is done in the packagers' free time. And the part where the packagers made 'unofficial' packages available much sooner, so anyone who really wanted to could use them and help get things to the point of "doesn't explode on install". And the part where various patches from 4.2 have been backported to 4.1 (and the part where 4.2 contains patches originated with Debian's 4.1).
All in all, you've severly damaged your argument with your poorly reasoned claims.
That kind of nonsense is why there's 50+ email clients and only a handful of the important things like audio/video compression etc... Things with numbers.
And here I thought it was because a very large number of people use email clients every day, and because the relavent protocols are well documented and publicly available, while compression algorithms are used by a relatively tiny number of people, and are typically patented, poorly documented if at all available, and require more math than i suspect the average EE knows either to invent.
Besides which, it sounded like your parent was complaining about trying to teach CS to people "only taking this class because it's required" (and who apparently have more clout with the dean than should be allowed).
Unicode was mentioned somewhere in one of the Apocalypses (Apocalypsen?), i think in conjunction with operators. And i do remember seeing that you'll be able to define your own metacharacters (one example defined \j to be a bare linefeed, as opposed to \n being just about any typical eol sequence).
The change from . to _ is going to bite me too... And $foo[0] to @foo[0]. But i'll learn eventually.
That the GPL has a noble reason for restricting the use of it's software means nothing from a legal standpoint.
The GPL does nothing to restrict the use of the software, in fact it explicitly states why it cannot restrict the use. I suspect you're confusing 'use' with 'modification' and/or 'redistribution'.
We can not justify being hypocritical about the following of license agreements by saying that we don't agree with the reasoning behind company x's license.
To clarify slightly, i'll also refer to this quote from your earlier post in this thread that the above quote refers to:
but the same people who whine about attempts to keep people from "pirating/breaking license agreements"
Just because we complain about the BSA's often unethical and occasionally (often?) illegal tactics, and many companies overbearing and possibly invalid licenses (see First Sale and Fair Use, among other things), doesn't mean we support those who're breaking license "agreements". Interesting word choice BTW, with the licenses you're referring to you have no choice but to pretend to agree in order to simply use a product you've legally purchased.
[The GPL is] still a license
Remember, the GPL grants rights you wouldn't otherwise have. Proprietary licenses attempt to remove rights you already have, usually without consideration and after the sale.
I assume the intended use of quarters is for laundry machines, but many collges nowadays use debit-style cards for this purpose -- the laundry machines at my college don't even accept quarters, just the university's debit cards.
If they do accept quarters, and there isn't a cash-to-card machine in/near every laundry room (and the debit system isn't such that you can't run out of money), get the quarters anyway! It's not fun to be a few cents short on the card and have to leave your laundry just sitting there while running down the street to the nearest machine in the rain/snow in your "i'm wearing this because all my decent clothes are in the machine" outfit...
Quarters are good for vending machines too, although dollar bills tend to work in those these days.
The only way you could lock yourself out was if you were gone without your keys when your roommate locked the door.
Happened to me once, stupid roommate didn't realize i was in the shower that morning like i was every morning. After that, i took my keys even when i went to shower.
Ask the RA, front desk, office, whoever has the spare key to open it
Cost $5.
Make a duplicate key just to keep in your wallet/purse.
Duplicating shop said "no can do, that's a security key".
Red Hat's strength is that the stuff they throw in actually works. More or less out of the box.
My problem with RedHat isn't that i can't hack it (i have hacked it, actually). The problem is that when it breaks it's more difficult to fix.
Personally, I find RedHat gets in my way whenever i have to use it at work (i co-admin somewhat large number of machines, all RedHat of one version or another). As someone else mentioned, the init.d scripts are extremely annoying with all the sourced files. Linuxconf gets in the way of editing things in/etc by hand, at least it has whenever i've tried. Packages aren't as nice, i still haven't figured out how to make postgresql start on boot without adding the symlink to/etc/rc3.d by hand (fortunately, mysql in a similar setup had an S70 link so i didn't have to worry about picking the proper number). I have no idea what we'll do when we decide to upgrade the boxen still running the older version of RedHat.
Debian, on the other hand, works well for me. Updating packages is easy (i have two machines set up to email me when they detect upgrades are available, so i can't forget). Editing configs isn't as easy as point-and-click in Linuxconf, but it is as easy as vi (works for me, i read the docs anyway to secure things as best i can). Docs are always in/usr/share/doc now, for every single package installed (i've found that some RedHat packages lack any entry in/usr/doc or/usr/share/doc). Upgrading to the latest version is as simple as upgrading a single package.
/lib contains libraries that are required for system boot, up to the point where the other filesystems are mounted. It's generally considered good practice to keep the / partition (which includes/lib) small to reduce the chances of filesystem corruption, which is why there's a separate/usr/lib (and/usr/bin, etc).
The reason it's/usr/lib instead of/lib/usr is similarly simple: if it were/lib/usr,/bin/usr,/sbin/usr, and so on, you'd need a separate partition for each one. But with/usr/lib,/usr/bin,/usr/sbin, and so on you just mount one partition on/usr containing bin, lib, and so on. This makes it much easier to reallocate space: if you suddenly discover you need more space in/bin/usr and you have too much in/lib/usr you have to repartition heavily to transfer the extra to where it's needed, where as/usr/bin and/usr/lib are on the same partition and so automatically share the space.
/usr/X11R6/* is there for hysterical raisins, mostly. My Debian systems, at least, came set up with a symlink from/usr/lib/X11 to/usr/X11R6/lib which could be considered part of a transition to use/usr/lib/X11.
don't like your examples. They are entirely artificial and don't map very well to the issue at hand.
It's hard to map anything well to the issue at hand. I made that point in there somewhere.
Your example isn't really much better, it's still entirely artificial, and the mapping isn't particularly clear either. In particular, are you trying to map doing violence or being jailed to being redistributed in a closed-source fashion?
Why is Sun allowed to distribute a 'proprietary program' in their own big organisation without opening the code
I don't know. Probably it wasn't strictly intended, and just springs from the funny "a corporation is equivalent a person for legal purposes" system we have here. Go ask RMS, he can tell you.
What is inherently wrong with keeping your game's source closed so that less hacks will be developed (securing it through other means than obfuscation is sometimes impossible)?
If you want to do that, don't use the GPL. It's that simple. The GPL is the wrong tool for that job.
So why would you want to decide for someone else that these things should not be possible with the code you give away?
Because you want people who use your code to give you the opportunity to use their code in return? The model seems to me something like this story, except we can't easily just stop providing 'scratcher' with code with the current methods of giving it away, so we take advantage of copyright law's prohibition of the use and only give the necessary permission as long as the recipient doesn't scratch.
PS2. Gratis comes from latin.
Libre probably does too. French and Spanish are both Romance languages derived from Latin, so it's not surprising they share the words. As for whether the person who first came up with using those words to help clarify 'free' versus 'free' was intending Latin, Spanish, French, or another language, i have no idea.
Reasonable would be "We'd prefer if you didn't redistribute out code." Reasonable (if indicative of stupidity) would be "Oh! We didn't realize our license allowed that! We're going to change it." Reasonable would be to accept the offer of a differently named package with text in the documentation and package description stating that it's not the full version.
Reasonable is not "If you do that, we'll change the license to specifically prohibit you. But not until then." That's not particularly nice, and it shows an intention to lie about the openness of your code (because openness of code and level of community support are directly proportional in this community).
Hmmm... reading it again, i get the impression the non-public letter to Marc et al was less diplomatically worded WRT the threatened license change.
Personally, i wish Debian would package it and force Transgaming to change the license for all to see.
Re:One argument for the GPL and against "look alik
on
Debian And WineX
·
· Score: 1
BSD vs GPL is rather like an anarcho-capitalist arguing with an anarcho-socialist over the nature of liberty.
If only i would have seen this before my earlier reply in this thread! Very nice comparison.
Although i suspect "is" fits somewhat better than "is rather like", if you limit application of the labels to views on software alone instead of the nature of property in general... Too bad i haven't studied enough politics to determine which is which. I suppose proprietary software advocates are totalitarian? And MS seems to be fascist then, totalitarian with a side of nationalism and racism (against non-MS, of course). Hmmm... someone should write "If software licenses were governments" like "If operating systems were women/cars/guns/etc".
They're both free. Anyone can modify and redistribute GPL code or BSD code. That's what we tend to mean by libre, so they're both libre too.
The crucial difference is that the BSD code can be made non-free, where as the GPL code must always be free[1]. Or, to put it another way, the GPL code is not free to lose its freedom, but the BSD code is. When people say "the GPL is more free", they mean it because GPL code cannot be non-free, where as BSD code can be made so. When people say "the BSD license is more free", they mean it because BSD code has the freedom to be made non-free, where as GPL code doesn't have this freedom. They're both right, it just depends on which definition of free you use.
An AC in this thread used an analogy with a man:
Man #1 can go anywhere he wants, Man #2 can go anywhere he wants, except jail.
True, with that analogy Man #1 is freer. But how about this one?
Man #1 can be kidnapped and sold into slavery, Man #2 cannot.
Which man would you consider freer now? Argument by analogy is always tricky, neither of these makes a proper case. "Man #1's decendants can be enslaved, Man #2's cannot. Which family is freer?" might be closer than either[2]. But it still has trouble with anthropomorphism, software can't choose to remain free or to give up its freedom[3].
Arandir makes a semantic argument based slightly on French (personally, i've always thought of gratis and libre as Spanish (not that it matters)) and more on 'liberty'. But "absence of external restriction" can mean "external restriction cannot exist" as well as "external restriction does not exist". My dictionary uses "freedom from" instead of "absence of", which makes this distinction even less clear. If you choose 'cannot', then the minor extra restriction on the GPL code makes it more free than the ease of imposing major restriction on the BSD code. It comes back to enslaving children again, Man #1 is free to have slave children, but Man #2's children will always be as free as Man #2 himself.
Hopefully this will shed some light on the situation, or at least convince people to come up with better arguments...
[1] Ignoring the original developer's ability to license it differently, of course.
[2] So Man #2's children can't choose to be slaves either. Some people get off on that sort of thing.
[3] At least not until we get MUCH better at AI...
If they want to prohibit redistribution, they should say so instead of pretending to be quasi-Open Source. Some people will put up with the AFPL but not this more restrictive license they intend to have.
It's the threat and lies that make it dirty.
Clearing things up a little better
on
Debian And WineX
·
· Score: 1
What Transgaming is asking is that distributions don't package the free version of their source as a package
And threatening to change the license to specifically prohibit them (Debian, in this case) from doing so if they try. So it's "we say you can redistribute, but if you do we'll tell you you can't."
so people don't get the impression that when they try to run new game x with copy protection that it doesn't work with the WineX period
As has been pointed out, a name change was offered. And i assume a warning would have been put in the package's description field. This didn't help, still the threat.
Re:Nothing "Wrong" what Transgaming are doing here
on
Debian And WineX
·
· Score: 1
You don't consider pretending to be quasi-Open Source and threatening to change the license to specifically exclude anyone who redistributes to be wrong?
I wish Debian would package it, just to force Transgaming to change their license and make obvious their intentions.
Sprint PCS has a deal somewhat like this. You pay a flat fee for a certain number of minutes per month, then if you go over they start charging.
The problem with this setup is that Sprint has an incentive to NOT give accurate usage information! A friend of mine uses this, and several times she's gone over the limit because the website and the '*4' information deal (which costs minutes, IIRC) aren't up to date even though they claim "Current as of $CURRENT_TIME" (once we even saw "Current as of $CURRENT_TIME+5 hours" online (and no, it wasn't a timezone thing)). And then they turn off her phone because of the extra charges, and don't bother to tell her they prorated her minutes for the next month once she got the money to pay them off; of course, they can't be bothered to write the usage apps to take this prorating into account, only the billing apps...
The advantage of flat rates in general is that they're easier to budget for. With electricity it's not so bad, because whatever electricity you use is basically what electricity you want to use, so it's not that likely to change from month to month (but then you get a cold spell when you have electric heat, owch). With Internet access you use bandwidth receiving flashing banner ads, spam, virus probes, etc, etc, etc. all taking bandwidth you'd rather not use.
Instead of either increasing service to support 1:1, or capping to enforce 1:1, how about this:
When the whole pipe is not being utilized, leave it as-is. When the whole pipe is being utilized, start capping. "Bandwidth hogs" get a smaller fraction of the pipe than non-"hogs".
Since it's apparently possible to determine how much bandwidth each customer has used (given that Comcast's proposal is basically metered fees), just assign each customer's traffic a priority based on the amount of bandwidth (possibly adjusted to discount bandwidth used during unsaturated periods) used over an appropriate sliding window. When the pipe is unsaturated, everybody gets their traffic through as normal so you don't piss off your customers for no reason. When the pipe is saturated, the low-priority traffic from the "bandwidth hogs" gets dropped in favor of higher priority packets.
I'm sure this has some flaws (e.g. a new "bandwidth hog" will take some time to rise above the mean), but it still sounds like a better option than either of the two you presented. It doesn't uselessly limit bandwidth when there's plenty to spare, and it prioritizes so-called "normal users" over "bandwidth hogs" when there is a scarcity. Bonus points if you expose some of this data to the customers (/.ers, etc.) who'd want to see their current status.
Students shouldn't be allowed to delve into the OS like most others here are suggesting. Instead, they should be encouraged to do their task and get off the machine as soon as possible.
Why? I'm reminded of the old saying "Any sufficiently advanced technology is indistinguishable from magic". There's an assumption in there: "sufficiently advanced technology" means "sufficiently advanced beyond the current state of knowledge". You're encouraging students to consider the OS 'magic' by keeping their current state of knowledge low. Some people are fine with this, but some would rather advance their state of knowledge so they can have a better explanation than 'magic' and superstition.
Actually, i feel all students should be encouraged to learn enough about the OS so it's not 'magic', even if they don't go on to become full computer geeks.
Slashdot Mirror
Actually, no. IE4 was more or less equivalent to Netscape 4 (although Communicator really was crap). IE4 was also bundled with Windos, so all the newbies started using it.
In fact, IE4 beats the hell out of the latest Netscape 4.7x release on any platform.
Hmmm... Let's see here:
Yep! By not existing, IE4 beats Netscape 4 on my Linux box! </SARCASM> (yes, i realize there could be a version available but not packaged for Debian. However, there isn't)Even on Windows, i still find IE and Netscape 4 about equivalent for most purposes. It's amazing how little DHTML is actually used, as long as you avoid sites whose only purpose in life is to flash and blink at you (or to show off DHTML).
Mozilla easily beats any IE release.
Ah! I had thought you were talking about binary packages. Especially since Debian doesn't have source 'packages' (just .tar.gz sources with diffs) i tend to consider packages to be binary things.
Well, if you use a package style like libc6 does, then it's easy enough. Otherwise... hmmm... ok, you got me there. Personally, i just put my patch online and expect people who want to compile to know enough to download and apply it to the standard sources ;)
In other words, until the packager actually makes sure the package versions make sense, no package manager can solve the problem of stupid versioning. Sounds about right to me, although i worry about a distro that thinks it can get away without verifying the package versions...
BTW, if 1.5 really was not backward-compatible with 1.4 (and upstream was impervious to clues), i suspect they'd make a "libpease1.5" package.
How would you create a .deb if you needed /usr/bin/foo and it could be supplied by Foo.deb or FooAndNarf.deb? Which package would you tie to?
Depends: foo | foo-and-narf
If foo is something generic, like "web broswer", then "Depends: web-browser" and have foo, foo-and-narf, baz, mozilla, etc. all "Provides: web-browser". Or, if foo-and-narf is just a nonstandard replacement for the widely-used foo, it might be able to get away with "Provides: foo" and leave all the other packages with a simple "Depends: foo" (dpkg had/has a few issues with versioned dependencies in this case).
No, i'm not a Debian developer, i just pay attention. ;)
I don't remember needing any slight of hand to do this. apt-get source foo, gets the pristime source and the patches. Copy the patched source dir, make my changes, and diff against the original patched source dir. There i go. Later, get the upgraded version (apt-get source foo automatically only downloads the new diffs, using the old upstream sources (unless, of course, it's a new upstream version)), apply the patch, and there i go again.
If you don't want to use apt-get, download the .tar.gz, .diff.gz, and .dsc files by hand and dpkg-source the .dsc to have it unpack for you. Or do it by hand with standard tools, you'll just have to remember to chmod +x debian/rules that way.
I'm having a great deal of trouble seeing your technical superiority here. The only possibility i see here is if rpm would automatically try to apply my patch after applying the distro's patches, which likely as not is going to fail anyway. Please explain.
- Poor dependencies. Nope, not inherent, and can hit source-based distros too.
- Poor upgradability. Nope, not inherent, and can hit source-based distros too.
- Incompatible changes to the package format. Nope, not inherent.
- Incompatible file locations. Nope, not inherent, and can hit source-based distros too.
- Upgrades can break things. Inherent, but hits source-based distros just as easily.
Ok, perhaps i missed something in the article. Where are these issues inherent to binary distributions that source distros don't suffer from?The software is compiled against the exact library versions installed on your system, so no subtle incompatabilities arise due to slightly mis-matched binaries. This eliminates a whole class of bugs, and a whole host of problems that can affect stability and reliability.
At install. However, wither you lose this when you upgrade the library, or you have to recompile every single app that uses the library whenever the library changes. Damn, i would hate to upgrade anything X depends on in a system like that, 2 weeks until the upgrade is complete! (assuming my old box doesn't run out of disk space first).
A non-stupidly-written library will be very easy to handle in dependencies (remember, minor version changes indicate backwards-compatible API changes, so app recompile shouldn't be necessary), a stupidly-written one somewhat harder. Either way, a good packaging system can easily handle this modulo human error. In fact, there's less chance for error when a few knowledgeable people handle all the compiling, as opposed to having everyone try it on their own. And when something does go wrong, everyone is likely to have the same problem, so more eyes can look for it.
Upgrades are very easy. In the case of Source Mage they are virtually automatic (you select the package to update and everything is taken care of for you), in the case of Gentoo they are less automatic and require some care, but are nevertheless easier than with any binary distribution I've ever tried (and I've used all the major ones at one time or another),
Somehow, i doubt recompiling everything from source (automated or not) is easier than apt-get dist-upgrade. Definately not easier than tracking unstable (as, based on your comments here, you're effectively doing with either of your favorite source-based distros).
Security is improved in one way: the ease and ability to keep up with security updates. Binary distros are still trying to get this to work smoothly (and mostly not succeeding, or requiring a tradeoff like Debian Stable, in which one must run 2 year-old software to enjoy that level of security). This is really a side effect of the previous point, but is significant enough to deserve sepearate mention.
Well, it would be deserving if it made any sense. You're comparing bleeding-edge source distros with tested-almost-to-the-point-of-absurdity binary distros. Try comparing to Debian unstable instead, it would be somewhat more accurate. You also neglect the fact that the updated code needs to be compiled eventually (since source-based pushes this to the user, they get 'release' ahead a little here), tested for breakage (from your description they just throw the source up without any testing, i hope this is wrong), packaged (a little more time here), and uploaded to the repository (which can take some time, depending on procedures in place).
and with Gentoo the flexibility of having multiple versions of libraries and even runtime apps is very useful.
I have multiple versions of many libraries on my Debian system here. A few apps too (e.g. gcc, autotools). I don't really need multiple versions of most apps. Does Gentoo make everything multi-versonable, even when config file formats (.foorc in $HOME, for example) change incompatibly and other sharing problems like that?
in contrast to binary distros that typically require 3-6 months (worse for some distros. I still recall the Debian developers irate answer to a user's question on when thye could expect X 4.2 support in the experimental version of Debian ("unstable"), to the effect of "leave me alone, it will be months!")
On the other hand, you're leaving out the part about X being a very large, very complex set of programs that needs quite a bit of time to package properly and ensure upgrades will actually function. You're also leaving out the part about the X packagers having to maintain the 4.1 version at the same time, especially since 4.2 cannot be tested well enough in time to make it into frozen. Further, you're leaving out the part where all this is done in the packagers' free time. And the part where the packagers made 'unofficial' packages available much sooner, so anyone who really wanted to could use them and help get things to the point of "doesn't explode on install". And the part where various patches from 4.2 have been backported to 4.1 (and the part where 4.2 contains patches originated with Debian's 4.1).
All in all, you've severly damaged your argument with your poorly reasoned claims.
And here I thought it was because a very large number of people use email clients every day, and because the relavent protocols are well documented and publicly available, while compression algorithms are used by a relatively tiny number of people, and are typically patented, poorly documented if at all available, and require more math than i suspect the average EE knows either to invent.
Besides which, it sounded like your parent was complaining about trying to teach CS to people "only taking this class because it's required" (and who apparently have more clout with the dean than should be allowed).
Unicode was mentioned somewhere in one of the Apocalypses (Apocalypsen?), i think in conjunction with operators. And i do remember seeing that you'll be able to define your own metacharacters (one example defined \j to be a bare linefeed, as opposed to \n being just about any typical eol sequence). The change from . to _ is going to bite me too... And $foo[0] to @foo[0]. But i'll learn eventually.
The GPL does nothing to restrict the use of the software, in fact it explicitly states why it cannot restrict the use. I suspect you're confusing 'use' with 'modification' and/or 'redistribution'.
We can not justify being hypocritical about the following of license agreements by saying that we don't agree with the reasoning behind company x's license.
To clarify slightly, i'll also refer to this quote from your earlier post in this thread that the above quote refers to:
Just because we complain about the BSA's often unethical and occasionally (often?) illegal tactics, and many companies overbearing and possibly invalid licenses (see First Sale and Fair Use, among other things), doesn't mean we support those who're breaking license "agreements". Interesting word choice BTW, with the licenses you're referring to you have no choice but to pretend to agree in order to simply use a product you've legally purchased.[The GPL is] still a license
Remember, the GPL grants rights you wouldn't otherwise have. Proprietary licenses attempt to remove rights you already have, usually without consideration and after the sale.
If they do accept quarters, and there isn't a cash-to-card machine in/near every laundry room (and the debit system isn't such that you can't run out of money), get the quarters anyway! It's not fun to be a few cents short on the card and have to leave your laundry just sitting there while running down the street to the nearest machine in the rain/snow in your "i'm wearing this because all my decent clothes are in the machine" outfit...
Quarters are good for vending machines too, although dollar bills tend to work in those these days.
Happened to me once, stupid roommate didn't realize i was in the shower that morning like i was every morning. After that, i took my keys even when i went to shower.
Ask the RA, front desk, office, whoever has the spare key to open it
Cost $5.
Make a duplicate key just to keep in your wallet/purse.
Duplicating shop said "no can do, that's a security key".
My problem with RedHat isn't that i can't hack it (i have hacked it, actually). The problem is that when it breaks it's more difficult to fix.
Personally, I find RedHat gets in my way whenever i have to use it at work (i co-admin somewhat large number of machines, all RedHat of one version or another). As someone else mentioned, the init.d scripts are extremely annoying with all the sourced files. Linuxconf gets in the way of editing things in /etc by hand, at least it has whenever i've tried. Packages aren't as nice, i still haven't figured out how to make postgresql start on boot without adding the symlink to /etc/rc3.d by hand (fortunately, mysql in a similar setup had an S70 link so i didn't have to worry about picking the proper number). I have no idea what we'll do when we decide to upgrade the boxen still running the older version of RedHat.
Debian, on the other hand, works well for me. Updating packages is easy (i have two machines set up to email me when they detect upgrades are available, so i can't forget). Editing configs isn't as easy as point-and-click in Linuxconf, but it is as easy as vi (works for me, i read the docs anyway to secure things as best i can). Docs are always in /usr/share/doc now, for every single package installed (i've found that some RedHat packages lack any entry in /usr/doc or /usr/share/doc). Upgrading to the latest version is as simple as upgrading a single package.
Anyway, that's my $0.02.
And you do yours. It's your job to support your own arguments, not ours.
BTW, all i can seem to find on that site is "pragmatism" with no real explanation.
The reason it's /usr/lib instead of /lib/usr is similarly simple: if it were /lib/usr, /bin/usr, /sbin/usr, and so on, you'd need a separate partition for each one. But with /usr/lib, /usr/bin, /usr/sbin, and so on you just mount one partition on /usr containing bin, lib, and so on. This makes it much easier to reallocate space: if you suddenly discover you need more space in /bin/usr and you have too much in /lib/usr you have to repartition heavily to transfer the extra to where it's needed, where as /usr/bin and /usr/lib are on the same partition and so automatically share the space.
It's hard to map anything well to the issue at hand. I made that point in there somewhere.
Your example isn't really much better, it's still entirely artificial, and the mapping isn't particularly clear either. In particular, are you trying to map doing violence or being jailed to being redistributed in a closed-source fashion?
Why is Sun allowed to distribute a 'proprietary program' in their own big organisation without opening the code
I don't know. Probably it wasn't strictly intended, and just springs from the funny "a corporation is equivalent a person for legal purposes" system we have here. Go ask RMS, he can tell you.
What is inherently wrong with keeping your game's source closed so that less hacks will be developed (securing it through other means than obfuscation is sometimes impossible)?
If you want to do that, don't use the GPL. It's that simple. The GPL is the wrong tool for that job.
So why would you want to decide for someone else that these things should not be possible with the code you give away?
Because you want people who use your code to give you the opportunity to use their code in return? The model seems to me something like this story, except we can't easily just stop providing 'scratcher' with code with the current methods of giving it away, so we take advantage of copyright law's prohibition of the use and only give the necessary permission as long as the recipient doesn't scratch.
PS2. Gratis comes from latin.
Libre probably does too. French and Spanish are both Romance languages derived from Latin, so it's not surprising they share the words. As for whether the person who first came up with using those words to help clarify 'free' versus 'free' was intending Latin, Spanish, French, or another language, i have no idea.
Can't speak for the last two days, but as of Nov 23, 2001 the 20,000 was still there.
HTH
Reasonable is not "If you do that, we'll change the license to specifically prohibit you. But not until then." That's not particularly nice, and it shows an intention to lie about the openness of your code (because openness of code and level of community support are directly proportional in this community).
Hmmm... reading it again, i get the impression the non-public letter to Marc et al was less diplomatically worded WRT the threatened license change.
Personally, i wish Debian would package it and force Transgaming to change the license for all to see.
If only i would have seen this before my earlier reply in this thread! Very nice comparison.
Although i suspect "is" fits somewhat better than "is rather like", if you limit application of the labels to views on software alone instead of the nature of property in general... Too bad i haven't studied enough politics to determine which is which. I suppose proprietary software advocates are totalitarian? And MS seems to be fascist then, totalitarian with a side of nationalism and racism (against non-MS, of course). Hmmm... someone should write "If software licenses were governments" like "If operating systems were women/cars/guns/etc".
The crucial difference is that the BSD code can be made non-free, where as the GPL code must always be free[1]. Or, to put it another way, the GPL code is not free to lose its freedom, but the BSD code is. When people say "the GPL is more free", they mean it because GPL code cannot be non-free, where as BSD code can be made so. When people say "the BSD license is more free", they mean it because BSD code has the freedom to be made non-free, where as GPL code doesn't have this freedom. They're both right, it just depends on which definition of free you use.
An AC in this thread used an analogy with a man:
True, with that analogy Man #1 is freer. But how about this one? Which man would you consider freer now? Argument by analogy is always tricky, neither of these makes a proper case. "Man #1's decendants can be enslaved, Man #2's cannot. Which family is freer?" might be closer than either[2]. But it still has trouble with anthropomorphism, software can't choose to remain free or to give up its freedom[3].Arandir makes a semantic argument based slightly on French (personally, i've always thought of gratis and libre as Spanish (not that it matters)) and more on 'liberty'. But "absence of external restriction" can mean "external restriction cannot exist" as well as "external restriction does not exist". My dictionary uses "freedom from" instead of "absence of", which makes this distinction even less clear. If you choose 'cannot', then the minor extra restriction on the GPL code makes it more free than the ease of imposing major restriction on the BSD code. It comes back to enslaving children again, Man #1 is free to have slave children, but Man #2's children will always be as free as Man #2 himself.
Hopefully this will shed some light on the situation, or at least convince people to come up with better arguments...
[1] Ignoring the original developer's ability to license it differently, of course.
[2] So Man #2's children can't choose to be slaves either. Some people get off on that sort of thing.
[3] At least not until we get MUCH better at AI...
If they want to prohibit redistribution, they should say so instead of pretending to be quasi-Open Source. Some people will put up with the AFPL but not this more restrictive license they intend to have.
It's the threat and lies that make it dirty.
And threatening to change the license to specifically prohibit them (Debian, in this case) from doing so if they try. So it's "we say you can redistribute, but if you do we'll tell you you can't."
so people don't get the impression that when they try to run new game x with copy protection that it doesn't work with the WineX period
As has been pointed out, a name change was offered. And i assume a warning would have been put in the package's description field. This didn't help, still the threat.
I wish Debian would package it, just to force Transgaming to change their license and make obvious their intentions.
The problem with this setup is that Sprint has an incentive to NOT give accurate usage information! A friend of mine uses this, and several times she's gone over the limit because the website and the '*4' information deal (which costs minutes, IIRC) aren't up to date even though they claim "Current as of $CURRENT_TIME" (once we even saw "Current as of $CURRENT_TIME+5 hours" online (and no, it wasn't a timezone thing)). And then they turn off her phone because of the extra charges, and don't bother to tell her they prorated her minutes for the next month once she got the money to pay them off; of course, they can't be bothered to write the usage apps to take this prorating into account, only the billing apps...
The advantage of flat rates in general is that they're easier to budget for. With electricity it's not so bad, because whatever electricity you use is basically what electricity you want to use, so it's not that likely to change from month to month (but then you get a cold spell when you have electric heat, owch). With Internet access you use bandwidth receiving flashing banner ads, spam, virus probes, etc, etc, etc. all taking bandwidth you'd rather not use.
When the whole pipe is not being utilized, leave it as-is. When the whole pipe is being utilized, start capping. "Bandwidth hogs" get a smaller fraction of the pipe than non-"hogs".
Since it's apparently possible to determine how much bandwidth each customer has used (given that Comcast's proposal is basically metered fees), just assign each customer's traffic a priority based on the amount of bandwidth (possibly adjusted to discount bandwidth used during unsaturated periods) used over an appropriate sliding window. When the pipe is unsaturated, everybody gets their traffic through as normal so you don't piss off your customers for no reason. When the pipe is saturated, the low-priority traffic from the "bandwidth hogs" gets dropped in favor of higher priority packets.
I'm sure this has some flaws (e.g. a new "bandwidth hog" will take some time to rise above the mean), but it still sounds like a better option than either of the two you presented. It doesn't uselessly limit bandwidth when there's plenty to spare, and it prioritizes so-called "normal users" over "bandwidth hogs" when there is a scarcity. Bonus points if you expose some of this data to the customers (/.ers, etc.) who'd want to see their current status.
Try Privoxy, which AFAICT is the same thing that used to be known as ijbswa (which was Stefan Waldherr's version of the original). Works well for me.
Why? I'm reminded of the old saying "Any sufficiently advanced technology is indistinguishable from magic". There's an assumption in there: "sufficiently advanced technology" means "sufficiently advanced beyond the current state of knowledge". You're encouraging students to consider the OS 'magic' by keeping their current state of knowledge low. Some people are fine with this, but some would rather advance their state of knowledge so they can have a better explanation than 'magic' and superstition.
Actually, i feel all students should be encouraged to learn enough about the OS so it's not 'magic', even if they don't go on to become full computer geeks.