AqD wrote:

> On Apr 11, 7:39 pm, White Spirit <wspi...@homechoice.co.uk> wrote:

>> AqD wrote:

>>> So what?

>>> A lot of linux apps are a hundred years behind their windows

>>> counterparts.

>>

>> It depends on the app. But the application is not part of the OS, so

>> it's a moot point. With a better OS, the same app will run better.

>

> Yes but an OS is useless itself without apps.

 

Moot point. I don't believe lusers do actual work.

chrisv wrote:

> AqD wrote:

>> On Apr 11, 7:39 pm, White Spirit <wspi...@homechoice.co.uk> wrote:

>>> AqD wrote:

>>>> So what?

>>>> A lot of linux apps are a hundred years behind their windows

>>>> counterparts.

>>>

>>> It depends on the app. But the application is not part of the OS, so

>>> it's a moot point. With a better OS, the same app will run better.

>>

>> Yes but an OS is useless itself without apps.

>

> Moot point. I don't believe lusers do actual work.

 

Yeah, they're too busy trying to get Windows to not crash -- or downloading

updates and rebooting -- or updating their anti-spyware and anti-virus. And

we're not even talking about Vista ME here.

 

--

RonB

"There's a story there...somewhere"

On 11 Apr, 18:40, Erik Funkenbusch wrote:

> Breakage is higher in Vista because too many apps were violating Microsofts design guidelines.

 

Can you produce any citations or concrete examples to back up that

statement, or are we just supposed to take your word for it .. ?

On Fri, 11 Apr 2008 11:19:41 +0100, White Spirit

<wspirit@homechoice.co.uk> wrote:

>There are profound technical reasons why Windows is crap. This is just

>one of them:

>

Is Windows the suckor and you the suckee?

On Apr 12, 2:17 am, the USENET QUEEN "Synapse Syndrome"

<syna...@NOSPAMsyndrome.me.uk> screamed:

> "AqD" <aquila.d...@gmail.com> wrote in message

>

> news:bcaa8442-26d4-49dd-a83e-7382f39fda11@q27g2000prf.googlegroups.com...

>

> > So what?

>

> > A lot of linux apps are a hundred years behind their windows

> > counterparts.

>

> Hey Aquila.  LTNS.

>

> So you have left Linux now?

>

> You stopped GUI twiddling, and now are using Windows Server 2003??

>

> What's going on?

 

My service in army ended, and I switched back to windows several

months before that.

 

I'm trying to get myself back to work, not that I'm jobless but I

found myself reluctant to do anything....

"AqD" <aquila.deus@gmail.com> schreef in bericht

news:9079a3ad-bae7-4500-91e6-cb73f969d8c5@q27g2000prf.googlegroups.com...

On Apr 12, 2:17 am, the USENET QUEEN "Synapse Syndrome"

<syna...@NOSPAMsyndrome.me.uk> screamed:

> "AqD" <aquila.d...@gmail.com> wrote in message

>

> news:bcaa8442-26d4-49dd-a83e-7382f39fda11@q27g2000prf.googlegroups.com...

>

> > So what?

>

> > A lot of linux apps are a hundred years behind their windows

> > counterparts.

>

> Hey Aquila. LTNS.

>

> So you have left Linux now?

>

> You stopped GUI twiddling, and now are using Windows Server 2003??

>

> What's going on?

> My service in army ended, and I switched back to windows several

> months before that.

> I'm trying to get myself back to work, not that I'm jobless

 

That's very good Aquila, don't become a Linux advocate by night and

Microsoft partner by day, like the lying hypocrites Mark Kent and his

husband Roy Schestowitz (Spammowitz).

<quote>

"At BT Global, our crown jewels are the services we supply to our

customers. With jNetX we own the intellectual property for our services,

allowing us to evolve the services as and when required."

*Mark* *Kent*

Head of Technology Strategy

http://www.jnetx.com/index.php?id=products

http://www.jnetx.com/index.php?id=ourpartners

http://www.jnetx.com/fileadmin/images/partner_logo/small/logo005.jpg

https://solutionfinder.microsoft.com/SDK/Solutions/SolutionDetailsView.aspx?solutionid=9bf1884cf9354bbeb110ba73b82dbdb4

http://download.microsoft.com/download/1/2/b/12bedb1a-0b15-4fe9-be7b-275fb83964d4/Jnetx_Sandbox_Demo.pptx

> but I

> found myself reluctant to do anything....

[snips]

 

On Fri, 11 Apr 2008 11:19:41 +0100, White Spirit wrote:

> * Perhaps claiming twenty-five years is unfair given that x86

> architecture was originally unable to offer multitasking

 

Really? When was this? The Commodore 64 offered multitasking, on a 65xx

chip - you're saying the x86 line couldn't do as well?

 

No, the x86 has always been capable of multitasking, as that is a

function of the OS, not the hardware. At most, the hardware makes the

job easier, more reliable and/or more efficient.

Clogwog wrote:

> That's very good Aquila, don't become a Linux advocate by night and

> Microsoft partner by day, like the lying hypocrites Mark Kent and his

> husband Roy Schestowitz (Spammowitz).

 

Someone's off his meds.

 

--

RonB

"There's a story there...somewhere"

Kelsey Bjarnason wrote:

> [snips]

> On Fri, 11 Apr 2008 11:19:41 +0100, White Spirit wrote:

>> * Perhaps claiming twenty-five years is unfair given that x86

>> architecture was originally unable to offer multitasking

> Really? When was this? The Commodore 64 offered multitasking, on a 65xx

> chip - you're saying the x86 line couldn't do as well?

> No, the x86 has always been capable of multitasking, as that is a

> function of the OS, not the hardware. At most, the hardware makes the

> job easier, more reliable and/or more efficient.

 

Perhaps I should have clarified. I'm talking about true multitasking,

involving separate program space for each application with its own stack

and memory allocation. What you're talking about it task-switching.

Hadron wrote:

> White Spirit <wspirit@homechoice.co.uk> writes:

>> Hadron wrote:

>>> White Spirit <wspirit@homechoice.co.uk> writes:

>>>> Have you ever programmed DirectX versus OpenGL or SDL? Take it from

>>>> me, OpenGL and SDL have much cleaner, more elegant APIs. Just about

>>>> all the Windows APIs are ugly. The only thing Microsoft has got right

>>>> so far is C#.

>>> Yes. And you are wrong. The Dx community for a start is far more

>>> knowledgable and experienced. They have to be - if they dont cut it they

>>> are out of business.

>> Every developer has to have the requisite knowledge and experience,

>> otherwise they wouldn't have a job. How does the relative knowledge

>> and experience of DirectX developers, which you allege, relate to the

>> quality of DirectX APS? Its just a red herring that you've thrown in.

> Err, no its not. "Dx community" - the people using it.

 

There is not necessarily a correlation between the quality of something

and the people who use it. This underpins the whole MS debate.

>> I didn't say that OpenGL isn't supported. I asserted that MS push

>> DirectX as an closed source solution that ties people to their

>> products.

> CEDEGA?

 

Cedega doesn't use DirectX. It uses a wrapper to translate to OpenGL.

>>> You're clearly another loon with a chip on his shoulder.

>> Perhaps. It's difficult to judge your motives given that you so far

>> have not been able to argue any point without obfuscation and

>> diversion.

> Actually I have argued each point calmly and with facts.

 

What, by calling me a loon?

> You clearly just hate MS. Good luck to you.

 

And you.

On Mon, 14 Apr 2008 10:50:27 +0100, White Spirit wrote:

> Kelsey Bjarnason wrote:

>

>> [snips]

>

>> On Fri, 11 Apr 2008 11:19:41 +0100, White Spirit wrote:

>

>>> * Perhaps claiming twenty-five years is unfair given that x86

>>> architecture was originally unable to offer multitasking

>

>> Really? When was this? The Commodore 64 offered multitasking, on a

>> 65xx chip - you're saying the x86 line couldn't do as well?

>

>> No, the x86 has always been capable of multitasking, as that is a

>> function of the OS, not the hardware. At most, the hardware makes the

>> job easier, more reliable and/or more efficient.

>

> Perhaps I should have clarified. I'm talking about true multitasking,

 

No such thing.

 

Cooperative, round-robin, pre-emptive, they _all_ qualify as

multitasking, the only differences being the comparative efficiency and

the response to apps which become unresponsive.

> involving separate program space for each application with its own stack

> and memory allocation. What you're talking about it task-switching.

 

No, I'm speaking of multitasking. You're speaking of memory management.

On 2008-04-14, Kelsey Bjarnason <kbjarnason@gmail.com> wrote:

> On Mon, 14 Apr 2008 10:50:27 +0100, White Spirit wrote:

>

>> Kelsey Bjarnason wrote:

>>

>>> [snips]

>>

>>> On Fri, 11 Apr 2008 11:19:41 +0100, White Spirit wrote:

>>

>>>> * Perhaps claiming twenty-five years is unfair given that x86

>>>> architecture was originally unable to offer multitasking

>>

>>> Really? When was this? The Commodore 64 offered multitasking, on a

>>> 65xx chip - you're saying the x86 line couldn't do as well?

>>

>>> No, the x86 has always been capable of multitasking, as that is a

>>> function of the OS, not the hardware. At most, the hardware makes the

>>> job easier, more reliable and/or more efficient.

>>

>> Perhaps I should have clarified. I'm talking about true multitasking,

>

> No such thing.

 

I dunno. The original x86 was pretty dang primitive. Unlike the

early Motorola processors (68k) , it wasn't really designed to be a

"mini computer on a chip". I wouldn't be so quick to attribute to the

x86 family in general any capabilities much beyond a 6502.

>

> Cooperative, round-robin, pre-emptive, they _all_ qualify as

> multitasking, the only differences being the comparative efficiency and

> the response to apps which become unresponsive.

 

Even in the 80s and early 90s, any system that wasn't fully pre-emptive

and also came with memory protection would be referred to as they were more

like fakes than the real thing. Everyone seemed to acknowledge the rather big

caveats involved and never placed the cooperative systems on anywhere

the same footing as the fully pre-emptive ones.

 

People understood the difference between the genuine Porsche and

something that was done up from a kit to just kind of look like a Porsche.

>

>> involving separate program space for each application with its own stack

>> and memory allocation. What you're talking about it task-switching.

>

> No, I'm speaking of multitasking. You're speaking of memory management.

 

 

 

--

Apple: Because a large harddrive is for power users.

|||

/ | \

 

Posted Via Usenet.com Premium Usenet Newsgroup Services

----------------------------------------------------------

http://www.usenet.com

[snips]

 

On Mon, 14 Apr 2008 15:51:07 -0500, JEDIDIAH wrote:

>>> Perhaps I should have clarified. I'm talking about true multitasking,

>>

>> No such thing.

>

> I dunno. The original x86 was pretty dang primitive.

 

Not nearly as primitive as the 6502, which the C64 was based on - and

*it* handled multitasking quite handily.

>> Cooperative, round-robin, pre-emptive, they _all_ qualify as

>> multitasking, the only differences being the comparative efficiency and

>> the response to apps which become unresponsive.

>

> Even in the 80s and early 90s, any system that wasn't fully

> pre-emptive

> and also came with memory protection would be referred to as they were

> more like fakes than the real thing.

 

By whom?

 

No, seriously, by whom? They all qualify as multitasking, the only

significant differences are in efficiency and how they handle

uncooperative applications.

> Everyone seemed to acknowledge the

> rather big caveats involved and never placed the cooperative systems on

> anywhere the same footing as the fully pre-emptive ones.

 

Sure, because a cooperative multitasker was just that - cooperative. It

required that the applications actually cooperate, and it could be

hellishly difficult to design 'em to do so in some cases.

 

Preemptive tasking removed that need - if your app doesn't cooperate, we

don't care, because *zot* you've just been yanked out of the active state

and something else is running.

 

They're both multitasking, one's simply more effective.

 

Take a hypothetical example of cooperative tasking between apps A and B,

and a resource R.

 

A is scheduled and requests resource R, which is free. It gets the

resource which now is marked "busy". It may well use this resource for

some time, so, being a nice little program, it releases the CPU every now

and then.

 

B gets scheduled, attempts to get resource R, which is busy, but there's

a glitch in B's resource management code: it only releases the CPU

("cooperates") *after* it gets the resource. Until then, it waits for

the resource to be available - meaning it is now stuck in a perpetual

wait state, as R is busy and B doesn't release the CPU, meaning A never

finishes its job and never releases R.

 

Net result, R is locked, B never finishes, A never finishes, all not good.

 

Now take away the cooperative aspect:

 

A runs, locks R.

B runs, requests R, which is locked.

B goes into a "forced" wait state.

A finishes, releases R.

B is now woken up and scheduled, it gets R, all is good.

 

Both systems allow multiple "simultaneous"[1] tasks to run, but one is

less fragile. Each multitasks, one is simply better at it.

 

Multitasking is simply the illusion - and occasionally the reality - of

running several programs at the same time. Such illusion - even such

reality - can be achieved by any number of means, including cooperative

and round-robin tasking. They're no more or less "multitasking" than any

other approach, they're just more fragile and/or less efficient than some

other apporaches.

 

 

[1] "simultaneous" in quotes because unless there's actually multiple

execution paths on the processor, or you have multiple processors, only

one task ever actually executes at a time.

Kelsey Bjarnason <kbjarnason@gmail.com> writes:

> [snips]

>

> On Mon, 14 Apr 2008 15:51:07 -0500, JEDIDIAH wrote:

>

>>>> Perhaps I should have clarified. I'm talking about true multitasking,

>>>

>>> No such thing.

>>

>> I dunno. The original x86 was pretty dang primitive.

>

> Not nearly as primitive as the 6502, which the C64 was based on - and

> *it* handled multitasking quite handily.

 

Nonsense. It featured it, but it was extremely limited. The QL was ons

of the first "home computers" which featured a decent multitasking OS.

>

>>> Cooperative, round-robin, pre-emptive, they _all_ qualify as

>>> multitasking, the only differences being the comparative efficiency and

>>> the response to apps which become unresponsive.

>>

>> Even in the 80s and early 90s, any system that wasn't fully

>> pre-emptive

>> and also came with memory protection would be referred to as they were

>> more like fakes than the real thing.

>

> By whom?

>

> No, seriously, by whom? They all qualify as multitasking, the only

> significant differences are in efficiency and how they handle

> uncooperative applications.

>

>> Everyone seemed to acknowledge the

>> rather big caveats involved and never placed the cooperative systems on

>> anywhere the same footing as the fully pre-emptive ones.

>

> Sure, because a cooperative multitasker was just that - cooperative. It

> required that the applications actually cooperate, and it could be

> hellishly difficult to design 'em to do so in some cases.

 

"e'm" doesn't convince anyone. It was actually relatively easy *IF* you

wanted your program to cooperate. Generally just call the message

handler every now and again with something like yield() scattered

around.

 

*snip yet more Kelsey posturing*

Kelsey Bjarnason wrote:

>>> Cooperative, round-robin, pre-emptive, they _all_ qualify as

>>> multitasking, the only differences being the comparative efficiency and

>>> the response to apps which become unresponsive.

>> Even in the 80s and early 90s, any system that wasn't fully

>> pre-emptive

>> and also came with memory protection would be referred to as they were

>> more like fakes than the real thing.

> By whom?

> No, seriously, by whom?

 

I was familiar with the idea of 'true' and 'non-true' multitasking back

then, as were others - hence my use of said terms. I take your point

regarding the nomenclature, but I feel that it is necessary to

differentiate between co-operative/non-memory managed multitasking

environments and those that protect against processes interfering with

each other at runtime.

White Spirit <wspirit@homechoice.co.uk> writes:

> Kelsey Bjarnason wrote:

>

>>>> Cooperative, round-robin, pre-emptive, they _all_ qualify as

>>>> multitasking, the only differences being the comparative efficiency and

>>>> the response to apps which become unresponsive.

>

>>> Even in the 80s and early 90s, any system that wasn't fully

>>> pre-emptive

>>> and also came with memory protection would be referred to as they were

>>> more like fakes than the real thing.

>

>> By whom?

>

>> No, seriously, by whom?

>

> I was familiar with the idea of 'true' and 'non-true' multitasking

> back then, as were others - hence my use of said terms. I take your

> point regarding the nomenclature, but I feel that it is necessary to

> differentiate between co-operative/non-memory managed multitasking

> environments and those that protect against processes interfering with

> each other at runtime.

 

Of course one should. But you will soon realise that Kelsey, a glorified

tape monkey, has taken on amazing ideas of grandeur since she completed

her "programming for sys admins" course. There are hardly any

innovations out there anymore which Kelsey was not involved in at some

stage apparently.

[snips]

 

On Tue, 15 Apr 2008 11:29:46 +0100, White Spirit wrote:

> I was familiar with the idea of 'true' and 'non-true' multitasking back

> then, as were others - hence my use of said terms. I take your point

> regarding the nomenclature, but I feel that it is necessary to

> differentiate between co-operative/non-memory managed multitasking

> environments and those that protect against processes interfering with

> each other at runtime.

 

Nothing about cooperative tasking prevents the use of memory management

or memory protection. Nothing about preemptive tasking requires the use

of memory management or memory protection.

 

Multitasking is about process _scheduling_. Not about memory management

or protection.

 

Effective memory management - on-demand page loading, address remapping,

etc, etc, etc, etc - can certainly make multitasking more effective, but

they're not required simply _to_ multitask. Memory protection can

certainly make multitasking more reliable and safer, but they're not

required simply _to_ multitask. Not even with a fully pre-emptive

tasking system.