Ysgrifennodd David Brodbeck:

kanenas wrote:

...

3. This is the only SuSE system besides 10.1 where a reboot "makes things ok for a while, then shtuff lapses into an almost predictable pattern of problems". 10.1 is guilty too, but does the dirty deed with much less frequency.

You know, I hate to say it, but my experience is that this is a classic symptom of bad RAM. Have you run something like MEMTEST86 to verify that's not your issue? I've had systems with bad RAM where Windows would run OK most of the time but Linux would have all kinds of problems. I had one system (actually running FreeBSD) that had a SIMM with two stuck bits. The system would run great for about two days, then some important kernel structure would hit the defective memory locations and the system would lock solid. That took a lot of head-scratching to figure out.

10.2 has been quite stable for me ever since I disabled zmd. ;) That said, I'm on 32-bit platforms, and it's possible you're hitting some bug specific to 64-bit systems.

I hate to say it (because I don't want this to turn into a bashing session), but my experience with SuSE 10.0 on AMD64 x 2 is almost identical. Peter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Anders Johansson wrote:

On Friday 02 March 2007 21:57, Peter Bradley wrote:

...

I hate to say it (because I don't want this to turn into a bashing session), but my experience with SuSE 10.0 on AMD64 x 2 is almost identical.

Running 10.2 here on an AMD X2

10:03pm up 6 days 23:31, 10 users, load average: 1.14, 2.03, 2.03

Not a single problem so far

Mine's been running for about 7 weeks, without problem. I've got an AMD 64 as well. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 3/2/07, Peter Bradley wrote:

never know. Can someone give some details about this memtest or whatever it was? There doesn't seem any harm in giving it a go.

Just boot with the install cd/dvd. The last grub option is memtest. Just run it as much as possible. Usually, if there is a problem, one night of running should reveal it. Cheers -- Svetoslav Milenov (Sunny) Even the most advanced equipment in the hands of the ignorant is just a pile of scrap. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Peter Bradley wrote:

Ysgrifennodd Sunny:

...

On 3/2/07, Peter Bradley wrote:

...

never know. Can someone give some details about this memtest or whatever it was? There doesn't seem any harm in giving it a go.

Just boot with the install cd/dvd. The last grub option is memtest. Just run it as much as possible. Usually, if there is a problem, one night of running should reveal it.

Cheers

Heh! Even I should be able to manage that. I'll give it a go. Thanks.

FWIW, I started having problems with my 32 bit mom board last year. It turned out to be memory errors that got worse to the point that it could no longer boot. I got the 64 bit system last May and have been running 64 bit SUSE ever since. Those problems appear to have been in the motherboard, as I had 3 memory sticks and all of them checed bad in that system. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

kanenas wrote:

...

3. This is the only SuSE system besides 10.1 where a reboot "makes things ok for a while, then shtuff lapses into an almost predictable pattern of problems". 10.1 is guilty too, but does the dirty deed with much less frequency.

You know, I hate to say it, but my experience is that this is a classic symptom of bad RAM. Have you run something like MEMTEST86 to verify that's not your issue? I've had systems with bad RAM where Windows would run OK most of the time but Linux would have all kinds of problems. I had one system (actually running FreeBSD) that had a SIMM with two stuck bits. The system would run great for about two days, then some important kernel structure would hit the defective memory locations and the system would lock solid. That took a lot of head-scratching to figure out.

10.2 has been quite stable for me ever since I disabled zmd. ;) That said, I'm on 32-bit platforms, and it's possible you're hitting some bug specific to 64-bit systems. All suggestions about my system are appreciated. But my point is that reliability is normal under 10.1 and 10.0 running in the same hardware, with

On Friday 02 March 2007 09:26, David Brodbeck wrote: the "same" apps, actually vmware uses the same virtual machines no matter which suse i run. I just killed my 10.0 installation and installed the 32 bit 10.2 in that partition, but I can still compare shtuff between my 10.1 install and the 10.2. ten poin two loses every time... Bad ram was one of the first things suspected, I have 2 gigs of it and I do run memtest once in a while, but running 2 xp vms, firefox with 10 tabs, an instance of oo, kmail, googleearth and avidemux in 10.1 does not result in the freeze-ups that 10.2 does... To be honest, I have not run a test in the past month, so one might be overdue, will do one tonight. My experience with memtest is that if a stick is bad, it will be exposed within 5 minutes, never had a different conclusion after an overnight test, nevertheless I do run it overnight. Re zmd, I have not had the trouble I had with it in 10.1, so zmd is still active and apparently is working well. But beagle was never installed, it was removed from the initial install. Regarding my frustration, it should be clear that it is not linux bashing. It is directed at the "features galore, never mind the crashes" attitude of more and more "programmers". It is amazing that someone actually defended bloated programming in this thread, that is just as bad as firefox catching itself crashing, imo they should concentrate on eliminating the crashes, not in catching them!!!!! Quality has been slipping. It is evident that this is deeply rooted in the approach of the new generation of programmers, it is more in line with the instant gratification without work thinking. Please spend the time to make something right, not just 80% functional. Please stick to what works well. Simplify the complicated, fix the bug. Don't add new features until it all works in the first place. Leave the other approach to others... thanks for putting up with the rambling, dimitris -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday 02 March 2007 16:07, Bruce Marshall wrote:

On Friday 02 March 2007 19:58, kanenas wrote:

...

I just killed my 10.0 installation and installed the 32 bit 10.2 in that partition, but I can still compare shtuff between my 10.1 install and the 10.2. ten poin two loses every time...

To make it even simpler: I think that 64 bit 10.2 does have a problem somewhere. This is reinforced by the first new round of memtest, yes it ran for only 3.5 hours, zero errors, yes it will run for another 8-9 later on tonight, but previous experience saiz the memory is good.

Then try Fedora.... or Mandriva... or Debian or Ubuntu...

I have mentioned that I just started playing with the 32 bit 10.2. If that does not perform to my satisfaction, the plan is to go back to the 64 bit 10.1, now we all know how to handle the update issue. In a somewhat parallel course, I have also created a free bsd virtual machine in my vmware. if that works I will make the installation "real", but that is a bit more long range than plan a or plan a1. It is not time to jump off the bridge yet.

Maybe one of them will work better for you. What you are saying has no basis.

Running two operating systems (10.1 and 10.2) on/in the same hardware, one of them crashing, the other one *not* crashing, seems like a good enough basis to me.

No two releases are alike and if they were, no one would bother upgrading to a new release.

Why did you?

I heard good things about 10.2 in this list. The main switch was around last Christmas. I gave myself time to iron out issues, but it seems that something more drastic is in line. I wanted to communicate this to the list, maybe it will be of some help to someone, also I took a wag at what I think is the underlying reason for the less than stellar performance of 10.2 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday 02 March 2007 06:09:15 pm Bruce Marshall wrote:

On Friday 02 March 2007 19:58, kanenas wrote:

...

installed, it was removed from the initial install. Regarding my frustration, it should be clear that it is not linux bashing. It is directed at the "features galore, never mind the crashes" attitude of more and more "programmers". It is amazing that someone actually defended bloated programming in this thread, that is just as bad as firefox catching itself crashing, imo they should concentrate on eliminating the crashes, not in catching them!!!!!

Almost all of us experience no crashes.... And I suspect you have never written a program and therefore know nothing of what you are spewing...

This is a ridiculous discussion.

Not entirely. As a long-time programmer - I wrote my first BASIC code in '79 in fifth grade on a TRS-80 - and now programming manager, I understand the need to balance between "bloat" and "efficency." People like me are always trying to provide the best possible solution at the lowest possible cost. We just went into production at my current workspace with an enterprise-scale application that took three programmers a little over a year to code. The design and requirements took roughly four years. We're actually on the ninth point-release since 1/2/07 (2.1.07 for those on the right side of the Atlantic). I'm going to spend the weekend testing release 10 - 1.0.1.10 - before releasing it Tuesday. I had one of the programmers do an informal survey of the code. Written in C#, the code had roughly 277,000 lines in several dozen assemblies. Many assemblies are re-used while some are only used once. We also used some third-party libraries, such as an image viewer and DLL interfaces to a receipt printer, touch screen device and label printers. Had we done the code in C++ or even ASM, it is possible we could have either expanded the code or lessened it. I don't know at this time and it is a mute point. Writing in a 3GL such as C# allowed us to not worry about memory management in the way we would have been forced to had we writtin in a 2GL or - heaven forbid - assembler. The "bloat" to which many people refer often is a result of added functionality. Let's face it - adding a GUI with lots of dummy-proof features - adds code and complexity. I'm sure Vi has a lot less code than does OpenOffice. I'm sure many of the Linux programmers here - Marcus and the others - are constantly balancing their own need to produce clean and efficient code with delays imposed on them by pointy-haired managers such as myself. In fact, it has been documented that the only reason the ill-fated Zen got into 10.1 was a result of pointy-haired managers insisting it go regardless. Instead of grief, I would give them applause. -- kai Free Compean and Ramos http://www.grassfire.org/142/petition.asp http://www.perfectreign.com/?q=node/46 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Saturday 03 March 2007, Carlos E. R. wrote:

The Friday 2007-03-02 at 20:09 -0800, Kai Ponte wrote:

...

We just went into production at my current workspace with an enterprise-scale application that took three programmers a little over a year to code. The design and requirements took roughly four years. We're actually on the ninth point-release since 1/2/07 (2.1.07 for those on the right side of the Atlantic).

Which leaves me without knowing for certain which month it is, the 2nd or the first... So, assuming it is February, why not "7-2-1"? Or the ISO format in my reply-leadin line above ;-) There is no doubt seeing "2007-03-02" which is the year and the month and the day.

...

Had we done the code in C++ or even ASM, it is possible we could have either expanded the code or lessened it. I don't know at this time and it is a mute point. Writing in a 3GL such as C# allowed us to not worry about memory management in the way we would have been forced to had we writtin in a 2GL or - heaven forbid - assembler.

I'm interested in this: can you expand, or point to a link? Maybe I'll have a look at the wikipedia.

...

The "bloat" to which many people refer often is a result of added functionality. Let's face it - adding a GUI with lots of dummy-proof features - adds code and complexity. I'm sure Vi has a lot less code than does OpenOffice.

I'll give an example, an old one.

I don't remember which version of Turbo Pascal produced a minumum ~30 KiB exe, just to write a "hello world" in the screen. Then, they invented what they called "smart linking", and it went down to 2 or 4 KiB! The thing is that their linker was clever enough to remove all functions from the linked libraries not actually called in the program. The "Turbo C" version of the same vintage didn't have the same ability.

-- Cheers, Carlos E. R.

DD/MM/YYYY the best all round soloution .. Pete . -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Saturday 03 March 2007, Carlos E. R. wrote:

The Saturday 2007-03-03 at 11:39 -0000, peter nikolic wrote:

...

DD/MM/YYYY

the best all round soloution ..

No, the best is following the ISO standard. That's what they are for, standards.

-- Cheers, Carlos E. R.

Not Realy . The ISO standard of YYYY/MM/DD is not the most efficent way of using a date example " you want to know the date you look at the ISO standard date you have to wade thru the year the month to find the day date normally the most used part of the date string whereas DD/MM/YYYY the important bit is right at th front of the string DD then you can read the rest if you need it .. YMMV Mine dont Pete . -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Saturday 03 March 2007, Anders Johansson wrote:

On Saturday 03 March 2007 17:05, peter nikolic wrote:

...

On Saturday 03 March 2007, Carlos E. R. wrote:

...

The Saturday 2007-03-03 at 11:39 -0000, peter nikolic wrote:

...

DD/MM/YYYY

the best all round soloution ..

No, the best is following the ISO standard. That's what they are for, standards.

-- Cheers, Carlos E. R.

Not Realy .

The ISO standard of YYYY/MM/DD is not the most efficent way of using a date

Translated into English: "It's not what I'm used to, so it's bad"

Having grown up in a country that uses yyyymmdd I much prefer the ISO standard

Now your trying to put words i have not used into use that is not what i said at all ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

peter nikolic wrote:

The ISO standard of YYYY/MM/DD is not the most efficent way of using a date

it is better not because it's more efficient, but because it's the standard and so it's prone to be understood by anybody. If you don't like it, subscribe to the ISO standard commissions (I'm sure they are free) and argue for a change...

example " you want to know the date you look at the ISO standard date you have to wade thru the year the month to find the day date normally the most used part of the date string whereas DD/MM/YYYY the important bit is right at th front of the string DD then you can read the rest if you need it ..

when I give my age, I say I'm from 1946, the month and days don't mean anything... jdd -- http://www.dodin.net Lucien Dodin, inventeur http://lucien.dodin.net/index.shtml -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Oops! I sent my last message as a PM as well as to the list. Sorry, jdd :( It comes of using Evolution at home and Thunderbird at work. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2007-03-03 10:05, peter nikolic wrote:

On Saturday 03 March 2007, Carlos E. R. wrote:

...

The Saturday 2007-03-03 at 11:39 -0000, peter nikolic wrote:

...

DD/MM/YYYY

the best all round soloution ..

No, the best is following the ISO standard. That's what they are for, standards.

-- Cheers, Carlos E. R.

Not Realy .

The ISO standard of YYYY/MM/DD is not the most efficent way of using a date

example " you want to know the date you look at the ISO standard date you have to wade thru the year the month to find the day date normally the most used part of the date string whereas DD/MM/YYYY the important bit is right at th front of the string DD then you can read the rest if you need it ..

YMMV Mine dont

Pete .

There is nothing anywhere in the English language that compels you to read left-to-right only -- in your example, start reading at the other end ;-) -- slleW GH -- .olah a htiw ysuolaej si noitangidni laroM -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 2007-03-03 14:06, James Knott wrote:

Darryl Gregorash wrote:

...

On 2007-03-03 10:05, peter nikolic wrote:

...

The ISO standard of YYYY/MM/DD <blah blah snip snip>

There is nothing anywhere in the English language that compels you to read left-to-right only -- in your example, start reading at the other end ;-)

Now, which end has the month? ;-)

Lemme see.. the left end is the year, the right end is the day -- I think that means the middle end is the month, yes? (Think of it as you would a transistor ;-) ) -- Moral indignation is jealousy with a halo. -- HG Wells -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-03-03 at 16:05 -0000, peter nikolic wrote:

...

...

DD/MM/YYYY the best all round soloution ..

...

No, the best is following the ISO standard. That's what they are for, standards.

Not Realy .

The ISO standard of YYYY/MM/DD is not the most efficent way of using a date

example " you want to know the date you look at the ISO standard date you have to wade thru the year the month to find the day date normally the most used part of the date string whereas DD/MM/YYYY the important bit is right at th front of the string DD then you can read the rest if you need it ..

It is not efficient for you because it is not what you are used to. But, being a standard, it avoids confusion, specially in international conversations. It is in fact very efficient, because the most significant number is always written at the left, and the least at the right - therefore years must go to the left, then month, then day. It is the logical way. A bunch of dates can be sorted just by alphabetical sort, like in a directory listing. And no, it is not the way I grew up which, nor my country use. It feels strange, but it is the standard, so I use it. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF6cIotTMYHG2NR9URAs1HAJwMZesA4f/WGKEa3fgBHHihhsgtpgCeKQ/Z 0lqCA8/5agIQxoir93ipFlo= =0E9M -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

John R. Sowden wrote:

A while back this thread mentioned Borland's 'Smart Linking' in one of its Pascal compilers, but not the current (at the time) C compiler). As this process only makes sense to minimize program size, therefore decreasing load time, and probably run time, as more RAM is available, it this process being used by today's current compilers?

I don't know, but considering how few applications are statically-linked these days, is there really a big payoff? It was different when the target was a DOS program, since those usually had to carry all their libs along with them. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-03-03 at 12:17 -0800, John R. Sowden wrote:

A while back this thread mentioned Borland's 'Smart Linking' in one of its Pascal compilers, but not the current (at the time) C compiler). As this process only makes sense to minimize program size, therefore decreasing load time, and probably run time, as more RAM is available, it this process being used by today's current compilers?

If not, why not? Is Borland holding the rights, like the tire and oil companies buying and closing the trains, or Intuit's buying 'In House Accountant', then shelving it.?

No, no. Free Pascal uses the same or similar technique. I don't know how they do it, but in Borland case they could do it because TPascal did not use the "standard" linker and .obj file structure with extra information, but a different one (.tpu) designed for the purpose. Their C compiler used a standard linker (almost), so it didn't have smart linking. On the other hand... I doubt the technique is usefull with OOP. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFF6hzGtTMYHG2NR9URAkAXAJ4t+RY+Hi34BaOLYsa9q9XgYc7LYQCeI4OM 3sUrFkhIzTR4ylZ+KwHZYIQ= =tO8A -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

peter nikolic wrote:

On Saturday 03 March 2007, Carlos E. R. wrote:

...

The Saturday 2007-03-03 at 11:39 -0000, peter nikolic wrote:

...

DD/MM/YYYY

the best all round soloution ..

No, the best is following the ISO standard. That's what they are for, standards.

-- Cheers, Carlos E. R.

Not Realy .

The ISO standard of YYYY/MM/DD is not the most efficent way of using a date

example " you want to know the date you look at the ISO standard date you have to wade thru the year the month to find the day date normally the most used part of the date string whereas DD/MM/YYYY the important bit is right at th front of the string DD then you can read the rest if you need it ..

YMMV Mine dont

Pete .

Now, if you want your computer to sort on date, which method works best? With ISO, the most significant value is on the left, just like all other numeric calculations. If you were to write the numbers for a dollar fifty, would you write $50.1 ? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Saturday 03 March 2007 03:02:19 am Carlos E. R. wrote:

The Friday 2007-03-02 at 20:09 -0800, Kai Ponte wrote:

...

We just went into production at my current workspace with an enterprise-scale application that took three programmers a little over a year to code. The design and requirements took roughly four years. We're actually on the ninth point-release since 1/2/07 (2.1.07 for those on the right side of the Atlantic).

Which leaves me without knowing for certain which month it is, the 2nd or the first... So, assuming it is February, why not "7-2-1"? Or the ISO format in my reply-leadin line above ;-) There is no doubt seeing "2007-03-02" which is the year and the month and the day.

Well, not wanting to get dragged down in the "my-date-format-is-better-than-yours" war, how's 2007-01-02? (January 2nd - a.k.a. the first Monday business day in California this year.)

...

Had we done the code in C++ or even ASM, it is possible we could have either expanded the code or lessened it. I don't know at this time and it is a mute point. Writing in a 3GL such as C# allowed us to not worry about memory management in the way we would have been forced to had we writtin in a 2GL or - heaven forbid - assembler.

I'm interested in this: can you expand, or point to a link? Maybe I'll have a look at the wikipedia.

http://en.wikipedia.org/wiki/Third-generation_programming_language http://en.wikipedia.org/wiki/Fourth-generation_programming_language http://en.wikipedia.org/wiki/Programming_language#Generational_view Though not universally agreed-upon - I tend to lump C#/Java or other Form-based languages with the 3GL crowd. Many like to see C++ as either a 3GL or a 2GL. I

...

The "bloat" to which many people refer often is a result of added functionality. Let's face it - adding a GUI with lots of dummy-proof features - adds code and complexity. I'm sure Vi has a lot less code than does OpenOffice.

I'll give an example, an old one.

I don't remember which version of Turbo Pascal produced a minumum ~30 KiB exe, just to write a "hello world" in the screen. Then, they invented what they called "smart linking", and it went down to 2 or 4 KiB! The thing is that their linker was clever enough to remove all functions from the linked libraries not actually called in the program. The "Turbo C" version of the same vintage didn't have the same ability.

You know, I remember that. I used to write Pascal on my Apple II after I realized the limitations of BASIC. Heh! -- kai Free Compean and Ramos http://www.grassfire.org/142/petition.asp http://www.perfectreign.com/?q=node/46 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos, On Friday 02 March 2007 11:56, Carlos E. R. wrote:

The Friday 2007-03-02 at 11:41 -0800, Randall R Schulz wrote:

...

...

2. It is WRONG to rely on the speed of new hardware to make up for bad programming.

The very notion is nonsense.

I don't think so. It is quite true, in general.

Que es mas macho? Pineapple or knife? -- Laurie Anderson It's nonsense since there's no relationship between program/ming quality and hardware speed. If anything, faster hardware (and especially multi-processor or multi-core systems) can expose certain kinds of programming errors that remain latent in lower-performance hardware.

-- Cheers, Carlos E. R.

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday 02 March 2007 12:58, Carlos E. R. wrote:

The Friday 2007-03-02 at 12:19 -0800, Randall R Schulz wrote:

...

On Friday 02 March 2007 11:56, Carlos E. R. wrote:

...

The Friday 2007-03-02 at 11:41 -0800, Randall R Schulz wrote:

...

...

2. It is WRONG to rely on the speed of new hardware to make up for bad programming.

The very notion is nonsense.

I don't think so. It is quite true, in general.

Que es mas macho? Pineapple or knife? -- Laurie Anderson

Never heard that.

Young'un, eh? I had the good fortune of seeing her perform live twice and attend one of her art installations at UCLA. I don't know what she's up to, now.

...

It's nonsense since there's no relationship between program/ming quality and hardware speed. If anything, faster hardware (and especially multi-processor or multi-core systems) can expose certain kinds of programming errors that remain latent in lower-performance hardware.

The relation is that with faster hardware programmers don't have to trim their programs. They can allow their programs to be huge, repetitive, non-optimized, because the hardware is faster, disks are bigger, and the diference will be hardly noticed.

That was not how I understood the complaint. He reported an instability. That's not a matter of program or programming efficiency, but rather one of correctness. And bug manifestation and hardware speed are, if anything, negatively correlated.

-- Cheers, Carlos E. R.

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos, On Friday 02 March 2007 15:54, Carlos E. R. wrote:

The Friday 2007-03-02 at 13:24 -0800, Randall R Schulz wrote:

...

...

...

Que es mas macho? Pineapple or knife? -- Laurie Anderson

Never heard that.

Young'un, eh? I had the good fortune of seeing her perform live twice and attend one of her art installations at UCLA. I don't know what she's up to, now.

No, simply I'm not american, thus my knowledge of your culture is limited. I just looked her up in the wikipedia. Not my kind of music, anyway... I'm listening to parts from "La belle au bois dormant" (P. Tschaikowsky) right now, in fact.

Well, I was just kidding. Laurie Anderson has always been a minority taste, but there _is_ great music both from still-living artitsts _and_ from non-Europeans (living or not)...

But I was refering to that saying you excerpted.

It's not a saying, as such. It's a line from one of her songs. It came to mind in the context of juxtaposing incommensurates.

...

He said many things, some I might agree (a bit), some not. But he also expressed the view that present day software is bloated, abusing the fact that most hardware is better than yesteryear and they can get away with it - and some of us more or less think the same.

I usually consider that a glib criticism that rarely comes from programmers who, much as they want to write tight code, must balance the requirement for producing correct code with the desire for efficient code all in the face of stringent, often unrealistic, scheduling constraints.

-- Cheers, Carlos E. R.

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday 02 March 2007 17:19, Rajko M. wrote:

On Friday 02 March 2007 18:13, Randall R Schulz wrote: ...

...

I usually consider that a glib criticism that rarely comes from programmers who, much as they want to write tight code, must balance the requirement for producing correct code with the desire for efficient code all in the face of stringent, often unrealistic, scheduling constraints.

I can agree, but the bloat is everywhere and it is brought to the extremes.

"Everywhere?" "Extremes?" Can you quantify these claims? Of course not.

My last "wondering why" was with HP laptop. It has software switch to turn wireless transmitter on and off. I can imagine that the most important function of some 4 MB large progam is to write a byte to certain I/O address on the chip. It should be quite short. What makes the rest?

Why do you care? What are the real consequences of this putative excess? How do you know what's truly involved in altering the state of the wireless connection on any given computer? It's quite likely that simply disabling the transmitter itself ("writing a byte to an I/O address") would simply cause a cascade of errors throughout the networking subsystems and beyond. And you probably want to be notified if something went wrong. And user-level applications cannot be given direct access to hardware, lest grave security holes be opened. And so on and so forth. It's all too terribly easy to underestimate what's involved in any given task. Managers do that all the time, which is one of the reasons there's so much trouble in the software industry. Stand a kilometer away and every task, every problem, every challenge seems trivial. Technology is complicated, and unobvious connections and complications are many. The bottom line is that unless you really know all the pertinent technical details, this kind of criticism is without any genuine basis.

-- Regards, Rajko.

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday 02 March 2007 22:31, Rajko M. wrote:

On Friday 02 March 2007 19:38, Randall R Schulz wrote:

...

...

...

The bottom line is that unless you really know all the pertinent technical details, this kind of criticism is without any genuine basis.

The 4 MB is big, you can put BIOS and video BIOS, or Linux kernel in it and it will give you some space left. Compare complexity of whole computer to one adapter, and see why I'm asking "What makes the rest?". Your reply is addressing only one side of the problem. The rest of answer is R&D tools, designed to have solution fast, not optimized.

The question remains: So what? Your objection is arbitrary and without intrisic foundation. You compare the size of one program to another one chosen arbitrarily. Nothing is harmed by this program's on-disk size and reductions in space or run time all require programmer and testing effort. Software is produced within an economy. If this were a real problem, then there'd be value in solving it. Presumably the market is dealing with this and similar matters and has produced approximate optimums for these things. That is, it does so unless you think there are siginificant externalities surrounding the making of these decisions. I don't.

-- Regards, Rajko.

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Carlos E. R. wrote:

The relation is that with faster hardware programmers don't have to trim their programs. They can allow their programs to be huge, repetitive, non-optimized, because the hardware is faster, disks are bigger, and the diference will be hardly noticed.

That doesn't really correlate to stability, though. Non-optimized software will be slower (usually) than optimized software, but optimizing a piece of software does not make it more stable. In fact, it's the opposite -- optimization often introduces subtle bugs of its own. You should never start optimizing any code that isn't stable. As Cort Dougan put it when he was working on porting Linux to PowerPC, "A fast kernel that crashes is just a kernel that crashes quickly." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday 02 March 2007 11:41:14 am Randall R Schulz wrote:

...

2. It is WRONG to rely on the speed of new hardware to make up for bad programming.

The very notion is nonsense.

Not really.... http://www.microsoft.com/windows/products/windowsvista/buyorupgrade/capable.... http://support.microsoft.com/kb/q32905/ ...some folks think it is a business model. /me ducks and runs! :P -- kai www.perfectreign.com || www.4thedadz.com www.filesite.org || www.donutmonster.com closing the doors that surround me so no one will ever penetrate complete my retreat just to wait for the day that never comes so i will laugh alone -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org