Moshe Goldfarb wrote:

> On Sun, 06 Apr 2008 16:28:12 +0200, Hadron wrote:

>

>> Moshe Goldfarb <brick.n.straw@gmail.com> writes:

>>

>>> "Somewhere in California - At 8:30 PDT with the release of Snoopy Linux 2.1

>>> and Goober Linux 1.0, the number of Linux distributions finally surpassed

>>> the number of actual Linux users."

>>>

>>>

>>> "We've been expecting it for some time," Merrill Lynch technology analyst

>>> Tom Shayes said, "but this is a little sooner than most expected. We've

>>> seen explosive growth in the number of Linux distributions, in fact my

>>> nephew just put out LittleLinux Chart Tommy Linux 1.1 last week."

>> Kewl! Does it "rock" and "work really well"? Does it meet your "needs"?

>>

>>> http://www.bbspot.com/News/2000/4/linux_distros.html

>> LOL. At least some people get it.

>

> Hahaha!

>

> Linux and the Linux community is a ball of confusion, a clusterfsck that is

> fragmented, filled with hateful, arrogant people and which has no direction

> or leadership.

>

> Everyone is free to do their own thing, which is fine if you wish to remain

> like the above.

 

So, you too prefer a dictatorship. Figures.

> However if Linux ever has a hope of challenging Microsoft for the desktop

> it is going to have to reign in the confusion and become organized, even if

> it is loosely organized at first.

 

How can a kernel want anything? Or do you mean the "Linux Community".

And, if so, how do you expect a community to to act in the same way a

single corporation can?

>

> They can start with why the need for so many different package managers.

 

That has already been answered. Different groups saw different needs.

Different managers arose.

>

> Then they can move to why they need 15 different sound systems.

 

Name all 15.

>

> Why so many different native file systems.

 

Because each has different strengths.

>

> Why different startup and shutdown scripts doing different things at the

> various levels in the boot/shutdown process.

>

> Why so many different, and duplicate tools to mange the distribution.

>

> An example is Samba.

>

> There has to be a dozen or more tools to set up Samba and for anyone who

> has attempted to set up Samba they know how confusing it is.

> The net is clogged with How-To's on this topic and it is surely one of the

> most frequently asked questions in Linux help groups.

 

Apparently "the community" doesn't agree on which Samba management tool

is the best. Why don't you just tell them, and then you can enforce your

decision.

>

>

> They should take the best of the best, meld it into ONE TOTALLY WORKING

> distribution and then put all the other stuff in a repository free to

> download if anyone wants to.

 

Who is "they". Who gets to decide what s "best"?

> This way they can take all of these people who are working on their own

> distributions and pool their resources and talent to create a Linux that

> actually works instead of the slopware (mostly) that is what desktop Linux

> currently is.

 

How are you going to force those developers, whose disros you killed, to

work on "someone else's" distro?

>

> But the Linux community won't allow this because they cry "we want

> choice!!"

>

> Evidently they want inferior slopware programs as well.

>

 

Why do you use slopware?

--

Rick

ray wrote:

> Must be somewhat similar to vista stats - 150 million units sold 50 in

> use.

 

And 100 million people still _trying_ to get in "in use"

 

--

Wes Groleau

 

http://Ideas.Lang-Learn.us/

For lovers of language and learning

Moshe Goldfarb wrote:

> On Sun, 06 Apr 2008 12:48:21 -0400, caver1 wrote:

>

>> Moshe Goldfarb wrote:

>>> On Sun, 06 Apr 2008 16:28:12 +0200, Hadron wrote:

>>>

>>>> Moshe Goldfarb <brick.n.straw@gmail.com> writes:

>>>>

>>>>> "Somewhere in California - At 8:30 PDT with the release of Snoopy Linux 2.1

>>>>> and Goober Linux 1.0, the number of Linux distributions finally surpassed

>>>>> the number of actual Linux users."

>>>>>

>>>>>

>>>>> "We've been expecting it for some time," Merrill Lynch technology analyst

>>>>> Tom Shayes said, "but this is a little sooner than most expected. We've

>>>>> seen explosive growth in the number of Linux distributions, in fact my

>>>>> nephew just put out LittleLinux Chart Tommy Linux 1.1 last week."

>>>> Kewl! Does it "rock" and "work really well"? Does it meet your "needs"?

>>>>

>>>>> http://www.bbspot.com/News/2000/4/linux_distros.html

>>>> LOL. At least some people get it.

>>> Hahaha!

>>>

>>> Linux and the Linux community is a ball of confusion, a clusterfsck that is

>>> fragmented, filled with hateful, arrogant people and which has no direction

>>> or leadership.

>>>

>>> Everyone is free to do their own thing, which is fine if you wish to remain

>>> like the above.

>>> However if Linux ever has a hope of challenging Microsoft for the desktop

>>> it is going to have to reign in the confusion and become organized, even if

>>> it is loosely organized at first.

>>>

>>> They can start with why the need for so many different package managers.

>>>

>>> Then they can move to why they need 15 different sound systems.

>>>

>>> Why so many different native file systems.

>>>

>>> Why different startup and shutdown scripts doing different things at the

>>> various levels in the boot/shutdown process.

>>>

>>> Why so many different, and duplicate tools to mange the distribution.

>>>

>>> An example is Samba.

>>>

>>> There has to be a dozen or more tools to set up Samba and for anyone who

>>> has attempted to set up Samba they know how confusing it is.

>>> The net is clogged with How-To's on this topic and it is surely one of the

>>> most frequently asked questions in Linux help groups.

>>>

>>>

>>> They should take the best of the best, meld it into ONE TOTALLY WORKING

>>> distribution and then put all the other stuff in a repository free to

>>> download if anyone wants to.

>>> This way they can take all of these people who are working on their own

>>> distributions and pool their resources and talent to create a Linux that

>>> actually works instead of the slopware (mostly) that is what desktop Linux

>>> currently is.

>>>

>>> But the Linux community won't allow this because they cry "we want

>>> choice!!"

>>>

>>> Evidently they want inferior slopware programs as well.

>>>

>>

>> Maybe the software has a little ways to go but it is improving rapidly.

>> with more Linux distros than users just shows how much smarter Linux

>> users are than windows users.

>> From the looks of it many more Linux users can create their own OS.

>> Almost non of the Windows users can.

>> caver1

>

> Of course Linux has been improving, but being able to create your own

> distribution of the month caters to a small subset of geeks and does

> nothing but further the confusion.

>

> The vast majority of the market are USERS not geek programmer types.

> That is one major reason why Linux does not appeal to average Joe.

>

>

"The average Joe" doesnt even know what Linux is. And even if "he" did,

it probably wouldn't matter. Herdm mentality, Inertia, Network Effects.

 

--

Rick

How can a kernel want anything? Or do you mean the "Linux Community".

And, if so, how do you expect a community to Moshe Goldfarb wrote:

> On Sun, 06 Apr 2008 13:50:39 -0400, Jeff Glatt wrote:

>

>>> Moshe Goldfarb <brick.n.straw@gmail.com>

>>> Linux and the Linux community is a ball of confusion

>> Overall, yes. But then, any sufficiently large demographic seems confused to me

>> because... well, people can be really, really different from each other.

>

> Linux needs some organization because it's obvious that everyone is doing

> their own thing and no clear "winner" has emerged, except maybe

> Ubuntu/Debian.

 

Well, why don't go form a committee?

>

> There has to be a focus to fix what is wrong with Linux rather than

> releasing even more broken distributions.

 

In your opinion. WHen will you get it through your head that the

Linux/OSS/FOSS development model is not the same as having one company

make the decisions model?

>

>

>>> filled with hateful, arrogant people

>> If you're talking about the "I hate MS and everything associated with it"

>> brigade, then yeah, those folks are really annoying and useless. Also, the

>> Linux "unpaid salesmen" (typically referred to as "fanbois") are really

>> annoying, because they're more interested in selling you on their particular

>> pet distro than actually being honest and helpful. They also almost always

>> belong to the aforementioned brigade, which makes them doubly useless.

>

> You've just described COLA to the letter.

>

> There are a couple of PAID fanbois in COLA as well though.

 

ANd hhow much do you make for your posting?

>

>> The annoyance of too many Ubuntu fanbois helped convince me to switch to

>> Debian. I just found Debian to a more serious distro where you can find good

>> help without having to endure fanbois as much. I was able to put together a

>> Debian system to do exactly what I wanted easier than with Ubuntu.

>

> Agreed.

> I think they should rename their trees though because the stable/unstable

> etc stuff is confusing.

 

You don't knoe the difference between stable and unstable?

>

>>> and which has no direction or leadership.

>> Overall yes. But see my comment above about large demographics.

>>

>>> Everyone is free to do their own thing, which is fine if you wish to remain

>>> like the above.

>>> However if Linux ever has a hope of challenging Microsoft for the desktop

>>> it is going to have to reign in the confusion and become organized, even if

>>> it is loosely organized at first.

>>> They can start with why the need for so many different package managers.

>> Yeah, that really needs to be addressed. I read an article about a guy who

>> proposed to have an API added to Linux to aid in the installation of software.

>> He got a bunch of developers of various package managers together, and got some

>> feedback from them. The conclusion seemed to be that most of them were planning

>> to simply keep doing things their own way, weren't all that interested in a

>> standard Linux API for installation purposes, and didn't really have much of an

>> interest in working on a more common solution. C'est la vie. So what we have is

>> a bunch of package systems, and app developers who don't support them all

>> because it's too much of a pain in the ass.

>

> This is called "choice" in COLA.

> While technically it is choice, it is also confusing and not helping the

> Linux cause at all.

>

> Fragmentation is not a good thing for Linux.

>

> Too many Indians and not enough Chiefs IMHO.

 

ANd who are you to make that decision?

>

>> When I package my software, I make a deb, and that's it. It's not that I have

>> anything against other package managers, but I happen to use apt-based distros,

>> and I just don't have the time nor inclination to bother with the package

>> managers of other distros. If those folks don't want to make it easier for me,

>> then I'm not interested in them.

>>

>>> Then they can move to why they need 15 different sound systems.

>> Because nearly all of them have their flaws, being designed by people who have

>> some good ideas, but unfortunately, do not seem to choose to have those ideas

>> peer reviewed by appropriate people (other sound developers, musicians, etc)

>> before coding starts. This is a really big problem with lots of open source

>> development. People start coding without taking the extra step of first writing

>> up some sort of detailed documentation about how the API will work, and getting

>> that peer-reviewed by other folks who could give good feedback (and maybe

>> propose some changes that will head off a lot of future dissatisfaction with

>> the finished code, and forestall a reason for those other dissatisfied folks to

>> start their own sound system. For some reason, those other dissatisfied folks

>> repeat the same mistake of not doing what the first programmer should have

>> done).

>

> This is where "pooling resources" would help Linux.

>

> The idea is that people want to play/record/edit sounds.

> They don't want to have to play with various Linux sound systems and they

> certainly don't need the different sound systems all competing for

> interrupts and thus resulting in no sound at all.

> IOW playing two sounds from two different applications at once is a crap

> shoot depending upon which sound system is active.

 

Well, why don't you make a decisoins and force everyone to use it?

>

> We've all seen the /dev/dspx is in use by another program/process message.

>

> This just doesn't happen under Windows unless you are using some high end

> package like Nuendo which assumes it is the only application using the

> sound subsystem.

 

.... unless? unless? So it does happen in Windows.

> IOW it's highly unlikely a musician would be listening to streaming radio

> while mixing or recording his latest project :)

>

>

>> I always write up the docs for my software before I even start coding. I

>> *never* use any sort of utility that creates docs from comments in the source

>> code, and I think that stuff should be outlawed because it encourages people to

>> fail to do enough "flow charting" and proper peer review before they start

>> coding.

>

> That's another Linux problem, documentation.

> Either the docs are too minimul (ie:The File menu contains, etc )

> or they are too complex.

 

Well.. go write some documentation instead of bitching.

> And then there is the tons of outdated How-To's and so forth on the net as

> well as specific doc for each individual distribution and now you have a

> giant mess.

>

>

>>> Why so many different native file systems.

>> Probably for the same reasons as above.

>

> Yep.

> Everyone is doing their own thing.

> Except maybe Hans Reiser who will be doing what he is told for the rest of

> his life, most likely.

 

You really are a puke of a person.

>

>>> They should take the best of the best, meld it into ONE TOTALLY WORKING

>>> distribution and then put all the other stuff in a repository free to

>>> download if anyone wants to.

>>> But the Linux community won't allow this because they cry "we want

>>> choice!!"

>> I'm sort of with you here. But actually I want more real choice. What I'm

>> getting with Linux is a bunch of choices that are, to me, pretty much all the

>> same thing. For example, I don't want a choice between a GUI API that runs atop

>> of X (and inherents its inherent limitations and design flaws) such as Gnome,

>> and another GUI API that runs atop of X too such as KDE. I want people to

>> support more real choices, like instead of dividing up programming attention

>> between those two, maybe support something that really is much more different

>> (such as directfb). I don't want a choice between Pulse Audio (ick) or ALSA

>> (better than Pulse Audio, but still with its problems -- problems that Pulse

>> Audio inherents because it rides on top of ALSA). I want a choice between sound

>> systems that really do have a radically different approach. Etc.

>

> We agree.

> I also see a need for the targeted distributions like DSL (low resource

> systems) or the firewall on a floppy distribution (I can't remember it's

> name but it is very good), audio recording based distributions are ok as

> well.

 

I see. A specialized distro is OK as long as it is something you agree with.

>

> It's the distributions that are nothing but graphics, maybe a different

> menu strutcture etc that are confusing things because they are so close to

> the versions they are based on.

>

> How many Ubunut offshoots are there?

> There must be at least 100 of those alone.

 

List them. All 100.

>

>

>> There are way, way too many Linux "choices" that are far too similiar, have the

>> same basic set of features and limitations, and seem to exist simply because

>> people aren't collaborating better. I'd rather see more collaboration among

>> people who are doing pretty much the same thing, and encourage "choice" where

>> it really offers something significantly different. The problem Linux has is

>> that people aren't collaborating enough when they should, nor are they doing

>> something significantly different when they should. We're getting choices that

>> aren't enough of a choice.

>

> The problem is they are reinventing the wheel over and over again and while

> a particular distribution may solve one problem, it creates another problem

> in the process and the cycle continues.

 

So what?

>

>

> Your post is a fine one BTW Jeff.

> The people in COLA could learn from your honesty and unbiased view of

> things.

>

> BTW when I make mention of Linux loons etc I am speaking of COLA and real

> zealots. I'm not referring to Linux advocates in general because most of

> them don't act like the loons in COLA do.

>

 

So... you call Linux software slopware and crapware. Why do you use

slopware and crapware.

 

--

Rick

On Sun, 06 Apr 2008 13:25:34 -0400, Moshe Goldfarb wrote:

 

On Sun, 06 Apr 2008 13:25:34 -0400, Moshe Goldfarb wrote:

> On Sun, 06 Apr 2008 12:24:14 -0500, netcat wrote:

>

>> On Sun, 06 Apr 2008 13:07:44 -0400, Moshe Goldfarb wrote:

>>

>>> Of course Linux has been improving, but being able to create your own

>>> distribution of the month caters to a small subset of geeks and does

>>> nothing but further the confusion.

>>>

>>> The vast majority of the market are USERS not geek programmer types.

>>> That is one major reason why Linux does not appeal to average Joe.

>>

>> You don't have to be a geek. Under Ubuntu all it takes is one command

>> to generate a LiveDVD using your current setup. You can use the LiveDVD

>> on future reinstalls or if you plan to install to more than one

>> machine, and you can also boot it on the same machine or a different

>> one and have the same settings and applications as on your HD. Throw in

>> a USB drive for persistent storage and you can even save data and

>> configuration changes.

>

> You've just proved my point.........

 

Fortunately, the average user is smarter than a flounder...

On Sun, 06 Apr 2008 10:19:26 -0400, Moshe Goldfarb wrote:

> "Somewhere in California - At 8:30 PDT with the release of Snoopy Linux 2.1

> and Goober Linux 1.0, the number of Linux distributions finally surpassed

> the number of actual Linux users."

>

> "We've been expecting it for some time," Merrill Lynch technology analyst

> Tom Shayes said, "but this is a little sooner than most expected. We've

> seen explosive growth in the number of Linux distributions, in fact my

> nephew just put out LittleLinux Chart Tommy Linux 1.1 last week."

>

> http://www.bbspot.com/News/2000/4/linux_distros.html

 

But they're all running Linux 2.6 . . . .

 

Only the bells and whistles change!

 

--

 

Usenet is a strange place.

 

< Dennis M. Ritchie

Hadron <hadronquark@googlemail.com> wrote in news:ftb1s2$e25$2

@registered.motzarella.org:

 

> Most people (including Tattoed Lobotomy) want their desktops to work and

> have applications working that employees must use to do a job of

> work. Not something to give them pleasure.

 

Of course, you are assuming that most computers are used in a business

setting to do business.

 

Maybe 15 years ago, but not today.

DanS <t.h.i.s.n.t.h.a.t@a.d.e.l.p.h.i.a.n.e.t> writes:

> Hadron <hadronquark@googlemail.com> wrote in news:ftb1s2$e25$2

> @registered.motzarella.org:

>

>

>> Most people (including Tattoed Lobotomy) want their desktops to work and

>> have applications working that employees must use to do a job of

>> work. Not something to give them pleasure.

>

> Of course, you are assuming that most computers are used in a business

> setting to do business.

>

> Maybe 15 years ago, but not today.

>

>

 

And of course I would expect Linux to be more popular in Business where

working multimedia and top notch gaming SW are less of a requirement.

 

--

Whoever asked if the debian organization was dead isn't reading

debian-devel. 66 messages in one day, and it's not over. I find it

difficult to keep up.

-- Bruce Perens

"ray" <ray@zianet.com> wrote in message

news:65s5agF2h5910U5@mid.individual.net...

> On Sun, 06 Apr 2008 10:19:26 -0400, Moshe Goldfarb wrote:

>

>> "Somewhere in California - At 8:30 PDT with the release of Snoopy Linux

>> 2.1 and Goober Linux 1.0, the number of Linux distributions finally

>> surpassed the number of actual Linux users."

>>

>>

>> "We've been expecting it for some time," Merrill Lynch technology

>> analyst Tom Shayes said, "but this is a little sooner than most

>> expected. We've seen explosive growth in the number of Linux

>> distributions, in fact my nephew just put out LittleLinux Chart Tommy

>> Linux 1.1 last week."

>>

>>

>> http://www.bbspot.com/News/2000/4/linux_distros.html

>

> Must be somewhat similar to vista stats - 150 million units sold 50 in

> use.

 

Another Linturd Liar

>Hadron

>The problem is that "Linux fanbois"

>exist who will crop up in knowledge bases which have nothing to do with

>the distro they actually use. And guess what "it works for them".

 

Yes, I've seen examples of them. It's a shame that they use Linux because

they're counterproductive. Not only don't they help people who do use Linux,

they also alienate people who don't use Linux.

 

I've had recent experiences with them in this newsgroup too. I talked a little

about the problem with developing for KDE in regards to a C programmer, and

someone who obviously has no programming experience (despite his claims to the

contrary) posted an annoying fanboi response filled with accusations about

"trolling". Worse, someone else unfortunately asked this fanboi for programming

advice. Needless to say, the fanboi was unable to answer the person's

questions. I had to provide answers to the queries. It's annoying when fanbois

interrupt and destroy conversations that more knowledgeable and responsible

people are trying to have, and its counterproductive for others to have to

clean up the mess they make when those of us with a better perspective could be

applying our efforts elsewhere.

>I am hoping pulseaudio will prevail.

 

I'm hoping it will flop and go away. I have absolutely no confidence in that

code base, nor the person maintaining it. He doesn't do proper error-checking

in his code, and actually defends that practice. He calls malloc() without

checking the return value. His "excuse" is that other programmers do this as

well, and anyway the Linux "process killer" will "take care of things". I'm

sorry, but I don't want my app to suddenly be terminated because I happen to be

calling some library that doesn't do proper error checking. I write audio and

MIDI software, and I will never use Pulse Audio. ALSA may be an API that takes

data abstraction to an annoying degree, but at least the ALSA devs know how to

do proper error checking, and therefore, their API is stable and reliable.

 

Incidentally, Pulse Audio is pretty much a daemon that sits on top of ALSA. It

really has nothing to offer that ALSA doesn't already offer, except that it

"emulates" more of the other sound APIs (ie, aRTS and ESD) than ALSA does, and

therefore claims to be able to replace them all. Plus it does this sort of

"individual audio settings per app", but frankly, an app could do that on its

own if programmers wanted to. Any other of its features are strictly mickey

mouse fluff. The only significant thing Pulse Audio offers is increased

instability under low memory conditions. I very much recommend against its use.

This so called "ear candy" will give serious audio users an ear ache.

 

I think that the whole lot of sound APIs should be scrapped, and ALSA should be

given a redesign to eliminate some of the redundancy (ie, sometimes there are

several different ways to do the same thing, apparently just for the hell of

it), and the abhorrent level of data abstraction. (I have particular ideas on

that too, but this goes well beyond the gist of this thread). There's nothing

inherently wrong with ALSA that a whole lot more care would solve much better

than the proliferation of audio APIs, particularly ones such as Pulse Audio

which will just introduce more instability for very little gain.

>"Real choice".

 

Yes. Real choice is not "I can get a hamburger at McDonald's or I can get a

hamburger at Burger King.". Real choice is "I can get a hamburger at

McDonald's, or I can get a sitdown meal at the gourmet restaurant down the

street". The difference between the vast majority of Linux distros, and Linux

software in general, is much more like the former than the latter.

>Ubuntu and some others are migrating to pulse.

 

Yes, and unfortunately so. They're choosing some really trivial feature sets,

such as having audio (speaker) panning follow the mouse pointer, at the expense

of system stability. The first thing I'll do with any distro I install

containing Pulse Audio is to disable and remove that daemon, and do the same

with any software that requires it.

 

There is no reason why features such as these can't be added to ALSA, with

better performance -- other than the fact that they're really cartoonish

features, and not really suitable for a serious audio API.

>I find it better than ALSA.

 

In what particular ways? Note that Pulse Audio sits on top of ALSA, so it's

behavior is ultimately inherited from ALSA.

>But as usual most of it is all half arsed and buggy regardless.

 

ALSA, as of the newest version, is a rather reliable API. I've done a complete

code audit of it, and I found some bugs in previous versions, but those were

fixed in the latest version. I do not see any noticeable bugs. On the other

hand, Pulse Audio is a poster child for lack of proper error checking. I did a

code audit of it, and if the author were a computer science student, I'd flunk

him.

>Maybe even someone as dumb as Spike1 or Tattoed

>Buttcheek will understand that.

 

Is that really necessary? If these people are doing something counterproductive

to Linux, that's unfortunate. But why bring them up in a message that really

has nothing to do with them?

On Sun, 06 Apr 2008 20:57:54 -0400, Jeff Glatt wrote:

> Yes, I've seen examples of them. It's a shame that they use Linux because

> they're counterproductive. Not only don't they help people who do use Linux,

> they also alienate people who don't use Linux.

 

Lol, takes you back to Utica... the good old Dissident days, commenting

about Amiga fanboi's in the Amiga room of Citadel BBS's, doesn't it Jeff?

 

I see you haven't changed much )

> I've had recent experiences with them in this newsgroup too. I talked a little

> about the problem with developing for KDE in regards to a C programmer, and

> someone who obviously has no programming experience (despite his claims to the

> contrary) posted an annoying fanboi response filled with accusations about

> "trolling".

 

Oh, come on Jeff. You have always enjoyed this little cat and mouse game

you play, putting out little bits of cheese for the fanbois to pounce upon,

and then firing your intellectual ammunition at them. If you didn't enjoy

it, you wouldn't find yourself in these arguments so much.

> Worse, someone else unfortunately asked this fanboi for programming

> advice. Needless to say, the fanboi was unable to answer the person's

> questions. I had to provide answers to the queries. It's annoying when fanbois

> interrupt and destroy conversations that more knowledgeable and responsible

> people are trying to have, and its counterproductive for others to have to

> clean up the mess they make when those of us with a better perspective could be

> applying our efforts elsewhere.

 

I sense yet another argument about the inability of the Amiga's serial port

to maintain MIDI baud rates reliably... Or a rant about how OS/2 is going

to replace the Amiga because IBM knows what it's doing, and Commodore

doesn't.

>>I am hoping pulseaudio will prevail.

>

> I'm hoping it will flop and go away. I have absolutely no confidence in that

> code base, nor the person maintaining it. He doesn't do proper error-checking

> in his code, and actually defends that practice. He calls malloc() without

> checking the return value. His "excuse" is that other programmers do this as

> well, and anyway the Linux "process killer" will "take care of things". I'm

> sorry, but I don't want my app to suddenly be terminated because I happen to be

> calling some library that doesn't do proper error checking.

 

Oh, a rant about code cleanliness. That was my next guess.

 

Most people were brought up to believe that malloc could not fail, because

if you ran out of memory the OOM killer would either free up more memory or

kill the process. Unfortunately, this "wisdom" comes from the days when

people could imagine ever needing to allocate more than the maximum working

process size, and they didn't imagine that a computer could have enough

memory to actually allow that.

 

In 32 bit systems, it's now quite possible for malloc to fail, when that

was so far beyond imagination just a few years ago. In 64 bit systems,

however, it's unlikely that malloc will ever fail in the foreseeable

future.

 

In any event, yes. Good, clean code should check malloc, and that's

especially true on 32 bit systems where you require a large amount of

memory (or in embedded systems without virtual memory).

> Yes. Real choice is not "I can get a hamburger at McDonald's or I can get a

> hamburger at Burger King.". Real choice is "I can get a hamburger at

> McDonald's, or I can get a sitdown meal at the gourmet restaurant down the

> street". The difference between the vast majority of Linux distros, and Linux

> software in general, is much more like the former than the latter.

 

Indeed.

> There is no reason why features such as these can't be added to ALSA, with

> better performance -- other than the fact that they're really cartoonish

> features, and not really suitable for a serious audio API.

 

Which may be the ultimate reason for a seperate daemon.

>Moshe Goldfarb

>Linux needs some organization because it's obvious that everyone is doing

>their own thing and no clear "winner" has emerged, except maybe

>Ubuntu/Debian.

 

I kind of see where you're going with this, but I think a more apropos way to

say it is that Linux needs better collaboration and planning. We don't need a

leader so much as we need folks to be able to understand the benefits of better

pre-planning software implementations (ie, better flow-charting and more

attention to doing certain things before you start coding such as actually

coming up with a list of APIs you plan to implement), and peer reviewing ideas

before coding.

 

Collaboration doesn't mean taking someone else's code and modifying it, and

then releasing what you did so someone else can use it (although a lot of what

I see in open source suggests that's exactly what open source programmers think

qualifies as collaboration). Real collaboration involves discussing ideas with

other people, coming to a consensus on things, and maybe even working together

on coding the initial release.

>You've just described COLA to the letter.

 

I'm not familiar with this newsgroup. If the "A" in that stands for "advocacy",

then it's a worthless newsgroup. There is no need for more salesmen in this

world. We have more than enough of them already. I know what I want, and I

don't need someone else to tell me.

>I think [Debian] should rename their trees though because the stable/unstable

>etc stuff is confusing.

 

Well, there's a lot of things that Debian could do better. I'm just saying that

one of the things they do better than Ubuntu, is not to suffer fanbois as much,

and allow fanbois to basically define the distro. From my point of view, Ubuntu

is mostly all hype generated from an excessive amount of fanbois. I've found

Debian to be ultimately more useful, and I think a lot of that has to do with

the fact that, while Debian certainly does have some rather opinionated and

brusque people involved in its "community", they nevertheless aren't as useless

and counterproductive as the fanbois who hold great sway in Ubuntu's community

(for example the ones who control the Ubuntu website forums).

>Fragmentation is not a good thing for Linux.

 

No, but I think what we have is not so much fragmentation. I mean, honestly,

how much difference is there between Ubuntu and Mint? Really not that much.

It's a few bash scripts, and what the distros choose to install by default

(such as Mint including restricted codecs). It's not like you're getting

significantly different things. Explaining the differences to a newbie is

actually rather confusing because you can't focus upon "the larger picture"

(which is what a newbie understands better). You have to talk about the more

minor, subtle differences. It's actually easier to explain the difference

between Gentoo and Ubuntu, because then you can say "You're going to be dealing

with source code and a command line with Gentoo, and just executables and a GUI

with Ubuntu". It's easier to find a more significant difference, and sum it up

in a single sentence. What's harder is when you have to explain that something

is "the same thing but sort of different".

 

We actually have a lack of fragmentation in Linux because the vast majority of

distros are essentially the same thing. What we have is too much proliferation,

rather than fragmentation. We have too many choices that are the same thing.

It's a lot easier for a consumer to differentiate between three restaurants

that serve entirely different types of cuisine (Italian, Chinese, and Mexican,

for example), than three restaurants that all serve the same menu.

>IOW playing two sounds from two different applications at once is a crap

>shoot depending upon which sound system is active.

 

Right. But a lot of that has to do with the fact that none of the Linux audio

APIs have any "resource sharing" interfaces. And a lot of that has to do with

the fact that, in order for this to work, you absolutely have to be able to

collaborate with lots of different audio developers, and be very meticulous

about the design before you start coding. This is not something that open

source developers are particularly noted for doing.

>We've all seen the /dev/dspx is in use by another program/process message.

 

Right. Because the APIs have no means for one app to say "notify any apps using

this resource to release it for my use", nor any means for an app to say

"notify me if any other app wants me to release this resource for its use".

 

I made a Linux library that shares a hardware resource among numerous apps.

It's definitely not something I'd expect a newbie programmer to do, but it can

be done in Linux, and Linux needs an audio/MIDI API that can do it.

>This just doesn't happen under Windows unless you are using some high end

>package like Nuendo which assumes it is the only application using the

>sound subsystem.

 

Well, Windows audio API does support multi-client drivers. And the API itself

"mixes" audio and MIDI streams from different processes. ALSA doesn't do that.

 

But I think it would be better to implement a "resource sharing" API like

Opcode did the Mac's OMS. This is more efficient, and it eliminates the need

for the drivers to do lots of complex things to implement resource sharing

transparently to the app. I think it would be better to have the app assist in

intelligently sharing audio/MIDI resources rather than have the underlying API

try to do it without the app's consent nor even knowledge.

>That's another Linux problem, documentation.

 

Very big problem.

Jeff Glatt <jglatt@spamgone-borg.com> writes:

>>Hadron

>>The problem is that "Linux fanbois"

>>exist who will crop up in knowledge bases which have nothing to do with

>>the distro they actually use. And guess what "it works for them".

>

> Yes, I've seen examples of them. It's a shame that they use Linux because

> they're counterproductive. Not only don't they help people who do use Linux,

> they also alienate people who don't use Linux.

>

> I've had recent experiences with them in this newsgroup too. I talked a little

> about the problem with developing for KDE in regards to a C programmer, and

> someone who obviously has no programming experience (despite his claims to the

> contrary) posted an annoying fanboi response filled with accusations

> about

 

I remember this. Mark South probably. H's always at that and refuses

to believe that something like KDevelop isn't straight from heaven.

> "trolling". Worse, someone else unfortunately asked this fanboi for programming

> advice. Needless to say, the fanboi was unable to answer the person's

> questions. I had to provide answers to the queries. It's annoying when fanbois

> interrupt and destroy conversations that more knowledgeable and responsible

> people are trying to have, and its counterproductive for others to have to

> clean up the mess they make when those of us with a better perspective could be

> applying our efforts elsewhere.

>

>>I am hoping pulseaudio will prevail.

>

> I'm hoping it will flop and go away. I have absolutely no confidence

> in that

 

I learnt something from the next paragraph.

> code base, nor the person maintaining it. He doesn't do proper error-checking

> in his code, and actually defends that practice. He calls malloc() without

> checking the return value. His "excuse" is that other programmers do this as

> well, and anyway the Linux "process killer" will "take care of things". I'm

> sorry, but I don't want my app to suddenly be terminated because I happen to be

> calling some library that doesn't do proper error checking. I write audio and

> MIDI software, and I will never use Pulse Audio. ALSA may be an API that takes

> data abstraction to an annoying degree, but at least the ALSA devs know how to

> do proper error checking, and therefore, their API is stable and

> reliable.

 

But a pity I cant get it to work properly with shared sound e.g mplyer,

youtube and system sounds. I need to install esd/pulse for system

sounds to work and then every now and again all sounds stops and get

queued until something (god knows what) releases the queue and they all

come piling out together,

>

> Incidentally, Pulse Audio is pretty much a daemon that sits on top of ALSA. It

> really has nothing to offer that ALSA doesn't already offer, except that it

> "emulates" more of the other sound APIs (ie, aRTS and ESD) than ALSA does, and

> therefore claims to be able to replace them all. Plus it does this sort of

> "individual audio settings per app", but frankly, an app could do that on its

> own if programmers wanted to. Any other of its features are strictly mickey

> mouse fluff. The only significant thing Pulse Audio offers is increased

> instability under low memory conditions. I very much recommend against its use.

> This so called "ear candy" will give serious audio users an ear ache.

>

> I think that the whole lot of sound APIs should be scrapped, and ALSA

> should be

 

Yup.

> given a redesign to eliminate some of the redundancy (ie, sometimes there are

> several different ways to do the same thing, apparently just for the hell of

> it), and the abhorrent level of data abstraction. (I have particular ideas on

> that too, but this goes well beyond the gist of this thread). There's nothing

> inherently wrong with ALSA that a whole lot more care would solve much better

> than the proliferation of audio APIs, particularly ones such as Pulse Audio

> which will just introduce more instability for very little gain.

>

>>"Real choice".

>

> Yes. Real choice is not "I can get a hamburger at McDonald's or I can get a

> hamburger at Burger King.". Real choice is "I can get a hamburger at

> McDonald's, or I can get a sitdown meal at the gourmet restaurant down the

> street". The difference between the vast majority of Linux distros, and Linux

> software in general, is much more like the former than the latter.

 

You do not need to explain that. I agree 100%. I always laugh when COLA

types say things like "Devilsspawn Linux really rocked and I liked it a

lot" You then ask what exactly they liked about it and it turns out that

"Gnome worked" or something equally as pathetic or "non issue".

>

>>Ubuntu and some others are migrating to pulse.

>

> Yes, and unfortunately so. They're choosing some really trivial feature sets,

> such as having audio (speaker) panning follow the mouse pointer, at the expense

> of system stability. The first thing I'll do with any distro I install

> containing Pulse Audio is to disable and remove that daemon, and do the same

> with any software that requires it.

 

Interesting.

>

> There is no reason why features such as these can't be added to ALSA, with

> better performance -- other than the fact that they're really cartoonish

> features, and not really suitable for a serious audio API.

 

Distro hell and "choice" rearing its ugly head again then .... The sound

system has left me feeling totally drained. I dont know where to look

anymore to be honest. Its a mess.

>

>>I find it better than ALSA.

>

> In what particular ways? Note that Pulse Audio sits on top of ALSA, so it's

> behavior is ultimately inherited from ALSA.

 

With pulse most things share or play simultaneously. Not with just alsa

for me. I dont know why. I have given up.

>>But as usual most of it is all half arsed and buggy regardless.

>

> ALSA, as of the newest version, is a rather reliable API. I've done a complete

> code audit of it, and I found some bugs in previous versions, but those were

> fixed in the latest version. I do not see any noticeable bugs. On the other

> hand, Pulse Audio is a poster child for lack of proper error checking. I did a

> code audit of it, and if the author were a computer science student, I'd flunk

> him.

 

To be honest I'm not sure I agree with your issues with ignoring

malloc. I do check myself but I often wonder "why bother". If I cant

malloc 32 bytes or something then there are worse issues and the chance

of the logging daemon working it about nil.

 

>

>>Maybe even someone as dumb as Spike1 or Tattoed

>>Buttcheek will understand that.

>

> Is that really necessary? If these people are doing something counterproductive

> to Linux, that's unfortunate. But why bring them up in a message that really

> has nothing to do with them?

 

Yeah, you're right. It becomes a habit in COLA.

"Rick" <none@nomail.com> stated in post

dr2dnbmm9d7HvGTanZ2dnUVZ_u2mnZ2d@supernews.com on 4/6/08 12:16 PM:

> Moshe Goldfarb wrote:

>> On Sun, 06 Apr 2008 16:28:12 +0200, Hadron wrote:

>>

>>> Moshe Goldfarb <brick.n.straw@gmail.com> writes:

>>>

>>>> "Somewhere in California - At 8:30 PDT with the release of Snoopy Linux 2.1

>>>> and Goober Linux 1.0, the number of Linux distributions finally surpassed

>>>> the number of actual Linux users."

>>>>

>>>>

>>>> "We've been expecting it for some time," Merrill Lynch technology analyst

>>>> Tom Shayes said, "but this is a little sooner than most expected. We've

>>>> seen explosive growth in the number of Linux distributions, in fact my

>>>> nephew just put out LittleLinux Chart Tommy Linux 1.1 last week."

>>> Kewl! Does it "rock" and "work really well"? Does it meet your "needs"?

>>>

>>>> http://www.bbspot.com/News/2000/4/linux_distros.html

>>> LOL. At least some people get it.

>>

>> Hahaha!

>>

>> Linux and the Linux community is a ball of confusion, a clusterfsck that is

>> fragmented, filled with hateful, arrogant people and which has no direction

>> or leadership.

>>

>> Everyone is free to do their own thing, which is fine if you wish to remain

>> like the above.

>

> So, you too prefer a dictatorship. Figures.

>

>> However if Linux ever has a hope of challenging Microsoft for the desktop

>> it is going to have to reign in the confusion and become organized, even if

>> it is loosely organized at first.

>

> How can a kernel want anything? Or do you mean the "Linux Community".

> And, if so, how do you expect a community to to act in the same way a

> single corporation can?

>

>>

>> They can start with why the need for so many different package managers.

>

> That has already been answered. Different groups saw different needs.

> Different managers arose.

>

>>

>> Then they can move to why they need 15 different sound systems.

>

> Name all 15.

>

>>

>> Why so many different native file systems.

>

> Because each has different strengths.

>

>>

>> Why different startup and shutdown scripts doing different things at the

>> various levels in the boot/shutdown process.

>>

>> Why so many different, and duplicate tools to mange the distribution.

>>

>> An example is Samba.

>>

>> There has to be a dozen or more tools to set up Samba and for anyone who

>> has attempted to set up Samba they know how confusing it is.

>> The net is clogged with How-To's on this topic and it is surely one of the

>> most frequently asked questions in Linux help groups.

>

> Apparently "the community" doesn't agree on which Samba management tool

> is the best. Why don't you just tell them, and then you can enforce your

> decision.

>

>>

>>

>> They should take the best of the best, meld it into ONE TOTALLY WORKING

>> distribution and then put all the other stuff in a repository free to

>> download if anyone wants to.

>

> Who is "they". Who gets to decide what s "best"?

>

>> This way they can take all of these people who are working on their own

>> distributions and pool their resources and talent to create a Linux that

>> actually works instead of the slopware (mostly) that is what desktop Linux

>> currently is.

>

> How are you going to force those developers, whose disros you killed, to

> work on "someone else's" distro?

>

>>

>> But the Linux community won't allow this because they cry "we want

>> choice!!"

>>

>> Evidently they want inferior slopware programs as well.

>>

>

> Why do you use slopware?

 

You keep talking about people being forced. Do you understand anything

about Linux and OSS development?

 

 

--

I don't know the key to success, but the key to failure is to try to please

everyone. -- Bill Cosby

"ray" <ray@zianet.com> wrote in message

news:65s5agF2h5910U5@mid.individual.net...

> On Sun, 06 Apr 2008 10:19:26 -0400, Moshe Goldfarb wrote:

>

>> "Somewhere in California - At 8:30 PDT with the release of Snoopy Linux

>> 2.1 and Goober Linux 1.0, the number of Linux distributions finally

>> surpassed the number of actual Linux users."

>>

>>

>> "We've been expecting it for some time," Merrill Lynch technology

>> analyst Tom Shayes said, "but this is a little sooner than most

>> expected. We've seen explosive growth in the number of Linux

>> distributions, in fact my nephew just put out LittleLinux Chart Tommy

>> Linux 1.1 last week."

>>

>>

>> http://www.bbspot.com/News/2000/4/linux_distros.html

>

> Must be somewhat similar to vista stats - 150 million units sold 50 in

> use.

 

Or the fallacy that Linux has more than a 1% market share on the desktop. Oh

wait, that's right. You said it IS, because IT IS. Except you don't have any

facts to back your statements up. Just like this one.

 

--

Sanity calms, but madness is more interesting.

http://www.lockergnome.com/darksentinel

Undo the munge to reply by email

"Wes Groleau" <groleau+news@freeshell.org> wrote in message

news:Nn9Kj.256$_I1.144@trnddc02...

> ray wrote:

>

>> Must be somewhat similar to vista stats - 150 million units sold 50 in

>> use.

>

> And 100 million people still _trying_ to get in "in use"

 

And you know this HOW?

 

--

Sanity calms, but madness is more interesting.

http://www.lockergnome.com/darksentinel

Undo the munge to reply by email

On Mon, 07 Apr 2008 08:19:58 -0500, chrisv wrote:

> Let's suppose that you're right. Now, what should one do about it? If

> one is "Hadron", one whines, pouts, stomps one's feet, and shamelessly

> lies about how "advocates don't understand that there would be benefits

> to focusing resources on fewer distros" (we do).

>

> On the other hand, one might understand that distro proliferation is

> what happens with FOSS, and there's no way to prevent it, so one accepts

> it and moves-on.

 

Even explaining it that simply won't make him understand, sorry.

>>>Hadron

>>I talked a little

>>about the problem with developing for KDE in regards to a C programmer, and

>>someone who obviously has no programming experience (despite his claims to the

>>contrary) posted an annoying fanboi response filled with accusations

>>about

>I remember this. Mark South probably. H's always at that and refuses

>to believe that something like KDevelop isn't straight from heaven.

 

Yes, that name sounds familiar. The sad irony is that, I wasn't talking about

KDevelop at all, nor even C programming in general. I was talking specifically

about QT programming in C, and made particular statements about that. Saying

that QT is the same as KDevelop is like saying MS Internet Explorer is the same

thing as the internet. Only someone not familiar with the details would make

that mistake, just as only someone not familiar with QT development in C would

make the mistake of assuming KDevelop is being discussed.

>>>I am hoping pulseaudio will prevail.

>> I'm hoping it will flop and go away. I have absolutely no confidence

>> in that

>I learnt something from the next paragraph.

 

I'm pleased. I hope that people do take a much closer look at what is being

packed into distros, and more people start doing code audits for security and

stability. It's not just the featureset that counts, but also the quality of

the code. I'd rather not have new software bundled if it comes at the expense

of efficiency and stability, and frankly offers marginally useful features.

>But a pity I cant get it to work properly with shared sound e.g mplyer,

>youtube and system sounds. I need to install esd/pulse for system

>sounds to work and then every now and again all sounds stops and get

>queued until something (god knows what) releases the queue and they all

>come piling out together,

 

Right. I just disabled system sounds altogether, and stopped the esd daemon.

I'm more interested in individual apps having sound than being able to hear

some sort of "click" noise when I open a folder, or a paper crumpling when I

empty the trash can.

 

That's not to say that the ALSA devs can't/shouldn't implement some sort of

"audio sharing", and then the Gnome developers can't/shouldn't abandon ESD and

go directly to ALSA. But given that this option isn't yet available, I

personally choose to abandon system sounds rather than risk

instability/inefficiency by using something like Pulse Audio. If Pulse Audio is

installed with a distro I use, I'll manually rip it out.

>The sound system has left me feeling totally drained. I dont know where to look

>anymore to be honest. Its a mess.

 

There's nothing majorly wrong with ALSA. It's stable and well-coded in regards

to error checking/handling. (Yeah, there are some design issues I have with it,

but it's no worse than much of what I see from the other sound choices).

 

What needs to be done is for people to totally reject things like Pulse Audio,

and instead petition the ALSA devs to do some serious peer studies/reviews on

implementing an audio/MIDI "sharing API", and then have app developers, and

especially the developers of Gnome and KDE, directly support ALSA. That will

solve the problems, in a much more efficient and stable way. Right now, the

ALSA devs are not doing this additional work on ALSA, and app devs aren't

supporting ALSA the way they should. And frankly, it's no fault of the app devs

for their support. The ALSA folks have produced very, very poor "documentation"

constructed with one of those horrid tools that pull comments out of source

code. In that case, it's not surprising that developers aren't supporting ALSA

better. ALSA is a more complicated API than something like Pulse Audio or aRTS

or JACK, etc. So given equally bad docs on all of the sound APIs, developers

are going to go for the ones that take the least amount of effort to figure out

on their own.

 

I've started a programming tutorial on ALSA and JACK at the following URL:

 

http://home.roadrunner.com/~jgglatt/tech/linuxapi.htm

 

The ALSA folks really, really, really need to do something much like this.

 

And they could definitely benefit from getting their code base peer reviewed to

fix those things that people find frustrating to use.

>With pulse most things share or play simultaneously. Not with just alsa

>for me. I dont know why. I have given up.

 

Right. Pulse Audio's API has built-in "stream mixing" transparent to the app.

ALSA does not. That's not to say that ALSA cannot have this added to it in a

way that is more efficient, and more stable (since the ALSA devs have at least

shown that they understand the need for proper error checking, and have

designed their whole API to return error codes, as should be done. The Pulse

Audio authors simply do not understand the importance of this, and openly

refuse to attend to it).

>To be honest I'm not sure I agree with your issues with ignoring

>malloc. I do check myself but I often wonder "why bother". If I cant

>malloc 32 bytes or something then there are worse issues and the chance

>of the logging daemon working it about nil.

 

The problem with ignoring malloc's error return is why we have the OOM killer,

which is a kludge that should not have existed. If people had done proper error

checking to begin with, then Linux's low memory error handling would never have

amounted to killing some process without its permission or even knowledge. The

problem with doing this is that, a process may be handling important data that

needs to be saved to permanent media, but has not yet been done, when it is

killed. That's permanent loss of important data, and that is a very, very, very

bad thing. (It's a good thing that wall street firms don't really know about

the OOM killer. If they did, they may back away from Linux for this reason

alone. No one wants to lose data that could cost them dearly. If Win32

advocates really start to understand the implications, there is going to be

major fallout for serious Linux use).

 

All code that does not do proper memory checking needs to be purged from Linux,

and replaced with code that not only does proper error checking, but also

returns proper error codes so that any calling code can also do proper error

checking and handling. This is the key to stability. You can't have stability

without good error checking and handling all the way down the line.

 

But I see why you're thinking "why bother"? Linux already has the OOM Killer

now, as a result of needing to deal with code that totally ignores error

checking and stumbles head-on into inevitable major system instability. So

people often think "it's too late to do the right thing. I can't stop the OOM

Killer. So I may as well do the wrong thing like other folks did". It's my hope

that, as more and more people do the right thing, eventually their code will

replace the "wrong stuff" (because the former will be more stable), and the OOM

killer will eventually be able to be jettisoned and replaced with much more

effective, stable, and efficient low memory handling/recovery. But the last

thing we need is to be adding new things that do the wrong thing some more...

like Pulse Audio.

Just a clarification to my own message:

>Pulse Audio's API has built-in "stream mixing" transparent to the app.

>ALSA does not.

 

ALSA does not have a streaming API built-in. But it does have a "plugin" that,

like Pulse Audio, does stream mixing. This s referred to as "dmix". But one

limitation is that it only works with software that directly supports ALSA. If

you want Gnome system sounds, as well as all app sounds, to be simultaneously

mixed to your speaker outputs, then petition the Gnome developers to jettison

ESD and directly support ALSA instead. Petition all app developers to also

support ALSA. Then just use the dmix plugin as your main ALSA "card", and

you're all set.

netcat wrote:

> On Sun, 06 Apr 2008 13:25:34 -0400, Moshe Goldfarb wrote:

>

> On Sun, 06 Apr 2008 13:25:34 -0400, Moshe Goldfarb wrote:

>

>> On Sun, 06 Apr 2008 12:24:14 -0500, netcat wrote:

>>

>>> On Sun, 06 Apr 2008 13:07:44 -0400, Moshe Goldfarb wrote:

>>>

>>>> Of course Linux has been improving, but being able to create your own

>>>> distribution of the month caters to a small subset of geeks and does

>>>> nothing but further the confusion.

>>>>

>>>> The vast majority of the market are USERS not geek programmer types.

>>>> That is one major reason why Linux does not appeal to average Joe.

>>> You don't have to be a geek. Under Ubuntu all it takes is one command

>>> to generate a LiveDVD using your current setup. You can use the LiveDVD

>>> on future reinstalls or if you plan to install to more than one

>>> machine, and you can also boot it on the same machine or a different

>>> one and have the same settings and applications as on your HD. Throw in

>>> a USB drive for persistent storage and you can even save data and

>>> configuration changes.

>> You've just proved my point.........

>

> Fortunately, the average user is smarter than a flounder...

 

Are you sure about that?

 

gls858

On Mon, 07 Apr 2008 15:51:27 -0400, Jeff Glatt wrote:

> If one agrees, there are a number of things. As just _one_ example, if you've

> ever written a "review" of some distro, do not focus upon the installation

> process, nor what apps are installed by default, what the desktop theme looks

> like, what versions of software are in the repository, nor whether it installs

> restricted codecs by default. Those are all minor, relatively irrelevant points

> (and yet nearly every distro review I've read is confined to discussing this

> small set of minor differences).

 

[...]

> But how about a difference between GoboLinux and Ubuntu's file layout, for

> example? If you had to recreate all those symbolic links on Ubuntu, now you're

> looking at major work for the enduser, because this is a difference that is not

> trivial to negate.

>

> So if you write a review, focus only upon things the distro can do that all

> other distros can't do without major work. And if there is no such feature,

> then either don't bother reviewing the distro, or simply say "This distro

> offers nothing significant that can't be gotten relatively easily upon most

> other distros.".

>

> If you read a review that focusses upon the minor differences, post a comment

> explaining the above to the reviewer and urge him to give attention to projects

> that truly provide something different, rather than hype another "me too"

> project (such as Ubuntu, which is vastly overrated, and stands upon the

> shoulders of Debian, which gets far too little credit as being the impetus

> without which Ubuntu could, and cannot, exist).

 

Bravo, Jeff. You've just articlated something that's been in the back of

my head bouncing around for a long time, but never quite came to the

surface.

 

You can't stop the "Me Too's", but you can certainly do one of a few

things:

 

1) Shame them into going away

 

2) Shame them into actually doing something innovative and worth creating a

while new distro for.

 

3) Make it unattractive to rebrand something and change some config files.

Today, people get lavish praise for, in effect, the equivelent of plagerism

(filing the serial numbers off and changing a few things around).

 

And if none of that works, at least they won't be particularly popular.

 

The thing is, Ubuntu is a marketing movement, not a technology one.

Concentric is very good convincing the low-medium technical people that

it's something special. And maybe that's a good thing, maybe not. Other

communities are "better" in the sense that they tend to have more competent

members on average.

On Mon, 07 Apr 2008 16:11:55 -0400, Jeff Glatt wrote:

> Just a clarification to my own message:

>

>>Pulse Audio's API has built-in "stream mixing" transparent to the app.

>>ALSA does not.

>

> ALSA does not have a streaming API built-in. But it does have a "plugin" that,

> like Pulse Audio, does stream mixing. This s referred to as "dmix". But one

> limitation is that it only works with software that directly supports ALSA. If

> you want Gnome system sounds, as well as all app sounds, to be simultaneously

> mixed to your speaker outputs, then petition the Gnome developers to jettison

> ESD and directly support ALSA instead. Petition all app developers to also

> support ALSA. Then just use the dmix plugin as your main ALSA "card", and

> you're all set.

 

This is, in my estimation, the biggest problem Linux faces. It's not the

"choices" (though that's part of the problem), it's not "difference", it's

the incompatibilities between apps and configurations and various

components.

 

And that's the result of balkanized development, in which people develop

*conflicting* systems.

"gls858" <gls858@yahoo.com> wrote in message

news:%231E2YzOmIHA.980@TK2MSFTNGP06.phx.gbl...

> netcat wrote:

>> On Sun, 06 Apr 2008 13:25:34 -0400, Moshe Goldfarb wrote:

>>

>> On Sun, 06 Apr 2008 13:25:34 -0400, Moshe Goldfarb wrote:

>>

>>> On Sun, 06 Apr 2008 12:24:14 -0500, netcat wrote:

>>>

>>>> On Sun, 06 Apr 2008 13:07:44 -0400, Moshe Goldfarb wrote:

>>>>

>>>>> Of course Linux has been improving, but being able to create your own

>>>>> distribution of the month caters to a small subset of geeks and does

>>>>> nothing but further the confusion.

>>>>>

>>>>> The vast majority of the market are USERS not geek programmer types.

>>>>> That is one major reason why Linux does not appeal to average Joe.

>>>> You don't have to be a geek. Under Ubuntu all it takes is one command

>>>> to generate a LiveDVD using your current setup. You can use the LiveDVD

>>>> on future reinstalls or if you plan to install to more than one

>>>> machine, and you can also boot it on the same machine or a different

>>>> one and have the same settings and applications as on your HD. Throw in

>>>> a USB drive for persistent storage and you can even save data and

>>>> configuration changes.

>>> You've just proved my point.........

>>

>> Fortunately, the average user is smarter than a flounder...

>

> Are you sure about that?

>

> gls858

 

Well, in your case............

Erik Funkenbusch wrote:

> On Mon, 07 Apr 2008 16:11:55 -0400, Jeff Glatt wrote:

>

>> Just a clarification to my own message:

>>

>>> Pulse Audio's API has built-in "stream mixing" transparent to the app.

>>> ALSA does not.

>> ALSA does not have a streaming API built-in. But it does have a "plugin" that,

>> like Pulse Audio, does stream mixing. This s referred to as "dmix". But one

>> limitation is that it only works with software that directly supports ALSA. If

>> you want Gnome system sounds, as well as all app sounds, to be simultaneously

>> mixed to your speaker outputs, then petition the Gnome developers to jettison

>> ESD and directly support ALSA instead. Petition all app developers to also

>> support ALSA. Then just use the dmix plugin as your main ALSA "card", and

>> you're all set.

>

> This is, in my estimation, the biggest problem Linux faces. It's not the

> "choices" (though that's part of the problem), it's not "difference", it's

> the incompatibilities between apps and configurations and various

> components.

>

> And that's the result of balkanized development, in which people develop

> *conflicting* systems.

 

 

Which is the outcome of open software. You can't have open software

telling anyone that they can make changes to the code as long as they

give it away when they do an they say its not right for some. All you

can do is stay away from the bad and hope it dies out.

caver1

>Erik Funkenbusch

>This is, in my estimation, the biggest problem Linux faces. It's not the

>"choices" (though that's part of the problem), it's not "difference", it's

>the incompatibilities between apps and configurations and various

>components.

>And that's the result of balkanized development, in which people develop

>*conflicting* systems.

 

Incompatibilities are a result of a lack of collaboration.

 

I feel it's more to do with open source developers mistakening "collaboration"

as "I take someone else's source code and hack at it. Then I release my hacked

version". That isn't collaboration. That's more like evolution if anything,

which may produce something different, but not necessarily something better,

nor something that can peacefully co-exist with what it evolved from.

 

At root of the issue is that I don't get the impression many open source

developers understand the concept of getting your ideas peer-reviewed, nor the

idea of flow-charting (which seems to be a lost programming art). They start

coding without enough pre-planning, finish up something, and _then_ they get

feedback when they say "Here's my initial offering for testing. Tell me how you

like it". It's too late by then. The "mistakes" have already been made.

Invariably, the dev takes the position of defending his own choices, and those

who wish it were somehow different are even more discouraged from working with

that person, and even more encouraged to go off on their own and develop

something completely incompatible. Unfortunately, those other developers often

seem to repeat the same mistake.