I can confirm gdamore's authorship of the parent post. Anyone trying to understand his statement on ogb-discuss that was linked should read the preceding messages in the thread. A transcript of IRC discussion of this article is available here (search for "slashdot"): http://echelog.matzon.dk/logs/browse/opensolaris/1271368800
ScummVM, a virtual machine that runs games developed for LucasArts' SCUMM engine, has been adding support lately for older games (Putt-Putt, Freddi Fish, etc.) released by Humongous Entertainment. (http://www.scummvm.org/demos.php has some examples).
ScummVM is extremely portable and runs on everything from most unix systems to game consoles and palmtops.
As for zlib (remember that some copyright noticed may have been removed): [trisk@kainga:/vfat/windows]% find . -type f -print | xargs strings -f 2>/dev/null | grep '[di].flate' ./system32/dllcache/vgx.dll: 4,f deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly ./system32/dllcache/vgx.dll: f,f inflate 1.1.3 Copyright 1995-1998 Mark Adler ./system32/offfilt.dll: inflate 1.0.4 Copyright 1995-1996 Mark Adler ./system32/pngfilt.dll: i inflate 1.0.4 Copyright 1995-1996 Mark Adler ./system32/urlmon.dll: PROTOCOLS\Filter\deflate ./system32/urlmon.dll: Accept-Encoding: gzip, deflate ./system32/urlmon.dll: Accept-Encoding: gzip, deflate ./system32/QuickTime.qts: inflate 1.0.4 Copyright 1995-1996 Mark Adler
vgx.dll and offfilter.dll are probably MS Office libs. (inflate(), deflate() are zlib functions, btw). QuickTime.qts is just shown since it's also interesting.
How does BSD prevent this problem where Linux can not? I'm genuinely curious as I am not a BSD user.
I think you're referring to OpenBSD releasing with a patched version of zlib that had already taken care of this vulnerability, probably incidentally. This only occurred on OpenBSD, AFAIK.
strings will display ASCII strings embedded in a binary.
With the additional '--print-file-name' option for the GNU binutils version, it's even more useful.
From Windows NT 5.0: [trisk@kainga:/vfat/windows/system32]% strings --print-file-name *.exe | grep 'Berkeley'
nslookup.exe: @(#)nslookup.c 5.39 (Berkeley) 6/24/90
nslookup.exe: @(#)commands.l 5.13 (Berkeley) 7/24/90
nslookup.exe: @(#)debug.c 5.22 (Berkeley) 6/29/90
nslookup.exe: @(#)list.c 5.20 (Berkeley) 6/1/90
nslookup.exe: @(#)subr.c 5.22 (Berkeley) 8/3/90
nslookup.exe: @(#)skip.c 5.9 (Berkeley) 8/3/90
nslookup.exe: @(#)getinfo.c 5.22 (Berkeley) 6/1/90
nslookup.exe: @(#)send.c 5.17 (Berkeley) 6/29/90
[trisk@kainga:/vfat/windows/system32]% strings --print-file-name *.exe | grep 'Regents.*University of California'
finger.exe: @(#) Copyright (c) 1980 The Regents of the University of California.
ftp.exe: @(#) Copyright (c) 1983 The Regents of the University of California.
nslookup.exe: @(#) Copyright (c) 1985,1989 Regents of the University of California.
rcp.exe: @(#) Copyright (c) 1983 The Regents of the University of California.
rsh.exe: @(#) Copyright (c) 1983 The Regents of the University of California.
It is not a "Microsoft technology", but rather a technology that has support for creating software installation routines for Windows, amongst other OSes.
... that this "Multiplatform InstallShield" is a joke.
So, flame me if you want to, but you don't really get to lead a big software company by being dumb, u know?
Take a look at mms://a953.m.akastream.net/7/953/674/t030402_001/c netdemo.download.akamai.com/674/t030402_1600hi.asf - C/Net's clips of steveb from the deposition (ASF stream; use asfrecorder, or WMP in your case...).
In actuality, Linux itself is not GNU software (that is, part of the GNU project), so there's no real reason to name it differently. A GNU/Linux system, however, consists of Linux and the GNU utilities, in order to actually have a working OS.
>So why - oh - why do these client machines know >so much?
Here's why: When you have a multiplayer 3D game, it requires a considerable amount of data to be transferred over the network, particularly for something like a dialup connection. With, say, about 10% packet loss on these connections (and high latency), most multiplayer games would simply not work if the client had to request data at the exact moment it is needed. Most multiplayer game clients, for example, a QuakeWorld client, recieves information of unrevealed objects beforehand, so the client will be able to estimate their locations even with some packet loss.
>In particular, why does the video card know so >much? Are the programmers that lazy that they
>are trusting the video card to figure >everything out? Man, back in my day we had to?
>render each pixel. The video card knew only
>what we wanted it to know.
No, the programmers are not "lazy;" most of the type of games concerned use maps that are available on the client side. It's simply not feasible for the server to dynamically stream environment information to a client, nor for the video card to continuously flush the scene information and redraw...
All the driver does is basically make a surface transparent instead of drawing it. The drawing of the surfaces in the first place is handled by the driver, so it's not a problem with the game. There's not much you can do about it.
If you didn't know, the GPL does stand for the GNU General Public Licence. I suppose you've never licenced a program under it.;) It (GPL 2.0) begins thus: GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
Here is a copy of the Deutsch version of the document that was removed from microsoft.com. I read this one first ('twas posted to kde-devel). The Babelfish translation of it (which I read, as I can't read German well..) is rather amusing.
Actually, while theKompany.com has contributed significant applications to the KDE family, it is a relatively new company that was only incorporated last year, and in fact does not back the majority of KDE development. KDE's development is driven by the developers themselves and is primarily independant of theKompany.com.
I'm part of the KDE community; I do some development work for KDE (specifically, I've contributed to the KWebStat application), and am involved in the KDE Zine project, so I have reason believe that my views on this should be more or less accurate.
Well, does matter that Debian had Qt Xft AA two weeks ago? For your information, I have had Qt Xft since 3 months ago. But I'm not going to go about bragging that my distro got it before all the others. I'm not a Debian user. I use Linux, but I don't even use a distro. All I had to to was to get qt-copy from KDE CVS (i.e. cvs -d:pserver:anonymous@cvs.kde.org:/home/kde co qt-copy) and replace my current Qt with that. qt-copy will always have the latest Qt with fresh bugfixes and such, and was previously the only source for Xft AA in the latest Qt as th only other Xft source was the original 2.2.2 patch released by Keith Packard.
Hm, well, for one thing, running remote X apps using a 'real' native X server under Linux would be faster than using Exceed, and Netscape (unless you're sticking to 3.0 Gold) is surely not depedant, on Windows. So, only real reason you have to keep Windows for is *cough* Lotus Notes... Wait, I'm guessing this might be a machine at work... find a better job:P j/k
The article here may be slightly more informative in regards to the actual details of the workings of SafeAudio. Also, there were originally four different test versions of SafeAudio, as mentioned briefly in the transcript of a conference Macrovision had at Q3 2000.
Interestingly, a Greek company, MLS LaserLock, is also developing a copy-protection scheme called "AudioLock" according to this document. The possible infringement of LaserLock's trademark that may have occured here may explain the name change of Macrovision's product from AudioLock to SafeAudio.
This system does work fine for fairly complex circuitry, but I do not see how this technology, in its current state, or even within the next few years, could be suited for manufacturing anything with the complexity and operating conditions of a processor that is the equivalent of those in modern consumer desktops. The first problem is simply the scale of precision and cleaness required. Your average CPU uses a < 0.20 micron resolution (that's 200 nanometres, recent CPU's use as small as 130nm) manufacturing process that is only possible with very, very expensive specialised equipment following a time-consuming process under extremely clean conditions where dust cannot exist at all. Also, a large number of 3-dimensional structures will simply not be printable, and there is a very possible limitation of materials (it's not all just silicon...). Another issue is the working environment, which will have to be extremely clean as before, and areas of the processor approach very high temperatures which would undoubtably heavily damage the plastic. So, it looks like illegally downloading CPU's or any other complex electronics over the Internet won't be a common practice for a few decades to come.
By the time that exists, if ever, the English language (if it exists then) will have changed enough that no free subdomain Webhosting company will even consider capitalising on the up.uranus SLD.
Actually, it would be more appropriate to label that Motif, by the look of the widgets. It may or may not be *nix.
--
Re:I have had a fearful thought....
on
KDE 2.1 Is Out
·
· Score: 1
> Seriously, I'm impressed with those people's skills - I just wish they could build me some panels and applets...
> I'll switch if I like it now, or wait until they get more panels - or become a left-wing tree-huggin' dropout and not worry a bit about any of this;) We do live in interesting times - that's for sure
Well, you might be happy to know that since a month or so ago, KDE has had extensible child panels, the KasBar panel (which has been around for months, now, but now it's in the main distribution), and an app dock bar. Regarding applets, there are now about 15 various useful panel applets included with KDE, and notably, you can use any WindowMaker dock applet as well. In conclusion, there's no shortage of panels or applets for KDE.
Slashdot Mirror
I can confirm gdamore's authorship of the parent post. Anyone trying to understand his statement on ogb-discuss that was linked should read the preceding messages in the thread. A transcript of IRC discussion of this article is available here (search for "slashdot"): http://echelog.matzon.dk/logs/browse/opensolaris/1271368800
ScummVM, a virtual machine that runs games developed for LucasArts' SCUMM engine, has been adding support lately for older games (Putt-Putt, Freddi Fish, etc.) released by Humongous Entertainment. (http://www.scummvm.org/demos.php has some examples). ScummVM is extremely portable and runs on everything from most unix systems to game consoles and palmtops.
As for zlib (remember that some copyright noticed may have been removed):
./system32/dllcache/vgx.dll: 4,f deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly
./system32/dllcache/vgx.dll: f,f inflate 1.1.3 Copyright 1995-1998 Mark Adler
./system32/offfilt.dll: inflate 1.0.4 Copyright 1995-1996 Mark Adler
./system32/pngfilt.dll: i inflate 1.0.4 Copyright 1995-1996 Mark Adler
./system32/urlmon.dll: PROTOCOLS\Filter\deflate
./system32/urlmon.dll: Accept-Encoding: gzip, deflate
./system32/urlmon.dll: Accept-Encoding: gzip, deflate
./system32/QuickTime.qts: inflate 1.0.4 Copyright 1995-1996 Mark Adler
[trisk@kainga:/vfat/windows]% find . -type f -print | xargs strings -f 2>/dev/null | grep '[di].flate'
vgx.dll and offfilter.dll are probably MS Office libs. (inflate(), deflate() are zlib functions, btw). QuickTime.qts is just shown since it's also interesting.
strings will display ASCII strings embedded in a binary.
With the additional '--print-file-name' option for the GNU binutils version, it's even more useful.
From Windows NT 5.0:
[trisk@kainga:/vfat/windows/system32]% strings --print-file-name *.exe | grep 'Berkeley'
nslookup.exe: @(#)nslookup.c 5.39 (Berkeley) 6/24/90
nslookup.exe: @(#)commands.l 5.13 (Berkeley) 7/24/90
nslookup.exe: @(#)debug.c 5.22 (Berkeley) 6/29/90
nslookup.exe: @(#)list.c 5.20 (Berkeley) 6/1/90
nslookup.exe: @(#)subr.c 5.22 (Berkeley) 8/3/90
nslookup.exe: @(#)skip.c 5.9 (Berkeley) 8/3/90
nslookup.exe: @(#)getinfo.c 5.22 (Berkeley) 6/1/90
nslookup.exe: @(#)send.c 5.17 (Berkeley) 6/29/90
[trisk@kainga:/vfat/windows/system32]% strings --print-file-name *.exe | grep 'Regents.*University of California'
finger.exe: @(#) Copyright (c) 1980 The Regents of the University of California.
ftp.exe: @(#) Copyright (c) 1983 The Regents of the University of California.
nslookup.exe: @(#) Copyright (c) 1985,1989 Regents of the University of California.
rcp.exe: @(#) Copyright (c) 1983 The Regents of the University of California.
rsh.exe: @(#) Copyright (c) 1983 The Regents of the University of California.
Take a look at
mms://a953.m.akastream.net/7/953/674/t030402_001/
- C/Net's clips of steveb from the deposition (ASF stream; use asfrecorder, or WMP in your case...).
Wow, just 1 minute after. Amazing coincidence.
That adds up to about $92.
www.forked.net has been /.'ed, but I managed to mirror the first 4 pages of the article.
They are available at: kainga.quasarnet.org/~trisk/icrap/
In actuality, Linux itself is not GNU software (that is, part of the GNU project), so there's no real reason to name it differently. A GNU/Linux system, however, consists of Linux and the GNU utilities, in order to actually have a working OS.
>So why - oh - why do these client machines know >so much? Here's why: When you have a multiplayer 3D game, it requires a considerable amount of data to be transferred over the network, particularly for something like a dialup connection. With, say, about 10% packet loss on these connections (and high latency), most multiplayer games would simply not work if the client had to request data at the exact moment it is needed. Most multiplayer game clients, for example, a QuakeWorld client, recieves information of unrevealed objects beforehand, so the client will be able to estimate their locations even with some packet loss. >In particular, why does the video card know so >much? Are the programmers that lazy that they >are trusting the video card to figure >everything out? Man, back in my day we had to? >render each pixel. The video card knew only >what we wanted it to know. No, the programmers are not "lazy;" most of the type of games concerned use maps that are available on the client side. It's simply not feasible for the server to dynamically stream environment information to a client, nor for the video card to continuously flush the scene information and redraw...
--
All the driver does is basically make a surface transparent instead of drawing it. The drawing of the surfaces in the first place is handled by the driver, so it's not a problem with the game. There's not much you can do about it.
--
If you didn't know, the GPL does stand for the GNU General Public Licence. I suppose you've never licenced a program under it. ;) It (GPL 2.0) begins thus:
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
--
Here is a copy of the Deutsch version of the document that was removed from microsoft.com. I read this one first ('twas posted to kde-devel). The Babelfish translation of it (which I read, as I can't read German well..) is rather amusing.
--
Apparently, something is up with Microsoft's marketing department - just take a look at this image: http://kainga.quasarnet.org/~trisk/images/hm-1.png
--
Btw, I use KDE as my desktop of choice in Solaris.
--
Actually, while theKompany.com has contributed significant applications to the KDE family, it is a relatively new company that was only incorporated last year, and in fact does not back the majority of KDE development.
KDE's development is driven by the developers themselves and is primarily independant of theKompany.com.
I'm part of the KDE community; I do some development work for KDE (specifically, I've contributed to the KWebStat application), and am involved in the KDE Zine project, so I have reason believe that my views on this should be more or less accurate.
--
Well, does matter that Debian had Qt Xft AA two weeks ago? For your information, I have had Qt Xft since 3 months ago. But I'm not going to go about bragging that my distro got it before all the others. I'm not a Debian user. I use Linux, but I don't even use a distro. All I had to to was to get qt-copy from KDE CVS (i.e. cvs -d :pserver:anonymous@cvs.kde.org:/home/kde co qt-copy) and replace my current Qt with that. qt-copy will always have the latest Qt with fresh bugfixes and such, and was previously the only source for Xft AA in the latest Qt as th only other Xft source was the original 2.2.2 patch released by Keith Packard.
--
Hm, well, for one thing, running remote X apps using a 'real' native X server under Linux would be faster than using Exceed, and Netscape (unless you're sticking to 3.0 Gold) is surely not depedant, on Windows. So, only real reason you have to keep Windows for is *cough* Lotus Notes... Wait, I'm guessing this might be a machine at work... find a better job :P j/k
--
The article here may be slightly more informative in regards to the actual details of the workings of SafeAudio. Also, there were originally four different test versions of SafeAudio, as mentioned briefly in the transcript of a conference Macrovision had at Q3 2000.
Interestingly, a Greek company, MLS LaserLock, is also developing a copy-protection scheme called "AudioLock" according to this document. The possible infringement of LaserLock's trademark that may have occured here may explain the name change of Macrovision's product from AudioLock to SafeAudio.
--
This system does work fine for fairly complex circuitry, but I do not see how this technology, in its current state, or even within the next few years, could be suited for manufacturing anything with the complexity and operating conditions of a processor that is the equivalent of those in modern consumer desktops. The first problem is simply the scale of precision and cleaness required. Your average CPU uses a < 0.20 micron resolution (that's 200 nanometres, recent CPU's use as small as 130nm) manufacturing process that is only possible with very, very expensive specialised equipment following a time-consuming process under extremely clean conditions where dust cannot exist at all. Also, a large number of 3-dimensional structures will simply not be printable, and there is a very possible limitation of materials (it's not all just silicon...). Another issue is the working environment, which will have to be extremely clean as before, and areas of the processor approach very high temperatures which would undoubtably heavily damage the plastic. So, it looks like illegally downloading CPU's or any other complex electronics over the Internet won't be a common practice for a few decades to come.
--
By the time that exists, if ever, the English language (if it exists then) will have changed enough that no free subdomain Webhosting company will even consider capitalising on the up.uranus SLD.
--
Actually, it would be more appropriate to label that Motif, by the look of the widgets. It may or may not be *nix.
--
> Seriously, I'm impressed with those people's skills - I just wish they could build me some panels and applets... > I'll switch if I like it now, or wait until they get more panels - or become a left-wing tree-huggin' dropout and not worry a bit about any of this ;) We do live in interesting times - that's for sure
Well, you might be happy to know that since a month or so ago, KDE has had extensible child panels, the KasBar panel (which has been around for months, now, but now it's in the main distribution), and an app dock bar. Regarding applets, there are now about 15 various useful panel applets included with KDE, and notably, you can use any WindowMaker dock applet as well. In conclusion, there's no shortage of panels or applets for KDE.
--