And the memory leaks are ridiculous, even as system with lots of Ram will be brought to its knees by FF given enough time.
Except IE7 does "leak" memory like sieve, (it's hard to tell exactly what it's doing) at least in comparison to Firefox.
Consider the following link. It is by a well-known Mozilla developer, so while he may be biased you can be sure that a result that cannot be reproduced would set the tubes on fire some time ago.
I think a lot of the posts that suggest that the right solution is talking to the roommate and potentially some client settings are wrongheaded.
Most people don't care if their P2P download is slowed down a little from HTTP traffic (which is practically in the noise by comparison most of the time, really). In fact, some of those same people would prefer *their* web browsing sessions remain fast while torrenting. The only reason to go for client-side bandwidth throttling or scheduling is because the traffic shaping options can take more expertise and (depending on implementation) may not work ideally -- it is often possible to (sometimes accidentally) abuse many QoS heuristics by, say, spawning a lot of connections.
Traffic shaping (in this case, if effective) will allow you to achieve greater link utilization (they can use 100% of the link when nobody is browsing) and absolve the issue of how one resolves multiple users on the same network wanting to make use of "low-priority" bandwidth. It simply makes life easier, should you be able to set it up.
In any case, the *WRTs (DD-WRT seems to be the easiest) seem to work okay, of course, I'd be interested to hear about other options....
In my recollection, lots of Linus' complaints were dressed in GPL3. GPL3 has turned into GPL2 with patent disarmament (and thus making it compatible with Apache2, whereas GPL2 is NOT compatible with Apache2) and some extra fuzz attached to make sure that you receive keys to hardware to ensure you can change and distribute modified source.
In particular, the DRM fuzz didn't make it.
It seems the reason for not migrating tends to be 1) logistics and 2) unperceived need.
Here are his comments in Git's COPYING file:
Note that the only valid version of the GPL as far as this project
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
HOWEVER, in order to allow a migration to GPLv3 if that seems like
a good idea, I also ask that people involved with the project make
their preferences known. In particular, if you trust me to make that
decision, you might note so in your copyright message, ie something
like
This file is licensed under the GPL v2, or a later version
at the discretion of Linus.
might avoid issues. But we can also just decide to synchronize and
contact all copyright holders on record if/when the occasion arises.
Linus Torvalds
Of course, you can also reference the ELER strip, which also represents the general ambivalence on the matter:
> I am 23 and I am making key policy decisions for the directors of engineering and marketing. They make 4X what I do, yet I am making the big calls....
Pessimistically speaking, this is called setting yourself up to become a scapegoat, if this is really true. Which begs the following question: if you are really the one that's going to be held accountable, why aren't you getting the pay?
That's one thing I learned when I saw what goes on in management, especially a few chains higher up. Deflection of personal accountability -- not results or effectiveness -- motivate decisions. It's much easier to blame (and take credit for the accomplishments of) a flunkie who was operating outside their official capacity and is not embedded deep inside the company's org chart. (leaf nodes are easier to snip)
...Actually, if you define "The US" as "The World" then you might be right. But executive compensation *in the US* is positively insane compared to all other countries that are ostensibly our peers.
Fooling yourself into thinking this is a rational and efficient free market reminiscent of the one described by Smith is a naive and charming fairy tale, as well as an impressive feat of self delusion. The real problem is that this not a free market, but mostly one of good ol' boys clubs and cronies who also have the influence and power to rewrite the rules of the game in their favor.
> The security linux enjoys is because it is 1% market share, so bad guys don't care about it.
This is probably true when it comes to malware targeting grandma, (note: you don't need a root exploit to do plenty of bad things, like install a keylogger on a user's session; IMO things like browsers should one day be relegated to another user as well) but you don't you think that people would be interested in breaking sendmail or BIND and the overwhelmingly UNIX (and increasingly GNU/Linux) systems that they run on? (They have in the past, many times in fact...)
I think this position understates the incentives to attack Linux, because, quite frankly, virtually everything actually important infrastructure-wise runs on a UNIX-alike nowadays (VMS holdouts withstanding), and now it seems clear that with the possible exception of Solaris that all UNIX-alikes except Linux are in their death throes.
> There are flaws in both open source and closed code, but I would say that closed code is better for security.
I disagree. With closed source there is substantially less research and review that goes on. Important security bugs that are thought to not be "in the wild" can be swept under the rug indefinitely because they don't jive with business goals of the owning company. In the case of open source development any agent with an axe to grind (and oftentimes clients to reassure) can make it their priority to get the damn thing fixed.
I think an axiom people have when they hold security-by-obscurity as a credible advantage is a defeatist regarding the nature of bugs: one *can* write a nearly-correct code; see qmail, TeX, dovecot, djbdns, and OpenSSL. It just takes time, effort, and sound engineering (which may include the limitation of scope, something that is hard to do in product-oriented firms). Linux 2.4 may be reaching this point; that's probably why NASA is considering deploying it on things that are actually important.
My recollection is that Zimbra has some very funky goings-ons in their licensing, and I'm not sure if "Freedom to Fork" is preserved in a reasonable way. (A license that forces derivatives to show their trademarked logo?) Therefore, I have never considered deploying Zimbra on the principle that in event of Zimbra's failure that a knowledge-vacuum would cause other firms to pick up the product.
Plus many of the modules that makes Zimbra actually useful are closed source.
For now I'd rather deploy Citadel ( http://www.citadel.org/ ) w/GroupDAV ( http://www.groupdav.org/ ). In particular its speed, turnkey-style administration, and replication options (thanks to BerkeleyDB) make it pretty attractive on the whole.
You don't understand patents. Patents are a monopoly on an idea. It doesn't matter if you prove that you completely independently derived the idea or not. You just move from "willful infringement" (IIRC: triple damages?) to "infringement."
That's why they're so insidious and are the strongest form of protection among all granted imaginary property.
Since when did "easier to read" mean "more bulletproof?" It works most often in software, but nothing is so strange as the law.
Even though the terms of the MS licenses seem reasonable to me, the layman, I would prefer to go with something that has been seen fit by the courts (GPL2) and is in another revision (GPL3, although, of course, there's the possibility of bugs), or one that has tons of source under it (Apache 2) contributed by a company with one of the most feared legal teams of these times (IBM) putting it under a microscope.
And unlike Microsoft IBM has a vested interest in Free Software...with it they gather a lot of money.
Not to nit-pick (okay, well, only a little) this 300 bytes thing floating around is in error; the correct figure is 318 machine words, as seen at the erlang efficiency guide. Still a pittance, but quite a bit larger than 300 bytes on most architectures.
Actually they didn't like it (and won the suit) largely because Arthur Anderson had its own competing consulting practice -- effectively competing with the Anderson Consulting arm. This was found to be a breach of agreement and was how the divorce was finally settled. Wikipedia has (had?) all this information.
It was a fortuitous breaking off, too -- not long afterwards Anderson Consulting changed its name to Accenture did Arthur Anderson implode due to Enron.
I agree. I work in Palo Alto right now, and there is no want for jobs...everyone I know has been easily been hired, and competition for the hire of software engineers seems pretty fierce.
That wasn't the point, as I read it. The point is that there may be a strong incentive to make players that don't support MP3 because it's encumbered and the owners doing the encumbering seem willing to exercise the ownership of their patent. In other words, there may be a shift to non-mp3 formats (AAC or say, ogg) for more players, and possible waning of MP3 domination due to incompatibility on players that don't support MP3 to keep cost down.
Sometimes, however, it is a lot faster to go through the government -- take the space program, for example, or the human genome project. Both were huge upfront investments with no obvious beneficial foreseeable outcome other than the invention of many technologies and seeding new types of research and technology. It is true that by the standards of modern techniques that both are quaint in their approaches, but the massive amounts of money being pumped into (what were at the time) new technologies and techniques surely helped a great deal.
I do understand that point and I do use QoS on my own connection to prioritize SSH packets (need low latency) over HTTP/Bittorrent traffic. I guess my point though is that the ISPs should have enough capacity to provide low latancy (i.e: there shouldn't even be a queue) delivery to every packet.
I assert this this is incredibly unrealistic, depending on the definition of "low." this is about as ludicrous as "let's do away with that silly hard drive/memory/cache thing (eg, the memory hierarchy) and 'just' make a CPU with lots and lots of registers. Gigabytes worth, in fact! It'll be awesome!"
Let's play out your scenario. ISPs have tons of bandwidth, everyone can exchange packets with 100ms delay...well, we could do that...if they capped your connection to 10k/s. Problem solved, right? Then everyone would be happy?
The point is that increased throughput (eg, 6mb/s) is dependent on bandwidth that could be in use, but isn't. If we just raised 10kb/s to 6mb/s and had 100ms for everyone, we may as well have had 30mb/s.
This may work in an ideal world, but the fact is that different applications do have different needs, and to make the Internet useful for more things it is necessary to have different levels of service -- and I don't mean company A paying B for higher priority -- I mean apps VoIP, which requires moderate bandwidth but also low latency, for example, should get a higher priority than your bittorrent packet, which can build in in a queue before being unloaded to you after some VoIP is done. Similarly, Bittorrent shouldn't be throttled per se, but just relegated further back in the queue because generally one doesn't care about latency in the system, "just" throughput.
A sensible approach to make you happy (maybe) would be to limit the amount of bandwidth at each QoS level defined. If you want to burn your 500mb/month of highest QoS on bittorrent then so be it. Make the lowest tier of QoS truly unlimited. or some scheme like that.
Also, even current/production-ish processes for "making" biodiesel require a lot less energy than ethanol, as well as being simpler. The main problem with diesel is the higher particulate emissions (among a few others) as a result of the high compression used in the engines. These (non-CO2) emissions is why the US uses gasoline. The Europeans -- unlike the US -- were willing to compromise (as well as weigh CO2 as an emission) and invested a lot in diesel engines and high-purity diesel fuel, which have about 20%-30% better mileage and better torque than gasoline...in use all over Europe, today.
As an aside: I think this mentality is also what allowed much of Europe to convert to fission power. One of the problems -- in my humble opinion -- is that the factions in the US that wrangle over environmental policy (unfettered business freedom, ecological scaremongers and nuts) don't leave any room for incremental improvement. Everyone is looking for the silver bullet instead of going with what we have to try and make that 1%, 5%, 10%, or even 20% difference in the meantime, thinking (I think maliciously) that an incremental solution is going to somehow fundamentally prevent us from finding or using that silver bullet should we find one.
Someone has tried this before...Pervasive Software.
They failed, but not for the reason you might expect:
What have we learned? While we always knew that PostgreSQL is a solid product with advanced database capabilities and that it has a very real opportunity to shake up the high-end database market, we underestimated the high level of quality support and expertise already available within the PostgreSQL community. In this environment, we found that the opportunity for Pervasive Software to meaningfully increase adoption of PostgreSQL by providing an alternative source for support and services was quite limited. Accordingly, we have made the decision today to substantially curtail our focus on our PostgreSQL initiative.
Berkeley uses a bunch of Sun Rays in the computer science lab. They've worked well, from what I could tell. You should contact inst AT eecs.berkeley.edu if you want to hear a story from the administrator side (if they are nice enough to respond to such a non-standard query)
The system has multiple machines of mixed architecture hooked up to a file server via NFS and has probably on the order of 40+ Sun Rays.
Slashdot Mirror
And the memory leaks are ridiculous, even as system with lots of Ram will be brought to its knees by FF given enough time.
Except IE7 does "leak" memory like sieve, (it's hard to tell exactly what it's doing) at least in comparison to Firefox.
Consider the following link. It is by a well-known Mozilla developer, so while he may be biased you can be sure that a result that cannot be reproduced would set the tubes on fire some time ago.
http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/
I'm not saying that Firefox is the leanest application ever, but some of the charges against it here are incredibly overblown and of dubious veracity.
I think a lot of the posts that suggest that the right solution is talking to the roommate and potentially some client settings are wrongheaded.
Most people don't care if their P2P download is slowed down a little from HTTP traffic (which is practically in the noise by comparison most of the time, really). In fact, some of those same people would prefer *their* web browsing sessions remain fast while torrenting. The only reason to go for client-side bandwidth throttling or scheduling is because the traffic shaping options can take more expertise and (depending on implementation) may not work ideally -- it is often possible to (sometimes accidentally) abuse many QoS heuristics by, say, spawning a lot of connections.
Traffic shaping (in this case, if effective) will allow you to achieve greater link utilization (they can use 100% of the link when nobody is browsing) and absolve the issue of how one resolves multiple users on the same network wanting to make use of "low-priority" bandwidth. It simply makes life easier, should you be able to set it up.
In any case, the *WRTs (DD-WRT seems to be the easiest) seem to work okay, of course, I'd be interested to hear about other options....
In my recollection, lots of Linus' complaints were dressed in GPL3. GPL3 has turned into GPL2 with patent disarmament (and thus making it compatible with Apache2, whereas GPL2 is NOT compatible with Apache2) and some extra fuzz attached to make sure that you receive keys to hardware to ensure you can change and distribute modified source.
In particular, the DRM fuzz didn't make it.
It seems the reason for not migrating tends to be 1) logistics and 2) unperceived need.
Here are his comments in Git's COPYING file:
Note that the only valid version of the GPL as far as this project
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.
HOWEVER, in order to allow a migration to GPLv3 if that seems like
a good idea, I also ask that people involved with the project make
their preferences known. In particular, if you trust me to make that
decision, you might note so in your copyright message, ie something
like
This file is licensed under the GPL v2, or a later version
at the discretion of Linus.
might avoid issues. But we can also just decide to synchronize and
contact all copyright holders on record if/when the occasion arises.
Linus Torvalds
Of course, you can also reference the ELER strip, which also represents the general ambivalence on the matter:
http://geekz.co.uk/lovesraymond/archive/sandals-not-flip-flops
> I am 23 and I am making key policy decisions for the directors of engineering and marketing. They make 4X what I do, yet I am making the big calls....
Pessimistically speaking, this is called setting yourself up to become a scapegoat, if this is really true. Which begs the following question: if you are really the one that's going to be held accountable, why aren't you getting the pay?
That's one thing I learned when I saw what goes on in management, especially a few chains higher up. Deflection of personal accountability -- not results or effectiveness -- motivate decisions. It's much easier to blame (and take credit for the accomplishments of) a flunkie who was operating outside their official capacity and is not embedded deep inside the company's org chart. (leaf nodes are easier to snip)
...Actually, if you define "The US" as "The World" then you might be right. But executive compensation *in the US* is positively insane compared to all other countries that are ostensibly our peers.
http://www.motherjones.com/news/exhibit/2006/05/perks_of_privilege.html
Fooling yourself into thinking this is a rational and efficient free market reminiscent of the one described by Smith is a naive and charming fairy tale, as well as an impressive feat of self delusion. The real problem is that this not a free market, but mostly one of good ol' boys clubs and cronies who also have the influence and power to rewrite the rules of the game in their favor.
As long as we're lobbing anecdotal evidence, I do seem to recall some angst about GenX's apathy.
Consider the wikipedia article (since we're probably talking about the US, I have provided a link to that section for you)
http://en.wikipedia.org/wiki/Generation_x#Generation_X_in_the_United_States
Older generations will complain about younger generations. There may be some interesting trends, but it's mostly just whining. Get off your horse.
Hope they are careful about what they're buying...
I suggest reading "A Security Market for Lemons" by Bruce Schneier. (aka the author of Blowfish)
http://www.schneier.com/blog/archives/2007/04/a_security_mark.html
> The security linux enjoys is because it is 1% market share, so bad guys don't care about it.
This is probably true when it comes to malware targeting grandma, (note: you don't need a root exploit to do plenty of bad things, like install a keylogger on a user's session; IMO things like browsers should one day be relegated to another user as well) but you don't you think that people would be interested in breaking sendmail or BIND and the overwhelmingly UNIX (and increasingly GNU/Linux) systems that they run on? (They have in the past, many times in fact...)
I think this position understates the incentives to attack Linux, because, quite frankly, virtually everything actually important infrastructure-wise runs on a UNIX-alike nowadays (VMS holdouts withstanding), and now it seems clear that with the possible exception of Solaris that all UNIX-alikes except Linux are in their death throes.
> There are flaws in both open source and closed code, but I would say that closed code is better for security.
I disagree. With closed source there is substantially less research and review that goes on. Important security bugs that are thought to not be "in the wild" can be swept under the rug indefinitely because they don't jive with business goals of the owning company. In the case of open source development any agent with an axe to grind (and oftentimes clients to reassure) can make it their priority to get the damn thing fixed.
I think an axiom people have when they hold security-by-obscurity as a credible advantage is a defeatist regarding the nature of bugs: one *can* write a nearly-correct code; see qmail, TeX, dovecot, djbdns, and OpenSSL. It just takes time, effort, and sound engineering (which may include the limitation of scope, something that is hard to do in product-oriented firms). Linux 2.4 may be reaching this point; that's probably why NASA is considering deploying it on things that are actually important.
My recollection is that Zimbra has some very funky goings-ons in their licensing, and I'm not sure if "Freedom to Fork" is preserved in a reasonable way. (A license that forces derivatives to show their trademarked logo?) Therefore, I have never considered deploying Zimbra on the principle that in event of Zimbra's failure that a knowledge-vacuum would cause other firms to pick up the product.
Plus many of the modules that makes Zimbra actually useful are closed source.
For now I'd rather deploy Citadel ( http://www.citadel.org/ ) w/GroupDAV ( http://www.groupdav.org/ ). In particular its speed, turnkey-style administration, and replication options (thanks to BerkeleyDB) make it pretty attractive on the whole.
For more information, see
http://www.rants.org/2007/06/26/when-is-open-source-not-open-source/
You don't understand patents. Patents are a monopoly on an idea. It doesn't matter if you prove that you completely independently derived the idea or not. You just move from "willful infringement" (IIRC: triple damages?) to "infringement."
That's why they're so insidious and are the strongest form of protection among all granted imaginary property.
Since when did "easier to read" mean "more bulletproof?" It works most often in software, but nothing is so strange as the law.
Even though the terms of the MS licenses seem reasonable to me, the layman, I would prefer to go with something that has been seen fit by the courts (GPL2) and is in another revision (GPL3, although, of course, there's the possibility of bugs), or one that has tons of source under it (Apache 2) contributed by a company with one of the most feared legal teams of these times (IBM) putting it under a microscope.
And unlike Microsoft IBM has a vested interest in Free Software...with it they gather a lot of money.
Consider Cube and Sauerbraten. These are not only amusing games but also quite pretty engines as well.
They also have some pretty interesting and ahead-of-their-time collaborative, live level editing support.
Not to nit-pick (okay, well, only a little) this 300 bytes thing floating around is in error; the correct figure is 318 machine words, as seen at the erlang efficiency guide. Still a pittance, but quite a bit larger than 300 bytes on most architectures.
So would the guy with the sign seem to suggest, or the Phelps clan.
Actually they didn't like it (and won the suit) largely because Arthur Anderson had its own competing consulting practice -- effectively competing with the Anderson Consulting arm. This was found to be a breach of agreement and was how the divorce was finally settled. Wikipedia has (had?) all this information.
It was a fortuitous breaking off, too -- not long afterwards Anderson Consulting changed its name to Accenture did Arthur Anderson implode due to Enron.
I agree. I work in Palo Alto right now, and there is no want for jobs...everyone I know has been easily been hired, and competition for the hire of software engineers seems pretty fierce.
That wasn't the point, as I read it. The point is that there may be a strong incentive to make players that don't support MP3 because it's encumbered and the owners doing the encumbering seem willing to exercise the ownership of their patent. In other words, there may be a shift to non-mp3 formats (AAC or say, ogg) for more players, and possible waning of MP3 domination due to incompatibility on players that don't support MP3 to keep cost down.
Because GNU is not Linux. Linux is a kernel. Because Solaris has some good features, like ZFS, that Linux cannot always match.
What was wrong with Solaris? Besides the weird userland tools -- eg, not GNU.
Check out http://www.gnusolaris.org/ , a GNU/Solaris aimed at addressing those who would like a GNU userland.
Actually, I'd really like if Dell supported an OpenSolaris option as well -- it's a fine piece of work.
Sometimes, however, it is a lot faster to go through the government -- take the space program, for example, or the human genome project. Both were huge upfront investments with no obvious beneficial foreseeable outcome other than the invention of many technologies and seeding new types of research and technology. It is true that by the standards of modern techniques that both are quaint in their approaches, but the massive amounts of money being pumped into (what were at the time) new technologies and techniques surely helped a great deal.
Let's play out your scenario. ISPs have tons of bandwidth, everyone can exchange packets with 100ms delay...well, we could do that...if they capped your connection to 10k/s. Problem solved, right? Then everyone would be happy?
The point is that increased throughput (eg, 6mb/s) is dependent on bandwidth that could be in use, but isn't. If we just raised 10kb/s to 6mb/s and had 100ms for everyone, we may as well have had 30mb/s.
The point is coexistence and maximum utilization.
This may work in an ideal world, but the fact is that different applications do have different needs, and to make the Internet useful for more things it is necessary to have different levels of service -- and I don't mean company A paying B for higher priority -- I mean apps VoIP, which requires moderate bandwidth but also low latency, for example, should get a higher priority than your bittorrent packet, which can build in in a queue before being unloaded to you after some VoIP is done. Similarly, Bittorrent shouldn't be throttled per se, but just relegated further back in the queue because generally one doesn't care about latency in the system, "just" throughput.
A sensible approach to make you happy (maybe) would be to limit the amount of bandwidth at each QoS level defined. If you want to burn your 500mb/month of highest QoS on bittorrent then so be it. Make the lowest tier of QoS truly unlimited. or some scheme like that.
Also, even current/production-ish processes for "making" biodiesel require a lot less energy than ethanol, as well as being simpler. The main problem with diesel is the higher particulate emissions (among a few others) as a result of the high compression used in the engines. These (non-CO2) emissions is why the US uses gasoline. The Europeans -- unlike the US -- were willing to compromise (as well as weigh CO2 as an emission) and invested a lot in diesel engines and high-purity diesel fuel, which have about 20%-30% better mileage and better torque than gasoline...in use all over Europe, today.
As an aside:
I think this mentality is also what allowed much of Europe to convert to fission power. One of the problems -- in my humble opinion -- is that the factions in the US that wrangle over environmental policy (unfettered business freedom, ecological scaremongers and nuts) don't leave any room for incremental improvement. Everyone is looking for the silver bullet instead of going with what we have to try and make that 1%, 5%, 10%, or even 20% difference in the meantime, thinking (I think maliciously) that an incremental solution is going to somehow fundamentally prevent us from finding or using that silver bullet should we find one.
They failed, but not for the reason you might expect:
Berkeley uses a bunch of Sun Rays in the computer science lab. They've worked well, from what I could tell. You should contact inst AT eecs.berkeley.edu if you want to hear a story from the administrator side (if they are nice enough to respond to such a non-standard query)
The system has multiple machines of mixed architecture hooked up to a file server via NFS and has probably on the order of 40+ Sun Rays.