They're probably not contributing to any projects because they have no idea how to code. They only know how to make announcements and webpages. They'll probably keep putting up webpages, making announcements, and discussing the "design" of the OS, while they try to look for real programmers to code for them. Meanwhile, the men in the WINE project will keep coding, for the most part with their mouths shut.
Price gouging on compact discs and other recordings. The record labels consistently charge more for compact discs than they do for casettes, even though CD's cost much less to manufacture. The only reason why CD's are more expensive is because when they were first introduced, they cost more to produce than casettes and were thus priced accordingly. What many people don't realize now is that CD's are far, far cheaper to manufacture.
This is a popular and simple minded argument pushed by the napster mob. The truth is that the record company's CD and cassette producing businesses do not exist in some sort of vacuum. The operating costs overlap. Market forces make it easier for them to recover most of those costs on CD sales. Cassette selling is not in itself a viablae business proposition. It is only viable in that the marginal expense of adding it to a CD business is worthwhile.
Unfair treatment of artists. Most musicians that are signed to record labels make pennies on each recording they sell. Doesn't it irritate you that when you spend $14.99 for a CD (or however much it costs in your local currency), that typically 1-5% of that is actually going to the artist you are listening to, while the remainder lines the pockets of corporate executives?
This is an outright lie. The artists probably get more than 1-5%. But the biggest lie is about the rest being "collected by executives". While this line may sound cool to the corporate conspiracy theorists, the truth is that most of the money goes on middlemen and taxes. Markup goes up exponentially with the number of middle men.
Although these services are used for piracy (which we do not condone) they also can be and are used for legitimate purposes
I thought the whole point of these services was piracy ! The napster mob certainly seem very pro-piracy. Napster is a glorified warez site, and the fact that the warez may be downloaded by people who own the software doesn't make it all OK.
Unfoprtunately, this site hasn't provided me with any reason to boycott the RIAA. It's merely convinced me that the boycott-the-RIAA people are the same simple minded, lying greedy f*cks as the napster mob.
I disagree with this. napster is not about attacking the MPAA, it is primarily about looting and freeloading. It's true that the RIAA are trying to load contracts in their direction, but I don't think that this is the reason why we have napster. I think it's just an excuse. The greedy napsterites and the greedy RIAA scum are pointing their fingers at each other and screaming "you're a greedy f*ck". And guess what ? They're both right. ( And when they both say "I am not", they're both wrong. )
They know their distribution mechanism is severly flawed, but it is flawed entirely in their favor.
No -- it's not completely flawed because unlike napster, it does not completely bypass the artist's compensation. Sure, the RIAA are greedy f*cks, but so are the napster mob. Both sides want to take as much as possible and to hell with anyone who gets in their way.
They control (for the most part) the media that influnces what you buy (think radio
Don't know about you, but I suibscribe to member supported radio -- I support alternatives. These stations are not controlled by anyone. ueah, I know, someone has to pay to support them, and the napsterites don't want to pay for anything.
Now yes, I put my music up on places like mp3.com and napster for public exposure. Why? Because no matter how bad I suck, I want to hear other peoples opinions and critiques (sp?).
The fact that you aren't a professional musician doesn't mean that noone else should be.
The RIAA has spent millions, silencing ME an artist, by shutting down one of my distribution channels.
napster was primarily a glorified warez site. The fact that tere was the odd bnit of legit material here and there doesn't justify it.
Miguel claims that a weakness of Unix is in not sharing more code between applications. M$ shares code extensively betwen applications... Lets put this to a poll... which is more stable: Unix or M$ Windows (choose your flavour).
Your logic is just bass-ackward. Are you trying to tell us that code reuse is bad because MS use it and MS make bad OSs ? That's just retarded. Your rant is completely wrong -- reuse does not necessarily mean just reusing the same binaries. There's design reuse, code reuse and system resource reuse. They are all different things. UNIX does use various forms of reuse, however, the "reuse" in UNIX systems is not terribly useful for GUI programming.
Just because Miguel is not a foaming at the mouth anti-MS zealot doesn't mean he "trusts" them -- he simply understands that reuse is a good thing.
Well, code reuse is not unique to OOP. But it's pretty hard to do a great deal of design reuse without inheritence. As for code reuse, it is enabled by shared libraries and generic programming as well as OO.
But if Miguel wanted to help improve the situation, why did he go off developing such a huge software project in C on UNIX?
He didn't. He just developed core APIs in C. If you want to bind other languages to the APIs, you really want the APIs to be written in C ( though it's a PITA to do this )
The answers to these problems are well known. Systems like Smalltalk-80 and the Lisp machine were fully integrated, component based environments where everything talked to each other. And almost any language other than C and C++ is better for component-based development and provides reuse.
Check the languages for which there are GTK bindings. It's quite impressive.
Plus you do to many things in a different and longer way. So it's not 500k lines of Perl vs 500k lines of C++ with more bugs in C++. It's really 50k of Perl (or Smalltalk, or Lisp) with few bugs, vs 500k lines of C++ with many bugs
Forgot to respond to this. This really depends on what you're doing. I doubt you'd need 10x as muych C++ code unless you're writing C in C++. There are some cases wehere perl has a big advantage, but for some things, C++ will not be much longer and it will be cleaner ( eg GUI code ).
With dynamic typing, you might basically test your program every 30 lines coded.
You can do safety checking in C++ too.
In addition in C++ there are many bugs that are related to memory allocation,
The benefits of perl's ref counting drop substantially when you introduce more complex data types.
type casting
Not really a problem in C++. This is more of a C issue. You don't need unsafe casts in C++. Keep in mind that in C++, you do at the very least have to be explicit about your casts.
or other bugs with no equivalent in Perl or a dynamically typed langage.
Dynamic typing provides its own set of risks. The main disadvantage with static typing is inflexibility, but you can partly circumvent this with dynamic binding.
The argument isn't for a better DB interface but how to handle arbitrary data-types. A good reasoning for this is that I might not care how the database was designed. Was it a 32bit int or 64bit ( possibly 32/64 bit date stamp, etc ). Changing the database means changing the Java / C code.
Not at all. There are ways to circumvent strong typing in OO languages. For example, you can have a data type that has a bunch of aggregates ( string, double, int ) and an overloaded constructor that initialises the right aggregate, then an accessor method that returns the right one. It's not that hard to do, in fact this kind of trick comes up a lot when you're accessing any kind of external data.
BTW, your original complaint about Perl's loose typing is also true with Python. For alot of programming chores its a feature not a deficiency.
Python knows the diff between a string and a number, perl treats them as the same. BTW, python also can tell you whether a number is a double or an int ( without resorting to regular expression checks ). Python is dynamically typed, but not typeless.
Also, structures would be nice. It's easy to do using hashes, but it's a pain to type. I'd suggest the dot notation, but it would break concatenation.
THey already have a structures package. I've never tried it though, so I don't know how it works. Perl is good for what it's good at. But it's not good at everything.
... limited GC, yes. But it doesn't make things substantially easier if you start implementing complex data structures. Actually, if anything it makes life harder because you can't "see" what's giong on. BTW, STL has built in hashes. I agree that perl is much better for string processing though.
I think I can say with confidence that C++ has not been adopted by many C programmers due to its complexity (and also due to the huge binaries), and ultimately I think we must presume that C++'s time has come and gone.
Hahaha... I don't think so. What do you think all the C++ programmers were doing before they programmed C ? There has been some migration. C is not going to make C++ obsolete any time soon ( it has no OO for starters ). But then, there are some jobs for which C++ is an overkill, so I don't see C dying soon either ( besides, there's too much C lying around to get rid of. )
Why should they ? Do you need to use both at the same time ? BTW, yes, they really are quite similar in terms of bindings. They're both windows-motif hybrids. They essentially use Windows keybindings and Motif/Unix style selection.
My car won't go because it has badly designed blocks for wheels.
Yeah, well it's not the car's fault for allowing you a choice of wheels !
Why should outline fonts be dependent on a particular file format, anyway?
Because the different formats are fairly deeply different. For example, you simply can not do a lossless type 1 to true type conversion. TrueType to Type1 is also potentially lossy because the hinting is lost.
Other systems manage just fine with a generalized abstraction --
The other systems you speak of tend to use only one format -- True Type.
there's no reason the introduction of a client/server architecture should change that.
The printer ( or the printing system ) needs the outline files ( for example, postscript and PCL printers render fonts by themselves -- from the outlines. ) Conversion is both unnecessary and in a lot of cases, lossy. And the printing system resides on the same machine as the client, not the X server. So this idea of doing everything on the server side is just plain wrong, because you really need fonts on the client as well.
If you want client/server, you still need a way of mapping server fonts to client fonts.
BTW, if the X protocol is truly extensible, it begs the question -- why not just redo the font handling part of X and leave the rest of it. I'd certainly agree that X's font handling could be improved.
I had to choose amongst myriad window managers, each with their own control key and window manipulation conventions.
The problem in these days was not that there were too many -- it was that none of them were very good. If all of them were good, you would have just settled for the default ( which also would have been good ), right ? BTW, things have changed quite a lot since RH5.0.
A Linux GUI needs consistency.
I'd say KDE is pretty consistent. So is GNOME. But that's irrelevant, because X is not a GUI, so badly designed GUIs are not really X's fault.
BTW, I understand where you're coming from -- I also program, but like to wear a "user hat". I find KDE sans themes works just fine for me -- it's bland, sure. That's fine by me -- I'm more interested in working than looking at "cool" backgrounds (-;
For the kind of font handling you're after, the client/server model as it stands just doesn't work. In fact for any decent font model, the client really needs to be able to see all the font files ( for example, what happens when the client wants to print ? ) One way of doing it would be to just render everything client side and completely bypass the existing font server model. This has several obvious advantages, but you also take a performance hit when you try to shove all those rendered pixels down the client-server connection.
You're right and wrong at the same time. X doesn't include the functionality that these apps require, but adding this functionality ( namely, print/display unification ) does not require changing X in any way. It requires getting a decent font management system that maps print display fonts. Again, X is not the problem here. The problem is that there's no standard way to map print and display fonts.
What sucks about X fonts is they've (?) never fixed its shortcomings. If you have StarOffice, CorelDraw, Framemaker and Canvas, you' have 4 additional installed directories of fonts for each app.
The problem they are addressing here is lack of print/display unification, not problems with X itself. These apps still use X for display.
However, that doesn't allow you to ignore the fact that our digestive system is (as best we know) designed to process a diet of about 20% meat and 80% other (plant products, insects, etc.).
If you're referring to the fact that our digestive system isn't a protien factory ( like for example the cows stomach ), then that's correct -- but still, what it means is that the human digestive system was designed to process a diet with a source of complete protien, there's no rule saying that the protien has to come from meat (-;
Yeah, I don't think a small meat intake is that unhealthy, especially if you stick to say lean beef and checken breast ( or if you're generally selective and health conscious about it... )
It's not that I'm unaware of the fact that I don't have a cow's digestive system, it's that the nutrients can be had many different ways ( for example, when you're a baby, you live on milk alone ! )
compare anything from ride the lightning to this post-grunge power ballad crap their releasing, ready-made mtv 4 minute singles, and tell me again how they've just happened to become rich?
THey were already making a lot of money by the time they released puppets.
as though they wouldn't mind the piracy if napster was a not-for-profit. that's ridiculous. they are going after napster not because napster is profiting from privacy, but because napster is allowing people to cut into metallica's pocktbook.
Well I don't see them going after Gnutella. And I didn't see them complaining about their pocketbook. Sorry, you're making this up. Your claim doesn't have any substance.
lots of bands support themselves off of tours. they aren't starving. furthermore, there are lots of people who play music and have day jobs. finally, there are a lot of people who aren't in it for the money at all.
I see, we move to plan (b) -- "it's only the greedy musicians who make money from record sales." Thank you, at least we're admitting that it's OK to take money from the artists. It seems clear that the musicians are considered less important than the napsterites right to freeload, am I right ? IMO, this makes the napsterites the greedy f*cks. Not all the musicians are greedy, but the napsterites, who place their "right to freeload" on a pedestal are in the same territory as the RIAA.
furthermore, there are lots of people who play music and have day jobs
So here it is again -- the idea that musicians shouldn't be paid, because that might interfere with a napsterite's "right to freeload". Again, I think it would be better if the musicians could spend all their time writing great music.
hey're the perfect example of why ruining cd sales as a business won't kill music! s
Why try so hard to justify this ? You don't care about the artist anyway ( especially in this example ) so why don't you just come out and say that your right to freeload comes before everything else like the rest of the napsterite mob ?
f humans evolved to be vegetarians, all their teeth would be molars. This is not the case.
Apparently, the things we evolved from are not vegetarian. However, some of us have moved on since those days (-;
If you are a vegetarian, you probably know that you have to be careful to eat the right things to get all your amino acids.
Bzzzzzt. (a) Milk contains complete protien, (b) there are studies that show that it's extremely hard to become protien deficient anyway, (c) Even a vegan with variety in their diet can get complete protien. You don't need to get all the amino acids in each meal. A nutritious diet requires variety regardless of whether you eat meat.
Still, I can't help but think the world would be a better place if more people at least considered science when making decisions about their lifestyles
I did "consider science", as you can see above. You on the other hand seem resigned to the fact that you're basically a smart ape.
Slashdot Mirror
This is a popular and simple minded argument pushed by the napster mob. The truth is that the record company's CD and cassette producing businesses do not exist in some sort of vacuum. The operating costs overlap. Market forces make it easier for them to recover most of those costs on CD sales. Cassette selling is not in itself a viablae business proposition. It is only viable in that the marginal expense of adding it to a CD business is worthwhile.
Unfair treatment of artists. Most musicians that are signed to record labels make pennies on each recording they sell. Doesn't it irritate you that when you spend $14.99 for a CD (or however much it costs in your local currency), that typically 1-5% of that is actually going to the artist you are listening to, while the remainder lines the pockets of corporate executives?
This is an outright lie. The artists probably get more than 1-5%. But the biggest lie is about the rest being "collected by executives". While this line may sound cool to the corporate conspiracy theorists, the truth is that most of the money goes on middlemen and taxes. Markup goes up exponentially with the number of middle men.
Although these services are used for piracy (which we do not condone) they also can be and are used for legitimate purposes
I thought the whole point of these services was piracy ! The napster mob certainly seem very pro-piracy. Napster is a glorified warez site, and the fact that the warez may be downloaded by people who own the software doesn't make it all OK.
Unfoprtunately, this site hasn't provided me with any reason to boycott the RIAA. It's merely convinced me that the boycott-the-RIAA people are the same simple minded, lying greedy f*cks as the napster mob.
I disagree with this. napster is not about attacking the MPAA, it is primarily about looting and freeloading. It's true that the RIAA are trying to load contracts in their direction, but I don't think that this is the reason why we have napster. I think it's just an excuse. The greedy napsterites and the greedy RIAA scum are pointing their fingers at each other and screaming "you're a greedy f*ck". And guess what ? They're both right. ( And when they both say "I am not", they're both wrong. )
No -- it's not completely flawed because unlike napster, it does not completely bypass the artist's compensation. Sure, the RIAA are greedy f*cks, but so are the napster mob. Both sides want to take as much as possible and to hell with anyone who gets in their way.
They control (for the most part) the media that influnces what you buy (think radio
Don't know about you, but I suibscribe to member supported radio -- I support alternatives. These stations are not controlled by anyone. ueah, I know, someone has to pay to support them, and the napsterites don't want to pay for anything.
Now yes, I put my music up on places like mp3.com and napster for public exposure. Why? Because no matter how bad I suck, I want to hear other peoples opinions and critiques (sp?).
The fact that you aren't a professional musician doesn't mean that noone else should be.
The RIAA has spent millions, silencing ME an artist, by shutting down one of my distribution channels.
napster was primarily a glorified warez site. The fact that tere was the odd bnit of legit material here and there doesn't justify it.
Put a piece of music in front of him.
Your logic is just bass-ackward. Are you trying to tell us that code reuse is bad because MS use it and MS make bad OSs ? That's just retarded. Your rant is completely wrong -- reuse does not necessarily mean just reusing the same binaries. There's design reuse, code reuse and system resource reuse. They are all different things. UNIX does use various forms of reuse, however, the "reuse" in UNIX systems is not terribly useful for GUI programming.
Just because Miguel is not a foaming at the mouth anti-MS zealot doesn't mean he "trusts" them -- he simply understands that reuse is a good thing.
He didn't. He just developed core APIs in C. If you want to bind other languages to the APIs, you really want the APIs to be written in C ( though it's a PITA to do this )
The answers to these problems are well known. Systems like Smalltalk-80 and the Lisp machine were fully integrated, component based environments where everything talked to each other. And almost any language other than C and C++ is better for component-based development and provides reuse.
Check the languages for which there are GTK bindings. It's quite impressive.
Forgot to respond to this. This really depends on what you're doing. I doubt you'd need 10x as muych C++ code unless you're writing C in C++. There are some cases wehere perl has a big advantage, but for some things, C++ will not be much longer and it will be cleaner ( eg GUI code ).
You can do safety checking in C++ too.
In addition in C++ there are many bugs that are related to memory allocation,
The benefits of perl's ref counting drop substantially when you introduce more complex data types.
type casting
Not really a problem in C++. This is more of a C issue. You don't need unsafe casts in C++. Keep in mind that in C++, you do at the very least have to be explicit about your casts.
or other bugs with no equivalent in Perl or a dynamically typed langage.
Dynamic typing provides its own set of risks. The main disadvantage with static typing is inflexibility, but you can partly circumvent this with dynamic binding.
Not at all. There are ways to circumvent strong typing in OO languages. For example, you can have a data type that has a bunch of aggregates ( string, double, int ) and an overloaded constructor that initialises the right aggregate, then an accessor method that returns the right one. It's not that hard to do, in fact this kind of trick comes up a lot when you're accessing any kind of external data.
Python knows the diff between a string and a number, perl treats them as the same. BTW, python also can tell you whether a number is a double or an int ( without resorting to regular expression checks ). Python is dynamically typed, but not typeless.
THey already have a structures package. I've never tried it though, so I don't know how it works. Perl is good for what it's good at. But it's not good at everything.
Speaking of moronic logic ... you have your logical implications back to front. Since many cats drink milk, anyone who drinks milk is a cat ...
I think I can say with confidence that C++ has not been adopted by many C programmers due to its complexity (and also due to the huge binaries), and ultimately I think we must presume that C++'s time has come and gone.
Hahaha ... I don't think so. What do you think all the C++ programmers were doing before they programmed C ? There has been some migration. C is not going to make C++ obsolete any time soon ( it has no OO for starters ). But then, there are some jobs for which C++ is an overkill, so I don't see C dying soon either ( besides, there's too much C lying around to get rid of. )
Why should they ? Do you need to use both at the same time ? BTW, yes, they really are quite similar in terms of bindings. They're both windows-motif hybrids. They essentially use Windows keybindings and Motif/Unix style selection.
My car won't go because it has badly designed blocks for wheels.
Yeah, well it's not the car's fault for allowing you a choice of wheels !
Because the different formats are fairly deeply different. For example, you simply can not do a lossless type 1 to true type conversion. TrueType to Type1 is also potentially lossy because the hinting is lost.
Other systems manage just fine with a generalized abstraction --
The other systems you speak of tend to use only one format -- True Type.
there's no reason the introduction of a client/server architecture should change that.
The printer ( or the printing system ) needs the outline files ( for example, postscript and PCL printers render fonts by themselves -- from the outlines. ) Conversion is both unnecessary and in a lot of cases, lossy. And the printing system resides on the same machine as the client, not the X server. So this idea of doing everything on the server side is just plain wrong, because you really need fonts on the client as well.
If you want client/server, you still need a way of mapping server fonts to client fonts.
BTW, if the X protocol is truly extensible, it begs the question -- why not just redo the font handling part of X and leave the rest of it. I'd certainly agree that X's font handling could be improved.
The problem in these days was not that there were too many -- it was that none of them were very good. If all of them were good, you would have just settled for the default ( which also would have been good ), right ? BTW, things have changed quite a lot since RH5.0.
A Linux GUI needs consistency.
I'd say KDE is pretty consistent. So is GNOME. But that's irrelevant, because X is not a GUI, so badly designed GUIs are not really X's fault.
BTW, I understand where you're coming from -- I also program, but like to wear a "user hat". I find KDE sans themes works just fine for me -- it's bland, sure. That's fine by me -- I'm more interested in working than looking at "cool" backgrounds (-;
The problem they are addressing here is lack of print/display unification, not problems with X itself. These apps still use X for display.
If you're referring to the fact that our digestive system isn't a protien factory ( like for example the cows stomach ), then that's correct -- but still, what it means is that the human digestive system was designed to process a diet with a source of complete protien, there's no rule saying that the protien has to come from meat (-;
Yeah, I don't think a small meat intake is that unhealthy, especially if you stick to say lean beef and checken breast ( or if you're generally selective and health conscious about it ... )
It's not that I'm unaware of the fact that I don't have a cow's digestive system, it's that the nutrients can be had many different ways ( for example, when you're a baby, you live on milk alone ! )
THey were already making a lot of money by the time they released puppets.
as though they wouldn't mind the piracy if napster was a not-for-profit. that's ridiculous. they are going after napster not because napster is profiting from privacy, but because napster is allowing people to cut into metallica's pocktbook.
Well I don't see them going after Gnutella. And I didn't see them complaining about their pocketbook. Sorry, you're making this up. Your claim doesn't have any substance.
lots of bands support themselves off of tours. they aren't starving. furthermore, there are lots of people who play music and have day jobs. finally, there are a lot of people who aren't in it for the money at all.
I see, we move to plan (b) -- "it's only the greedy musicians who make money from record sales." Thank you, at least we're admitting that it's OK to take money from the artists. It seems clear that the musicians are considered less important than the napsterites right to freeload, am I right ? IMO, this makes the napsterites the greedy f*cks. Not all the musicians are greedy, but the napsterites, who place their "right to freeload" on a pedestal are in the same territory as the RIAA.
furthermore, there are lots of people who play music and have day jobs
So here it is again -- the idea that musicians shouldn't be paid, because that might interfere with a napsterite's "right to freeload". Again, I think it would be better if the musicians could spend all their time writing great music.
hey're the perfect example of why ruining cd sales as a business won't kill music! s
Why try so hard to justify this ? You don't care about the artist anyway ( especially in this example ) so why don't you just come out and say that your right to freeload comes before everything else like the rest of the napsterite mob ?
Apparently, the things we evolved from are not vegetarian. However, some of us have moved on since those days (-;
If you are a vegetarian, you probably know that you have to be careful to eat the right things to get all your amino acids.
Bzzzzzt. (a) Milk contains complete protien, (b) there are studies that show that it's extremely hard to become protien deficient anyway, (c) Even a vegan with variety in their diet can get complete protien. You don't need to get all the amino acids in each meal. A nutritious diet requires variety regardless of whether you eat meat.
Still, I can't help but think the world would be a better place if more people at least considered science when making decisions about their lifestyles
I did "consider science", as you can see above. You on the other hand seem resigned to the fact that you're basically a smart ape.