POV-Ray : Newsgroups : povray.off-topic : Compiling stuff Server Time
30 Sep 2024 17:26:06 EDT (-0400)
  Compiling stuff (Message 234 to 243 of 283)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Jim Henderson
Subject: Re: Compiling stuff
Date: 17 Dec 2008 11:25:51
Message: <4949280f$1@news.povray.org>
On Wed, 17 Dec 2008 09:50:43 +0000, Invisible wrote:

>>>>> (Actually, at the time I tried out klogic, we *did* have an Internet
>>>>> connection, but I didn't even bother to *attempt* to make it work
>>>>> under Linux. Making the "simple" stuff work was hard enough...)
>>>> Well, then, there's really no excuse for not submitting bugs, is
>>>> there? ;-)
>>> How do you figure that?
>> 
>> Because you're on the 'net now?
> 
> And I don't use klogic any more?

You said you tried it again when you did have an Internet connection.

>> The way you write, you make it sound like there's maybe 1 or 2 or maybe
>> even *gasp* as many as 10 whole games for Linux.  There are probably
>> thousands that run natively, and hundreds to thousands more that will
>> run under something like WINE or reasonably within a current release of
>> VMware.
> 
> I guess it depends on whether you consider XTetris to be a "game".
> 
> Sure, there are about 25,000 Mahjong clones for Linux. But how many
> large-scale games are there?

There are several.  I'm not a gamer, but I'm told by people who are who 
use Linux that game support is better now than ever.

> (If I'm not mistaken, there's one newish FPS that works on Linux - I
> think it might be a member of the Unreal series. Doom has been ported,
> but that's pretty tame by now. And there's Tux Racer...)

Like I said, go to freshmeat.net and have a look.  Go to sourceforge.net 
and have a look.  Go to Cedega's website and look at what Windows games 
are supported.

>>> I'm not saying it's impossible to make cross-platform games. But when
>>> you have a huge codebase invested in DirectX, it would be tantamount
>>> to a complete rewrite to move to OpenGL. (Plus Valve games make use of
>>> lots of advanted stuff like DirectX 10. Guess where that's
>>> supported...)
>> 
>> If you want broader platform support, then it becomes an investment to
>> look into.
> 
> Sure. And some day, there will probably be a lot more stuff for Linux
> than there currently is. All I said was that today there isn't a vast
> amount of stuff yet.

And you were wrong, see above for the reasons why.

>> And companies are doing it, as you said, Valve releases games that are
>> native on Linux now.  There must be money in it or they wouldn't
>> invest.
> 
> Valve don't release games for Linux. They make the game *servers*
> available for Linux. As far as anyone knows, there are no plans to ever
> make the games themselves available for Linux, or any other platform
> that isn't Microsoft.

http://www.cedega.com/gamesdb/

Don't just read the "over 40 games certified", look at the list.  Half-
Life and several (most?) of its derivatives run under Cedega perfectly 
fine.

Just because Valve don't release the clients on Linux doesn't mean you're 
stuffed to run the client on Linux.

> Other developers, though, may have other plans...

Obviously, because the number of games that run on Linux is increasing.

>>> Of course, why would complexity be any obsticle to comprehending
>>> something?
>> 
>> It shouldn't be an obstacle to trying to comprehend it.
>> 
>> If you start with "this is so incredibly complex I'll never understand
>> it so why even bother starting to look at it", then sure, it's going to
>> look damned impossible.  You won't understand it overnight, but you can
>> learn about it over time.
> 
> Sure. A system designed by several thousand designers and programmers
> over the course of decades. A system that is *purposely designed* to be
> difficult to understand. Sounds simple to me. :-P

There you go again with the "purposely designed" nonsense.  It's not 
*designed* to be difficult to understand.  Don't confuse complexity with 
"intentionally meant to be difficult to understand".

>> <sigh>  Again, it's not the specifics, it's the concepts.  A more
>> complex OS just takes more time and manpower.  That doesn't make it
>> impossible. If it wasn't impossible, WINE woudn't exist.  WINE exists. 
>> Therefore, it's possible.
> 
> And exactly how many thousand people are working on WINE?

This may surprise you, but the core development team for most OSS 
projects is relatively small.  A lot of people can contribute patches, 
but the core development team reviews and approves as well as doing 
development.

>>> I don't see anything in the FAQ about legallity.
>> 
>> I was sure there was something in there.  No matter, look at Mono - it
>> also addresses the patent issue.  Mono is a reimplementation of the
>> .NET framework - incidentally, done (I believe) through clean-room
>> reverse- engineering.
> 
> Interesting - I was under the impression that it was an ISO "standard"
> now.

The language may be, but that doesn't mean the libraries are.  Building 
cross-platform applications using C# isn't very easy to do if things like 
Winforms aren't ported to the platforms in question.

>> So please stop saying "it's impossible!" when clearly it isn't because
>> it's being done.
> 
> Well if you want to be *technical* about it, what I *actually* said was
> "it's impressive because it should be impossible".

Semantics, don't start with "it should be impossible" just because you 
don't have the knowledge or experience.  Making a rocket should be 
impossible.  Going to the moon should be impossible.  If the human race 
balked at everything that should be impossible, we'd never progress.

Jim


Post a reply to this message

From: Invisible
Subject: Re: Compiling stuff
Date: 17 Dec 2008 11:26:23
Message: <4949282f$1@news.povray.org>
>>> It's obvious once you learn to operate it.
>> Isn't everything? ;-)
> 
> As long as you take the time to learn it instead of giving up after 5 
> minutes and declare it "impossible". ;-)

Actually it was 2 hours and not 5 minutes, so :-P

>>> But a man page.  "man vim" is a good starting place on a modern *nix
>>> system for learning how to use vi.
>> I'm pretty sure when I tried that, it told you how to invoke vi and all
>> the command-line switches, but not how to actually work the editor. (A
>> bit like the man page for GCC not telling you how to write C programs.)
>>
>> (Also, I'm almost cetain it was vi, not vim.)
> 
> The current man page is pretty good.  vi = vim, they're the same program 
> now.

I'm just astonished that after all the editor wars, there still isn't a 
Unix text-mode editor that's actually *easy* to use, that's all...


Post a reply to this message

From: nemesis
Subject: Re: Compiling stuff
Date: 17 Dec 2008 11:56:02
Message: <49492f22$1@news.povray.org>
Invisible escreveu:
>>>> Andrew, both emacs and vi come with quite good interactive tutorials.
>>> Sure. And do you know how to *find* that?
>>
>> Run vimtutor instead of vim.
> 
> Heh. It always seems easy once you already know how. ;-)

 > vim

Should show you a screen where it gives you a few pointers, including 
:help and :tutor.  Vim is a (very) improved version of vi. 
Unfortunately, it's not the standard vi in most distros.

Now, if you go:
 > vi foo.hs
 > emacs foo.hs

Well, you just don't see the "splash screen"... :P


Post a reply to this message

From: nemesis
Subject: Re: Compiling stuff
Date: 17 Dec 2008 11:58:00
Message: <49492f98$1@news.povray.org>
Chambers escreveu:
> Although I don't remember ever seeing anything about a tutor, at least
> it tells you how to quit.

The tutorial is only for vim, an improved vi.  Old vi is quite like 
using ed, just for real programmers of legend. ;)


Post a reply to this message

From: Invisible
Subject: Re: Compiling stuff
Date: 17 Dec 2008 11:59:52
Message: <49493008$1@news.povray.org>
>>>>> Well, then, there's really no excuse for not submitting bugs, is
>>>>> there? ;-)
>>>> How do you figure that?
>>> Because you're on the 'net now?
>> And I don't use klogic any more?
> 
> You said you tried it again when you did have an Internet connection.

Let's get this straight: I tried KLogic in 1997 or so. Back then, while 
technically we *did* have an Internet connection, after having just 
spent 3 weeks (!!) getting the graphics card to work, I didn't even 
bother *trying* to get the modem to work. (It's probably a winmodem 
anyway...)

So yeah, not very easy to report bugs. :-P

>> Sure, there are about 25,000 Mahjong clones for Linux. But how many
>> large-scale games are there?
> 
> There are several.  I'm not a gamer, but I'm told by people who are who 
> use Linux that game support is better now than ever.

"Better now than ever" could just mean that there are 2 games now 
instead of only 1. ;-)

As I say, I imagine in future the number will go up rather than down. 
That still doesn't change the fact that at the moment it's rather low.

> Like I said, go to freshmeat.net and have a look.

...so Doom, Quake-2 and Unreal then?

(BTW, I've always wondered what the heck "freshmeat" is. I guess now I 
know... sorta...)

> Go to sourceforge.net and have a look.

Not seeing anything interesting here. (Obviously the wrong serarch term 
or something.)

> Go to Cedega's website and look at what Windows games 
> are supported.

Who?

>> Valve don't release games for Linux.
> 
> http://www.cedega.com/gamesdb/
> 
> Don't just read the "over 40 games certified", look at the list.  Half-
> Life and several (most?) of its derivatives run under Cedega perfectly 
> fine.

Again, this utterly defies belief. Games, more than any other 
application, are legendary for intimately relying on obscure 
undocumented functionallity. Getting even one game to anything 
approaching working would be absurdly difficult. I can't begin to 
imagine how they have managed to do this in less than 20 years...

> There you go again with the "purposely designed" nonsense.  It's not 
> *designed* to be difficult to understand.  Don't confuse complexity with 
> "intentionally meant to be difficult to understand".

It's a Microsoft product. It's purposely designed to be overcomplicated 
and obfuscated.

>> And exactly how many thousand people are working on WINE?
> 
> This may surprise you, but the core development team for most OSS 
> projects is relatively small.  A lot of people can contribute patches, 
> but the core development team reviews and approves as well as doing 
> development.

For something like GNUplot, I can believe it. For something like 
reverse-engineering an entire OS, I'd expect it to take a vast army of 
workers.

>>> I was sure there was something in there.  No matter, look at Mono - it
>>> also addresses the patent issue.  Mono is a reimplementation of the
>>> .NET framework - incidentally, done (I believe) through clean-room
>>> reverse- engineering.
>> Interesting - I was under the impression that it was an ISO "standard"
>> now.
> 
> The language may be, but that doesn't mean the libraries are.

True...

> Semantics, don't start with "it should be impossible" just because you 
> don't have the knowledge or experience.

Oh, so I'm stupid now? That's nice. :-P


Post a reply to this message

From: nemesis
Subject: Re: Compiling stuff
Date: 17 Dec 2008 11:59:55
Message: <4949300b$1@news.povray.org>
Jim Henderson escreveu:
> On Mon, 15 Dec 2008 22:21:04 -0600, Mueen Nawaz wrote:
>> 	Why is that unfortunate?
> 
> I wondered that as well.  I may not like using Windows, but that doesn't 
> mean that those users should be forced to a particular platform for OSS 
> applications.  That's a Microsoft attitude. <g> <scnr>

Because they can act all hypocrite and diss free software while also 
taking advantage of it in their closed platform.


Post a reply to this message

From: Darren New
Subject: Re: Compiling stuff
Date: 17 Dec 2008 12:07:34
Message: <494931d6$1@news.povray.org>
Jim Henderson wrote:
> The language may be, but that doesn't mean the libraries are.  Building 
> cross-platform applications using C# isn't very easy to do if things like 
> Winforms aren't ported to the platforms in question.

Nah. You put a layer above it that abstracts out the OS-specific 
information. It's no harder to build cross-platform applications in an OOP 
language because of windowing than it is because of different file systems. 
Java managed it. Tcl managed it. Nobody needs to run X on Windows to support 
either of those.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.


Post a reply to this message

From: Darren New
Subject: Re: Compiling stuff
Date: 17 Dec 2008 12:09:58
Message: <49493266$1@news.povray.org>
Jim Henderson wrote:
> but once you 
> do, those drivers get downloaded and installed automatically.

For you, maybe.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.


Post a reply to this message

From: Darren New
Subject: Re: Compiling stuff
Date: 17 Dec 2008 12:12:07
Message: <494932e7$1@news.povray.org>
Mueen Nawaz wrote:
> 	Gnucash is what I use, and it has matured quite a bit since I first
> tried. But still, no (serious) budgeting capability.

Does it do both double and single entry bookkeeping (in different files, 
obviously)?  Does it download statements from your bank?  Does it export to 
tax preparation software?

Those are the features I need. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.


Post a reply to this message

From: Darren New
Subject: Re: Compiling stuff
Date: 17 Dec 2008 12:28:54
Message: <494936d6$1@news.povray.org>
Darren New wrote:
>> things like Winforms aren't ported to the platforms in question.
> 
> Nah. You put a layer above it that abstracts out the OS-specific 
> information. 

Or, you implement winforms. There's virtually nothing in winforms that is 
platform-specific.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.