On Tue, 16 Dec 2008 09:20:47 +0000, Invisible wrote:

> Jim Henderson wrote:
> 
>>>> Text mode X11 configuration apps have been around for a while, longer
>>>> than sax2, in fact.
>>> ...which is of no help whatsoever if you can't *find* them.
>> 
>> http://letmegooglethatforyou.com/?q=x11+text+mode+configuration
> 
> ...which again requires Internet access.

...which you happen to have, otherwise you wouldn't be reading this 
message, would you?

>>> (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?

>> Tux Racer has been around for dog's ages (the last *update* is 7 years
>> ago, in fact).  "Not much" isn't a good assessment unless you've bought
>> into the FUD.
> 
> I guess for a suitable definition of "not much" you could argue it
> doesn't apply. After all, 3 is greater than 4 for sufficiently large 3.
> :-P

It's not 6, let's put it that way.  It's a number significantly larger 
than 6.  Go up to freshmeat.net and do a search on "games" and see how 
many hits you get.  That's a *start*.  Go look at the online repositories 
for OSS games for openSUSE, Fedora, Ubuntu, etc.  That's a start.

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.

>>> Weirdly, almost all of Valve's games run on Linux - or rather, the
>>> GAME SERVER runs on Linux. The clients are Windows-only. (In fairness,
>>> what does a game server do? It sends and receives UPD datagrams. Can't
>>> be *that* hard to port it. Drawing 3D graphics is another matter...)
>> 
>> Not if you use a crossplatform library like openGL or Mesa.  Plenty of
>> people write games that use those libraries.
> 
> Both of those only support graphics. A game also needs sound, complex
> keyboard access, realtime control, etc., all of which varies by
> platform.

And there are open alternatives to DirectSound or whatever it's called.  
Sheesh, you talk about 3D graphics so I answer it, and then you conflate 
graphics with sound.  There are standard libraries that work 
crossplatform for that at a reasonable spead.  OpenAL for sound, for 
example.

> 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.  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.

>>> So you've got several GB of data, and you can only pick apart a few
>>> dozen bytes of it per day. Sure, shouldn't take long.
>> 
>> It's not about the complexity, it's about the concept.  And the tools.
> 
> Of course, why would complexity be any obsticle to comprehending
> something?

It shouldn't be an obstacle to trying to comprehend it.  I just pulled 
down about 300 MB of source code for a product my employer develops.  It 
would take me a year to study it enough to be able to develop code for 
it, and it's not part of my job.  But that doesn't stop me from using 
Source Navigator NG3 (a really cool program for code analysis - and BTW 
it's GPL'ed software) and looking at specific issues through the lens of 
the source code.  It's a chance to learn.

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.

<joke>I thought Americans were the only ones who looked for instant 
gratification.  <sigh> </joke>

>> Reverse-engineering is not generally illegal.
> 
> Sure. The fact that the EULA says "you may not reverse engineer this"
> doesn't make it illegal at all. No sir.

EULAs are AFAIK not court-tested, and are highly suspect in their "shrink-
wrap" or "click-wrap" form.  So yes, doing reverse engineering even after 
being forced to agree to an EULA is not generally illegal.  It may be a 
violation of the terms of the license if the license is upheld in court.

There is a *huge* difference there, and local laws may vary.  For 
example, in Germany, I think you'll find that reverse-engineering is 
generally accepted as standard practice and no German court would enforce 
an EULA that prohibited it.  In China, well, you're in China.  The 
government is pretty well known to sanction reverse-engineering of all 
sorts of things, from aircraft airfoils to software to painting equipment.

>> In that, you have one team that determines the specs.  You compile a
>> specification for those functions.
>> 
>> Then you turn the specifications over to a second team that has not
>> looked at the code for the original and have them reimplement it.
> 
> Given how painfully difficult it is just working out how to *use* the
> Win32 API, the chances of somebody correctly implementing a clone of it
> seem vanishingly small. (Especially given the vast sea of software that
> intimately depends on undocumented functionallity, glitches and the
> like.) Also, I hear that various M$ products depend on entire APIs which
> are kept "secret".

Difficult for you != difficult for everyone on the planet.  'nuff said.

>> That's how we ended up with clone PCs - clean room reverse engineering
>> of IBM's BIOS.
> 
> Because the BIOS *totally* has the same complexity level as an entire OS
> with 20 years of backwards compatibility.

<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.

>> Have a look at WINE's FAQ about Windows patents and whatnot.  You'll
>> learn a lot.
> 
> 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.  The developers of Mono were originally denied access to the 
Microsoft Professional Developer's Conference, but Microsoft *couldn't* 
prosecute them.  The project leads work for Novell so they do benefit 
(again, I understand) from the agreement between Microsoft and Novell, so 
the threat isn't really there now, but the development model hasn't 
changed just in case the agreement does change.

Same with Moonlight (a Silverlight-compatible clone, written in Mono 
IIRC).

Etc, etc, etc - there are plenty of examples out there.

So please stop saying "it's impossible!" when clearly it isn't because 
it's being done.

Jim

Post a reply to this message