Incidentally, what would the difference(s) be between OpenStep's Display Postscript and OSX's Display PDF (Quartz) tech? Anyone know the relative pros/cons, how either one stacks up against the other, etc.?
Methinks the xdps component may see a surge of interest, with all these tantalizing reports of what OSX can do with dynamic scaling and alpha-channelling....
Having a L-shaped title bar would mean less space to see what's behind the window, or to maximize the window, for a relatively minor gain in functionality. I believe the Mac's click-to-focus mode doesn't pass through the focusing click...
What bothers me about the Mac/OSX design is the dearth of resize bars. I might be spoiled from using fvwm2 with an ungodly high BorderWidth value, but anything that doesn't allow full eight-way window resizing comes up short for me.
That domain (used to) belong to the #linuxwarez bunch, and had a nice little site, with some IRC news and (non-warez) downloads. But this-- this is disgusting.
And to add insult to injury, they have a topless lady right on the fscking front page!! Ghods, a domain desecrated. Whatever happened to #linuxwarez, anyway?
Well, there is the issue of certification. IIRC, the way SGI certifies an OpenGL implementation involves a hefty conformance testing suite, and the seal of approval is specific to the hardware and binaries (no recompilation!) involved. Possibly a few developers are uneasy at the thought of users rebuilding their libGL/libGLU objects?:P
Aside from that, I think it would be a real shame if they were to ignore the excellent codebase found in Mesa. It's all but certain that the Mesa code is better designed. Someone here on/. once posted that the Mesa implementation is actually faster than SGI's (when hardware acceleration is taken out of the picture) as far as texture-mapping is concerned, which would be a win for Linux gaming. (Conversely, a followup posting mentioned SGI's implementation is probably better optimized for rendering huge polysets anyway).
If, for some reason a court would declare the GPL invalid, in whole or in part, what would this mean to Linux and the rest of the free software community?
Programs under the GPL would revert to standard copyright under its authors. I believe this would automatically bring into force the usual restrictions on copying and distribution (i.e. prohibited without author's permission, etc.). No one will suddenly be able to turn emacs or gcc proprietary; quite the opposite-- until a valid license is put on some [formerly GPL'ed] package, no one will be legally able to even download it.
The scenario, I imagine, would go something like this:
GPL v2 is declared invalid
The top guns at the FSF draft a new GPL in line with the legal opinion, and true to the spirit of the previous version
Release GPL v3
Free-software maintainers the world over update the COPYING file in their tarballs, using the "either version 2 of the License, or (at your option) any later version" provision, or in the worse case, after checking with everyone in AUTHORS
So it would certainly cause a lot of hubbub (gnu.misc.discuss and debian-legal would go berzerk, that's for sure), but in the end, people will just patch the bug, and get on with business as usual. And the new GPL will be that much harder against future legal challenges.
Can anybody comment(guess) on how much it adds to dev time to do a port/do 2 OSes on avg?
It's all a matter of how you go about writing the code. idsoftware takes a really modular approach, keeping all the system-dependent stuff separate, and voila! They release stuff for Linux and Mac just as easily as Windows. The only extra work should be the view/controller portion, and that's probably one place where you can reuse a lot of code from earlier games.
The problem are the game companies that use Win32 and all the DirectWhatever goodies MSoft has to offer. Very powerful, yet very complex and definitely non-portable stuff. I haven't coded for Windows, but from what I've heard, the API was not designed to be easily implemented on other systems (without basically re-implementing a good part of Windows itself).
The enlightened game developer will probably want to have a look at ClanLib and SDL, which address this problem quite nicely. (Maybe not completely, but at least they're a start). I hope the ultra-portable game libs in that vein catch on.
Linux on MIPS has never been a priority for them. Remember, SGI is shifting all their operations to Linux on Intel (not all at once, but that's the direction they're headed). It doesn't make any sense (for them) to port Linux to MIPS-- they already have IRIX for those machines.
In any case, don't forget that a lot of people within SGI like Linux a lot, and are very enthusiastic about working professionally with it. Given SGI's creativity-powerhouse culture, it makes perfect sense. I think Linux has a very good friend in SGI.
Not that that would leave you with much hope for Linux on your machine, but hey-- IRIX's cc is awesome for debugging (with -fullwarn). What other compiler will tell you "variable foo was set but never used?"
You've definitely got something there. Granted, GTK+ may be much farther along (nevermind the C++ Qt), but it doesn't aim for the same level of portability. Not to mention its syntax is (*ahem*) a bit on the heavy side. If Ng's portability can be extended to BeOS and Win32 (putting it on par with the previously mentioned C++ toolkits), and the syntax is more elegant than GTK+'s, it may very well be capable of a life of its own.
Even if you don't open the source to PG, it can't hurt to place Ng under LGPL. If it's really good, it'll take off. If not, well... should you ever release another Ng app, the binaries won't have to be statically compiled;-)
Even if the app itself isn't open-source, I sure wouldn't mind having a look at Ng. Check out this little blurb:
Internally, Photogenics is based on my Ng user interface toolkit, and avoids calling any OS specific functions. Ng itself sits on top of a small OS abstraction layer, which either maps directly to AmigaOS functions, or uses Posix for thread related functions, and Xlib for display. With this abstraction layer in place, Photogenics will soon become platform agnostic. With 99.9% of the Photogenics source code remaining unchanged across ports, no platform will get left behind when it comes to new versions. An Amiga NG version should not be a problem, and QNX aficionados will be pleased to know that Photogenics will port over with only trivial changes
'Course, if this is a C++ show, it won't be anything new (cf. FOX, wxWindows et. al.) Still, that level of portability gives me goosebumps }:-)
This is exactly what I was thinking. It's perfect for getting your code 64-bit clean, not to mention you get to squash all warnings on yet *another* compiler:-)
Can you re-register after the 30 days, however? It'd sure be nice to keep those Alpha binaries up to date....
Anyway, while it should be possible to come up with a new, unpatented color-matching system, I'd imagine there would be two problems:
- It would be very VERY costly to develop (esp. if it's to be on par with Pantone), and - Then you have to convince almost every graphic designer in the world to switch. (Compatibility is good, but 100% is unlikely, methinks)
The solution I've heard mentioned is for someone to produce a non-free [binary?] Gimp plug-in. I think this will happen someday, once the app has matured enough to raise eyebrows among professional artists. (Still need CYMK support!)
So this means *all* BSD code out there has the advertising clause nullified? e.g. if I had source for an old 4.4 utility, BSD+advert licensed, that has been sitting on my hard drive for the last ten years, then that code can now be used without the advert clause? Coolers!
Would this also apply, then, to other non-BSD-UNIX yet BSD+advert-licensed software out there? Or would the authors of these programs have to re-release their source with the updated license?
Well, speaking as someone who has eaten bugs (giant roasted ants*, specifically), I can say they're not nearly as bad as many people think they are. They just have to be prepared the right way. (Biting into a live/raw locust is *not* something I would want to do in this lifetime:-)
* - They taste...weird. But not bad. There's just nothing to compare the taste to. Heck, some of you would probably find Twizzlers less palatable...
There's Cygwin, as Stonehand suggested-- which would probably be the best choice if you're porting a Unix-native app (there's a runtime library that the compiled programs will need, that provides the Unix services missing from Windows).
If you want to write Windows-native apps, however, using the Win32 API and linked to the standard Windows libraries, Mingw32 is the one to go with. It's a GCC port, IIRC, rewritten to work with Windows.
You might want to have a look at LCCWIN, but I'm not sure what the tradeoffs are with that one. All I know is that it's popular for compiling Quake plug-ins:-)
Don't forget why there are going this route to begin with. SGI loves Linux, not (just) because it's the buzzword of the year, but because the system is open, and SGI has a lot more creative control over it.
Remember that cool quote by an SGI exec: "With NT, you are really limited in terms of the value you can add to the system" (or words to that effect). That basically sums it up in a nutshell.
(P.S.: "Value you can add" != "proprietary extensions". Check out the position paper SGI put out today. They're very gung-ho about not balkanizing Linux, just making the best damn hardware/software combination ever)
WinNT strategy: You can get a box with Linux, and install NT over it. But why would you want to hobble your k-rad SGI hardware like that?
(j/k)
Seriously, however, they'll still be offering NT. There's still a lot of demand for it-- lotta Microsoft-only shops out there-- and it'd be foolish to turn down that customer base.
Look at it this way: The money they make selling NT solutions will help them develop even better Linux solutions };-)
Would this be the one with Intel's new IA32 backend? It'll be great to finally see gcc kick VC++ butt on x86 binary quality. I'm getting this strange urge to recompile everything -O9 -mpentium }:-)
Slashdot Mirror
Incidentally, what would the difference(s) be between OpenStep's Display Postscript and OSX's Display PDF (Quartz) tech? Anyone know the relative pros/cons, how either one stacks up against the other, etc.?
Methinks the xdps component may see a surge of interest, with all these tantalizing reports of what OSX can do with dynamic scaling and alpha-channelling....
Having a L-shaped title bar would mean less space to see what's behind the window, or to maximize the window, for a relatively minor gain in functionality. I believe the Mac's click-to-focus mode doesn't pass through the focusing click...
What bothers me about the Mac/OSX design is the dearth of resize bars. I might be spoiled from using fvwm2 with an ungodly high BorderWidth value, but anything that doesn't allow full eight-way window resizing comes up short for me.
And they've got linuxwarez.org too!
That domain (used to) belong to the #linuxwarez bunch, and had a nice little site, with some IRC news and (non-warez) downloads. But this-- this is disgusting.
And to add insult to injury, they have a topless lady right on the fscking front page!! Ghods, a domain desecrated. Whatever happened to #linuxwarez, anyway?
Well, there is the issue of certification. IIRC, the way SGI certifies an OpenGL implementation involves a hefty conformance testing suite, and the seal of approval is specific to the hardware and binaries (no recompilation!) involved. Possibly a few developers are uneasy at the thought of users rebuilding their libGL/libGLU objects? :P
/. once posted that the Mesa implementation is actually faster than SGI's (when hardware acceleration is taken out of the picture) as far as texture-mapping is concerned, which would be a win for Linux gaming. (Conversely, a followup posting mentioned SGI's implementation is probably better optimized for rendering huge polysets anyway).
Aside from that, I think it would be a real shame if they were to ignore the excellent codebase found in Mesa. It's all but certain that the Mesa code is better designed. Someone here on
The scenario, I imagine, would go something like this:
- GPL v2 is declared invalid
- The top guns at the FSF draft a new GPL in line with the legal opinion, and true to the spirit of the previous version
- Release GPL v3
- Free-software maintainers the world over update the COPYING file in their tarballs, using the "either version 2 of the License, or (at your option) any later version" provision, or in the worse case, after checking with everyone in AUTHORS
So it would certainly cause a lot of hubbub (gnu.misc.discuss and debian-legal would go berzerk, that's for sure), but in the end, people will just patch the bug, and get on with business as usual. And the new GPL will be that much harder against future legal challenges.It's all a matter of how you go about writing the code. idsoftware takes a really modular approach, keeping all the system-dependent stuff separate, and voila! They release stuff for Linux and Mac just as easily as Windows. The only extra work should be the view/controller portion, and that's probably one place where you can reuse a lot of code from earlier games.
The problem are the game companies that use Win32 and all the DirectWhatever goodies MSoft has to offer. Very powerful, yet very complex and definitely non-portable stuff. I haven't coded for Windows, but from what I've heard, the API was not designed to be easily implemented on other systems (without basically re-implementing a good part of Windows itself).
The enlightened game developer will probably want to have a look at ClanLib and SDL, which address this problem quite nicely. (Maybe not completely, but at least they're a start). I hope the ultra-portable game libs in that vein catch on.
There'd be no point to that. If any cracker cared, (s)he could get the same result by telnetting to port 80 and using queso.
;-)
Then again, if they find out you're running OpenBSD, they might just give it up a priori
Thanks for the hint!
USER> Is there a god?
(a few moments pass, processing request...)
COMPUTER> THERE IS NOW
Linux on MIPS has never been a priority for them. Remember, SGI is shifting all their operations to Linux on Intel (not all at once, but that's the direction they're headed). It doesn't make any sense (for them) to port Linux to MIPS-- they already have IRIX for those machines.
In any case, don't forget that a lot of people within SGI like Linux a lot, and are very enthusiastic about working professionally with it. Given SGI's creativity-powerhouse culture, it makes perfect sense. I think Linux has a very good friend in SGI.
Not that that would leave you with much hope for Linux on your machine, but hey-- IRIX's cc is awesome for debugging (with -fullwarn). What other compiler will tell you "variable foo was set but never used?"
This should do the trick.
/mnt/cdrom
mount -t iso9660 -o ro,loop=/dev/loop0 corel_cd.iso
Thanks for replying :-)
;-)
You've definitely got something there. Granted, GTK+ may be much farther along (nevermind the C++ Qt), but it doesn't aim for the same level of portability. Not to mention its syntax is (*ahem*) a bit on the heavy side. If Ng's portability can be extended to BeOS and Win32 (putting it on par with the previously mentioned C++ toolkits), and the syntax is more elegant than GTK+'s, it may very well be capable of a life of its own.
Even if you don't open the source to PG, it can't hurt to place Ng under LGPL. If it's really good, it'll take off. If not, well... should you ever release another Ng app, the binaries won't have to be statically compiled
Even if the app itself isn't open-source, I sure wouldn't mind having a look at Ng. Check out this little blurb:
Internally, Photogenics is based on
my Ng user interface toolkit, and avoids calling any OS specific
functions. Ng itself sits on top of a small OS abstraction layer, which
either maps directly to AmigaOS functions, or uses Posix for thread
related functions, and Xlib for display. With this abstraction layer in
place, Photogenics will soon become platform agnostic. With 99.9% of
the Photogenics source code remaining unchanged across ports, no
platform will get left behind when it comes to new versions. An Amiga
NG version should not be a problem, and QNX aficionados will be
pleased to know that Photogenics will port over with only trivial
changes
'Course, if this is a C++ show, it won't be anything new (cf. FOX, wxWindows et. al.) Still, that level of portability gives me goosebumps }:-)
This is exactly what I was thinking. It's perfect for getting your code 64-bit clean, not to mention you get to squash all warnings on yet *another* compiler :-)
Can you re-register after the 30 days, however? It'd sure be nice to keep those Alpha binaries up to date....
This is too weird... I just have two questions:
1. (dumb one) How was this thing getting its TCP/IP? Ethernet port, serial PPP, what?
2. Doesn't the Dreamcast run WinCE?
You might want to start here :-)
Anyway, while it should be possible to come up with a new, unpatented color-matching system, I'd imagine there would be two problems:
- It would be very VERY costly to develop (esp. if it's to be on par with Pantone), and
- Then you have to convince almost every graphic designer in the world to switch. (Compatibility is good, but 100% is unlikely, methinks)
The solution I've heard mentioned is for someone to produce a non-free [binary?] Gimp plug-in. I think this will happen someday, once the app has matured enough to raise eyebrows among professional artists. (Still need CYMK support!)
So this means *all* BSD code out there has the advertising clause nullified? e.g. if I had source for an old 4.4 utility, BSD+advert licensed, that has been sitting on my hard drive for the last ten years, then that code can now be used without the advert clause? Coolers!
Would this also apply, then, to other non-BSD-UNIX yet BSD+advert-licensed software out there? Or would the authors of these programs have to re-release their source with the updated license?
It's already waaay ahead of where Mozilla started out. But I still shudder to think of the AMOUNT of source code that will have:
:-]
-rw-r--r-- 1 straker skunk 147813223 Mar 11 2000 soffice-5.2.tar.gz
I swear, that sucker's going to make the XFree86 source tarballs look manageable
I heard somewhere there was a female counterpart to Chu-- er, Beastie... could anyone confirm? Are there pics anywhere?
(Dangit, I'd really like to be able to say of my FreeBSD box, "She runs solid as a rock!")
Just pick up two copies of OS/2.
Well, speaking as someone who has eaten bugs (giant roasted ants*, specifically), I can say they're not nearly as bad as many people think they are. They just have to be prepared the right way. (Biting into a live/raw locust is *not* something I would want to do in this lifetime :-)
* - They taste...weird. But not bad. There's just nothing to compare the taste to. Heck, some of you would probably find Twizzlers less palatable...
There's Cygwin, as Stonehand suggested-- which would probably be the best choice if you're porting a Unix-native app (there's a runtime library that the compiled programs will need, that provides the Unix services missing from Windows).
:-)
If you want to write Windows-native apps, however, using the Win32 API and linked to the standard Windows libraries, Mingw32 is the one to go with. It's a GCC port, IIRC, rewritten to work with Windows.
You might want to have a look at LCCWIN, but I'm not sure what the tradeoffs are with that one. All I know is that it's popular for compiling Quake plug-ins
Don't forget why there are going this route to begin with. SGI loves Linux, not (just) because it's the buzzword of the year, but because the system is open, and SGI has a lot more creative control over it.
Remember that cool quote by an SGI exec: "With NT, you are really limited in terms of the value you can add to the system" (or words to that effect). That basically sums it up in a nutshell.
(P.S.: "Value you can add" != "proprietary extensions". Check out the position paper SGI put out today. They're very gung-ho about not balkanizing Linux, just making the best damn hardware/software combination ever)
WinNT strategy: You can get a box with Linux, and install NT over it. But why would you want to hobble your k-rad SGI hardware like that?
(j/k)
Seriously, however, they'll still be offering NT. There's still a lot of demand for it-- lotta Microsoft-only shops out there-- and it'd be foolish to turn down that customer base.
Look at it this way: The money they make selling NT solutions will help them develop even better Linux solutions };-)
ObFanboyComment: GO GCC!!! :-D
Would this be the one with Intel's new IA32 backend? It'll be great to finally see gcc kick VC++ butt on x86 binary quality. I'm getting this strange urge to recompile everything -O9 -mpentium }:-)