A daemon that needs to bind to a port lower than 1024 must run as root
Actually, it has to be launched as root, so it can bind() to the privileged port (or do whatever it's required to do as root), but then it can setgid() and setuid() itself to act as a less powerful user/group (i.e. nobody) with limited access.
Am I wrong when I thing the media industry is using an old tactic to force down the throat the introduction of copy prevention facilities?
Let's see it this way: mandatory copy prevention mechanisms are just a pain in the ass for user and manifacturers, and unreasonable as it is, I doubt it would ever be popular. OTOH, optional copy prevention mechanisms are somewhat less evil, but they can be as bad if they ever become widespread (i.e. try surfing the web with cookies disabled, as someone pointed out in another post).
Now thing are presented to the mass as if you have only two choices and you have to choose only between them. Basically, they are trying to force you to choose between something evil and a compromise. But when you are faced with two options there is always a third option: the status quo (no compromises at all).
Briefly: the media industry asked for 200 and obtained 0, the media industry now is asking for 100 (which is the goal of the media industry, and is less unreasonable than 200, but still unreasonabe). People accepting this compromise just because is less evil than what was originally proposed are just pawns the media's game.
The number of installed machines of HP/UX and Solaris is still quite high.
There is a problem with HP-UX installations: it doesn't scale really well downards (i.e. workstations). If you pick the popular HP 712 100 with 128Mb RAM you'll find it is completely unusable with HP-UX 11. With HP-UX 10.20 it is comparable with an old Pentium 133 (or worse). Emacs on it is quite slow.
Things get better on an HP B 180, which is comparable to a not-so-cutting-edge PC (now IIRC a B is the entry level), but it costs as a small car. Still, a x86 with FreeBSD/Linux/whatever feels definitively better.
I suspect (but I don't have numbers) that a large base of HP-UX systems run on 712 and B 180 workstations in telco companies (and obviously also companies developing software for telco operators).
The fact that HP is giving some help with the PA-RISC port of Linux (still in early stages) should lead to interesting considerations. I believe that HP is trying to focus only on big/medium iron (i.e. servers), while leaving its customers with a viable option (PA-RISC Linux) for workstations.
I also believe the same thing is happening with Solaris: there are several old Sparc workstations out there that can be brought to a new life using Sparc Linux.
That said, older Sparc and PA-RISC workstations could be an interesting niche for free unices to fill in, since they may help companies to earn more from their former investments in (pricy!) hardware. And once they are on the workstations, they can slowly crawl also to the servers.
So: after OS/X is "finished", a port of OS/X (the whole OS/X, not just Darwin) to Sparc and PA-RISC for low-end workstations could be interesting for Apple: it could start making inroads to the server market. Until the only hardware capable of running OS/X (again, the whole OS/X, not just the kernel and the *NIX utlities) is the one provided by Apple, the probabilities for OS/X to penetrate the server area (provided that Apple is interested at all) are smaller.
A port for not-so-popular architectures like Sparc or PA-RISC doesn't necessarily mean Apple cutting itself out of market: just look at the x86 port of Solaris: it helped people to buy the hardware where Solaris runs best.
When will SUN ship it's systems with a protocol a bit less bloated than X? (Ica?)
X is not the best in every situation, but if with "bloated" you mean "large bandwidth", I'd suggest you having a look at dxpc (Differential X Protol Compression).
If with "bloated" you mean it has a complex low-level API because of backwards compatiblity, well, it may be the case. But unless you are a toolkit developer, this shouldn't affect you
On the other end, if you just want ICA, you can buy Metaframe for Solaris from Citrix. But probably is not what you want.
The problem with X is that it usually is good enough (i.e. office applications on a 10Mbps LAN) and it can be extended, so competitors have to work really hard just to catch up.
There is also a large set of X application out there that must be supported, so a replacement should really also provide X compatibility (i.e. at least with a gateway X -> other protocol, like VNC server on *NIX).
Aladdin basically sells you the ability to use Ghostscript in a proprietary application, but the standard license just forbids to distribute GhostScript for money (if you are doing it for free, then no problem). So anyone may grab the very latest version of GS directly from Aladdin and use it. Just you can't ask for money when you distribute it (and that's why distributions include GNU GS, and not Aladdin's GS).
What I had in mind was really something more similar to what has been done with this localization of StarOffice (provided it could legally be done): would you purchase a localized StarOffice now, or would you wait six months?
Home users probably would wait six months, but corporate users? (I know, usually corporate users take months just to realize that there is a need at all for a certain product...).
Perhaps it's more like Trolltech did: buy Qt for Windows now (and use also in your proprietary application if you like), or wait for a free port from the UNIX version (sometimes in the future?).
Ok, Qt is a library, the free version is GPL and a Windows port would also be, so it's not the same as buying the commercial version. But think if it were LGPL'd instead... Or think to develope a proprietary extension to GTK+ (LGPL), with the promise (kept, because you want to play fair) of releasing it as LGPL after some time, and doing so again and again for each extension, on a regular base (instead of doint it occasionaly, like Sun or Netscape).
But then, it's only an idea... and I don't know if I'd like it.
Well, possible copyright infringiment issues apart, I have a genuine question wandering in my head.
First, a premise:
making money out of Free software is a bit harder that making money out of closed software: in the first case one can sell additional services (i.e. maintenace, ad hoc customizations, etc.), while in the latter one can also sell the use of the software in itself (because the sources are not available for one to compile and use them, or not legally usable/alterable/redistributable).
That said, could time-shifting be considered as a "service"?
Example: Joe spent some effort developing a nice application for which there could be some market space. Although Joe has no obligation problems to release it under a Free license (i.e. the libraries and the tools he used don't legally force him to release his code under a Free licence), Joe decide to sell its application as proprietary software, with the perspective of releasing the source with a Free license in (say) six months.
This would give Joe enough time to earn some money, and perhaps would please the Free software community because the software will be released under a Free license (let's assume that Joe keeps its promises).
Basically, Joe says "If you want it now and you are not interested in the source, please pay me. Otherwise, wait six months when you'll have everything Free for free".
My question is: would this be considered acceptable by the community? Instead of paying to "have the ability to use it in proprietary software", you'd pay it "to have it now". For some aspects, it's similar to the way Aladdin manages GhostScript, if I remember correctly.
(note: no, I'm not planning to do it this way, since I haven't such a "killer app", and if I had, I'd probably release it as Free software from the start, but I'd like an opinion on that).
I say I'm not exactly sure what you mean when you say "multiresolution editing"
Probably he means the image you are manipulating is only a preview of the image (smaller resolution), while editing operations on the "real" image are queued, so they can be performed later on the real image.
This would let you quickly edit an image using a lower resolution, and when you are satisfied with the result you could reapply the same operations on the final image (and go for a coffee or two).
This could be implemented using scripting, of course. Basically, what is needed is a way for the Gimp to record macros and then apply them on another versione of the same image (with more resolution).
Another possiblity would be to have the queued operations be performed in background while you are still editing.
In any case, it should be really useful:
if your machine is not fast enough:-)
if the images are really huge, so working on a preview is OK.
AFAIK, there is some work going on to separate the GIMP rendering engine from the GUI, so it can be integrated/reused in other programs). As a side effect, it could also allow doing this.
Just grab Gimp 1.1.30. It has what you ask, and works well.
You have paths (bezier curves), you can stroke them, modify them, and also convert arbitrary selection to bezier paths.
Paths can be easily exported/imported to/from textfiles, and creating a plugin to convert them to/from EPS should be simple (I'm making some experiments as now).
Ok, folks, no one really understanding how thing works here, eh?
Xt is a OO framework for developing objects in C and for managing message queues. Point. It does no rendering. At all. It's a library for developing toolkits, and it has some design problems. Did you know that when you set a property on a widget using Xt calls, a full copy of the structure representing the widget is required, thus affecting performance? Commercial widgets vendors implement specific calls for their widgets just to avoid the inefficiency of using applicatively the Xt calls to set properties on their widgets.
GTK+ is NOT based on Xt, it has its own object model. Want a proof? Take any GTK+ app, and do "ldd filename" on it to see what shared libraries it uses. Do you see libXt in there? No. QED.
Qt is NOT based on Xt, it doesn't need to be since it's a C++ toolkit. Another proof? Take any KDE app, do "ldd filename" on it, and search again for libXt. You won't find it.
GNOME libs actually are mostly utility libraries for what concerns GTK+. They avoid 300+ programmers writing the exact same code across all the applications that make up GNOME. This gives consistency, (and less bugs btw). It's not really another abstraction layer.
At the bottom there may be XLib (GDK is an abstraction layer for the drawing engine, and it can be ported to non-X platforms. Look at The Gimp for Windows). This is required, since it provides only the minimal functionalities to talk with an X server, and you'd have to reimplement all of it by yourself if you wanted to talk with an X server without using Xlib.
Finally, I'm wondering myself why the Windows port of GTK hasn't been used, since it's there and works fine. Perhaps some Gnome developer wanted raw access, and did raw XLib calls instead of GDK ones just to be "faster"? Well, now you need an X server until that "smartness" get fixed with appropriate GDK calls.
they can't take the Ghostscript route of being "free for non-commercial use
Just a note: Aladdin GhostScript is free (as in beer and partially as in speech) for commercial use. The limitation is that only Aladdin can charge money for distributing modifications to the source. Read it here.
After a certain amount of time, source is relicensed under GPL (and here we have GNU GhostScript), so Aladdin basically sells the fact it stays ahead in development, while also pleasing RMS (who, you'll agree with me, is not so easy to please).
Abisource developers could agree to do something similar in the future, and perhaps earn some money (provided people out there are willing to pay for creepy featurism).
About Framemaker: I use it for large technical documents (600+ pages on HP-UX) and I really like it. But for the use I make of FrameMaker, I could as well use LyX without any problem. Frames in FrameMaker are a nice plus over LyX, but you'll agree with me that you can't do serious DTP with them anyway, and they are mostly used exactly as LyX floats...
are they going to sign also.bat files, VB macros in Office/whatever, and scripts/programs executed by interpreters in general?
or are they going to eradicate all scripting/macro capabilities from installations destinated to lusers?
In the first case, it's pretty useless.
In the second case, while I recognize that the only automation tool that the typical luser knows of (and needs, because it's a luser) is his/hers hands doing the same thing over and over, there would be trouble even USING an Excel sheet requiring the execution of macros in order to work.
Servers shouldn't need such an extreme solution. Lusers are not supposed to put their finger on them, and scripting is usually needed on servers.
IMHO, in order to be effective, an implementation of such a solution as now would require severe redesigning of the way common apps works. I doubt it's an option.
lacking alpha blending: alpha blending (and font antialiasing) can be easily done by the user apps that require it - having the support directly in the X server is nice and desiderable (XFree86 4.x implements such extensions, so toolkits like Qt or GTK+ can start using them and providing nice API), but absolutely not required (The Gimp does alpha blending and antialiasing by itself, the same is true for Gnome Canvas and Swing of Java memories).
true type fonts: come on, please! There has been True Type font support for ages through appropriate X font servers. And you can easily have them along with Compugraphic fonts and the usual Adobe Type 1 (and more esotic sorts) by simply using an X font server. And graphic applications can smooth them by themselves (i.e. The Gimp, apps using the Gnome Canvas widget, GhostScript when rendering PostScript text, or Acrobat Reader - they all use antialiased fonts and graphics where they are required).
how could you present as work those ugly blochaveky fonts?: come on, please (again)! You can have all the vectorial fonts you want (even a hight-quality edition of the 35 standard PostScript fonts, search on Goole for URW fonts, but if you have GhostScript you probably have them already), and graphics programs can do antialiasing by themselves.
That said: X is not the best at everything, and color calibration is one of these. If there is enough interest, it will be implemented as an extension to the X protocol. Instead of bashing X, go after X implementors, like the XFree86 group, and ask or help them to properly design and implement such thing. Then you'll have fine color calibration in X.
The amount of unjustified X Window System bashing is amazing: while some design issues start to emerge now (13 years later), resolution indipendence is not one of them.
The toolkits applications are developed with (Athena, Motif, GTK+, Qt) compute the dimensions of widgets (buttons, textfields, etc.) on the dimensions of the text they contain.
The X servers know (or can be told) the DPI resolution of the display
One of the 14 fields of font names is used to choose font sizes in tenths of typographic points: this is interpolated with the known DPI resolution of the monitor to obtain an actual size in pixels.
Toolkits derived by Xt (Intrinsics) have a mechanism for the user to specify fonts for every class of widget via X resources (i.e. your ~/.Xdefaults file). Shortly, it works for every Athena or Motif application.
GTK+, which is not derived from Xt, has a nice ~/.gtkrc in which you can do the same thing (and you can do it from your Gnome control panel).
Qt, which is not derived from Xt, has a similar mechanism to specify font sizes.
Many complain that the Helvetica and Times fonts supplied with the X Window System are bitmapped. So what? Use Adobe Type 1 fonts (like Utopia), or TrueType fonts (Arial and Times New Roman), which are vectorial.
So, unless the GUI developer was moron and specified absolute dimensions for widgets, there is resolution indipendence. Just specify the size of your fonts in tenths of typographic points (the 8th field): the layout manager of the toolkit then will make your app equally usable at 640x400 and 1600x1200.
The real problem here is only with bitmaps: they have a hinerent size in pixels. Buttons containing only a bitmap won't scale (unless the developer arranges things specifically, i.e. scaling the bitmap to be n rows of text high).
Well, let's put it in this terms: it provides some functionalities allowing REAL web servers to be faster when it comes to serve static content. But of course you still need an httpd in userland using the functionalities above.
I don't know if Tux (the web server) is based on that, or if it implements its own in kernel.
If I understand it right, it's a good idea: optimal loop unrolling is performed in a different manner on different platform.
This way, you have the actual loop in the bytecode, which can be unrolled and translated very efficiently for the specific architecture.
While I believe that nothing could beat a human being when it come to coding to one specific architecture, I believe optimizers can do a damn good job when it comes to support several architectures. Example?
Take a simple loop in ANSI C, compile with the optimizer. Then unroll by hand the very same loop (using something like the Duff's Device). Compare the results. On a single architecture a human can take in account the CPU characteristics, and do the best optimization, but if you have to support several architectures, unrolling by hand could result in better bytecode for some, but worse bytecode for all the others.
So, having an intermediate language (I wouldn't call it "assembly") designed with optimizers in mind should be a Good Thing(TM).
If I remember correctly, one of the mistakes in designing the JVM is that a great deal of information is left out when compiling to bytecode, so JIT compilers can only do a less-than-optimal job (and you pay it in speed). I don't know if the Amiga virtual machine is better at this, but I bet it is.
A lot of Free and Open Source software is offered commercial support, and the FAQ simply states that you won't get support from IBM even if you are willing to pay.
This also mean that if there is enough commercial interest [in offering commercial support for Open AFS], someone else will probably provide that.
I thought that Win2K had it's own journalling file system
AFS stands for "Andrew File System", it's a network filesystem, and has little to do with IBM's journaled filesystem JFS and the effort to port it to Linux.
Could it be a source of problems for Wine & Co.?
on
Microsoft Cracked
·
· Score: 1
What I mean: in six months or so, could Microsoft point the finger to Wine, or WVWare (was MsWordView) or OpenOffice, etc., and say they used their stolen intellectual property to improve compatiblity with Windows/Office, and thus the projects are to be suspended until clarity is made by a judging court?
I can't believe that Microsoft would ever admit it has been cracked and their sources were stolen unless there is some advantage in doing so. Do you?
SDL at http://libsdl.org is a LGPL library implementing a layer that can use X, SVGAlib, GGI, the Linux kernel framebuffer, and Windows and BeOS graphics systems as a backend. It is well documented, easy to use, provides a nice framework to manage input events and sound, and it is here to stay for a looong time. There are Free (as in speech) extensions to manage even more types of audio files and images, MPEG video, TrueType font rendering. There are also a couple of nice toolkits providing buttons, textfields, lists, checkboxes, etc.
On the ohter hand, SVGAlib is SVGAlib, and as of today, I'm more inclined to trust an XFree86 X server running as root than whichever app running as root and messing around with SVGAlib. But your mileage may vary, of course.
How much of what you guys are doing really matters ...
I think my point is that IMHO nobody would be stressed if they were doing truly important work
Could be this one of the reasons behind the free software movement? I believe many (not all) developers are after it because they believe it's for the sake of a better world (please note I said "they believe", even if it probably is real), which is a respectable goal after all, isn't it?
Personally I believe it's more motivating than a goal like "making yourself and the company you work for gain some more bucks", which isn't bad at all, but clearly is somewhat less actractive (at least in some cultures).
So yes, if you use Linux on your mainframe, you can also boot Windows on it
Excuse my ignorance, but are you implying there are no emulators of PC hardware running natively on S/390 at all?
Ok for free ones (it's not so common to have a mainframe to fiddle with, and bochs wasn't free until it was acquired by Mandrake), but neither commercial ones? It would be really surprising (for me, at least).
Slashdot Mirror
Actually, it has to be launched as root, so it can bind() to the privileged port (or do whatever it's required to do as root), but then it can setgid() and setuid() itself to act as a less powerful user/group (i.e. nobody) with limited access.
Let's see it this way: mandatory copy prevention mechanisms are just a pain in the ass for user and manifacturers, and unreasonable as it is, I doubt it would ever be popular. OTOH, optional copy prevention mechanisms are somewhat less evil, but they can be as bad if they ever become widespread (i.e. try surfing the web with cookies disabled, as someone pointed out in another post).
Now thing are presented to the mass as if you have only two choices and you have to choose only between them. Basically, they are trying to force you to choose between something evil and a compromise. But when you are faced with two options there is always a third option: the status quo (no compromises at all).
Briefly: the media industry asked for 200 and obtained 0, the media industry now is asking for 100 (which is the goal of the media industry, and is less unreasonable than 200, but still unreasonabe). People accepting this compromise just because is less evil than what was originally proposed are just pawns the media's game.
Obviously, it's because of the Eric Conspirancy Secret Labs ;-)
There is a problem with HP-UX installations: it doesn't scale really well downards (i.e. workstations). If you pick the popular HP 712 100 with 128Mb RAM you'll find it is completely unusable with HP-UX 11. With HP-UX 10.20 it is comparable with an old Pentium 133 (or worse). Emacs on it is quite slow.
Things get better on an HP B 180, which is comparable to a not-so-cutting-edge PC (now IIRC a B is the entry level), but it costs as a small car. Still, a x86 with FreeBSD/Linux/whatever feels definitively better.
I suspect (but I don't have numbers) that a large base of HP-UX systems run on 712 and B 180 workstations in telco companies (and obviously also companies developing software for telco operators).
The fact that HP is giving some help with the PA-RISC port of Linux (still in early stages) should lead to interesting considerations. I believe that HP is trying to focus only on big/medium iron (i.e. servers), while leaving its customers with a viable option (PA-RISC Linux) for workstations.
I also believe the same thing is happening with Solaris: there are several old Sparc workstations out there that can be brought to a new life using Sparc Linux.
That said, older Sparc and PA-RISC workstations could be an interesting niche for free unices to fill in, since they may help companies to earn more from their former investments in (pricy!) hardware. And once they are on the workstations, they can slowly crawl also to the servers.
So: after OS/X is "finished", a port of OS/X (the whole OS/X, not just Darwin) to Sparc and PA-RISC for low-end workstations could be interesting for Apple: it could start making inroads to the server market. Until the only hardware capable of running OS/X (again, the whole OS/X, not just the kernel and the *NIX utlities) is the one provided by Apple, the probabilities for OS/X to penetrate the server area (provided that Apple is interested at all) are smaller.
A port for not-so-popular architectures like Sparc or PA-RISC doesn't necessarily mean Apple cutting itself out of market: just look at the x86 port of Solaris: it helped people to buy the hardware where Solaris runs best.
X is not the best in every situation, but if with "bloated" you mean "large bandwidth", I'd suggest you having a look at dxpc (Differential X Protol Compression).
If with "bloated" you mean it has a complex low-level API because of backwards compatiblity, well, it may be the case. But unless you are a toolkit developer, this shouldn't affect you
On the other end, if you just want ICA, you can buy Metaframe for Solaris from Citrix. But probably is not what you want.
The problem with X is that it usually is good enough (i.e. office applications on a 10Mbps LAN) and it can be extended, so competitors have to work really hard just to catch up.
There is also a large set of X application out there that must be supported, so a replacement should really also provide X compatibility (i.e. at least with a gateway X -> other protocol, like VNC server on *NIX).
...but can be slowed down enough.
What I had in mind was really something more similar to what has been done with this localization of StarOffice (provided it could legally be done): would you purchase a localized StarOffice now, or would you wait six months?
Home users probably would wait six months, but corporate users? (I know, usually corporate users take months just to realize that there is a need at all for a certain product...).
Perhaps it's more like Trolltech did: buy Qt for Windows now (and use also in your proprietary application if you like), or wait for a free port from the UNIX version (sometimes in the future?).
Ok, Qt is a library, the free version is GPL and a Windows port would also be, so it's not the same as buying the commercial version. But think if it were LGPL'd instead... Or think to develope a proprietary extension to GTK+ (LGPL), with the promise (kept, because you want to play fair) of releasing it as LGPL after some time, and doing so again and again for each extension, on a regular base (instead of doint it occasionaly, like Sun or Netscape).
But then, it's only an idea... and I don't know if I'd like it.
First, a premise:
making money out of Free software is a bit harder that making money out of closed software: in the first case one can sell additional services (i.e. maintenace, ad hoc customizations, etc.), while in the latter one can also sell the use of the software in itself (because the sources are not available for one to compile and use them, or not legally usable/alterable/redistributable).
That said, could time-shifting be considered as a "service"?
Example: Joe spent some effort developing a nice application for which there could be some market space. Although Joe has no obligation problems to release it under a Free license (i.e. the libraries and the tools he used don't legally force him to release his code under a Free licence), Joe decide to sell its application as proprietary software, with the perspective of releasing the source with a Free license in (say) six months.
This would give Joe enough time to earn some money, and perhaps would please the Free software community because the software will be released under a Free license (let's assume that Joe keeps its promises).
Basically, Joe says "If you want it now and you are not interested in the source, please pay me. Otherwise, wait six months when you'll have everything Free for free".
My question is: would this be considered acceptable by the community? Instead of paying to "have the ability to use it in proprietary software", you'd pay it "to have it now". For some aspects, it's similar to the way Aladdin manages GhostScript, if I remember correctly.
(note: no, I'm not planning to do it this way, since I haven't such a "killer app", and if I had, I'd probably release it as Free software from the start, but I'd like an opinion on that).
Probably he means the image you are manipulating is only a preview of the image (smaller resolution), while editing operations on the "real" image are queued, so they can be performed later on the real image.
This would let you quickly edit an image using a lower resolution, and when you are satisfied with the result you could reapply the same operations on the final image (and go for a coffee or two).
This could be implemented using scripting, of course. Basically, what is needed is a way for the Gimp to record macros and then apply them on another versione of the same image (with more resolution).
Another possiblity would be to have the queued operations be performed in background while you are still editing.
In any case, it should be really useful:
AFAIK, there is some work going on to separate the GIMP rendering engine from the GUI, so it can be integrated/reused in other programs). As a side effect, it could also allow doing this.
Just grab Gimp 1.1.30. It has what you ask, and works well.
You have paths (bezier curves), you can stroke them, modify them, and also convert arbitrary selection to bezier paths.
Paths can be easily exported/imported to/from textfiles, and creating a plugin to convert them to/from EPS should be simple (I'm making some experiments as now).
Xt is a OO framework for developing objects in C and for managing message queues. Point. It does no rendering. At all. It's a library for developing toolkits, and it has some design problems. Did you know that when you set a property on a widget using Xt calls, a full copy of the structure representing the widget is required, thus affecting performance? Commercial widgets vendors implement specific calls for their widgets just to avoid the inefficiency of using applicatively the Xt calls to set properties on their widgets.
GTK+ is NOT based on Xt, it has its own object model. Want a proof? Take any GTK+ app, and do "ldd filename" on it to see what shared libraries it uses. Do you see libXt in there? No. QED.
Qt is NOT based on Xt, it doesn't need to be since it's a C++ toolkit. Another proof? Take any KDE app, do "ldd filename" on it, and search again for libXt. You won't find it.
GNOME libs actually are mostly utility libraries for what concerns GTK+. They avoid 300+ programmers writing the exact same code across all the applications that make up GNOME. This gives consistency, (and less bugs btw). It's not really another abstraction layer.
At the bottom there may be XLib (GDK is an abstraction layer for the drawing engine, and it can be ported to non-X platforms. Look at The Gimp for Windows). This is required, since it provides only the minimal functionalities to talk with an X server, and you'd have to reimplement all of it by yourself if you wanted to talk with an X server without using Xlib.
Finally, I'm wondering myself why the Windows port of GTK hasn't been used, since it's there and works fine. Perhaps some Gnome developer wanted raw access, and did raw XLib calls instead of GDK ones just to be "faster"? Well, now you need an X server until that "smartness" get fixed with appropriate GDK calls.
If you don't use them already, I strongly recommend you the JMK fonts for X: they provide simply the best looking monospaced fonts (expecially "neep" 18 points) a developer could ever desire for his editor.
Now, if only I were able to convert them into something usable also on Windows... suggestions?
Just a note: Aladdin GhostScript is free (as in beer and partially as in speech) for commercial use. The limitation is that only Aladdin can charge money for distributing modifications to the source. Read it here.
After a certain amount of time, source is relicensed under GPL (and here we have GNU GhostScript), so Aladdin basically sells the fact it stays ahead in development, while also pleasing RMS (who, you'll agree with me, is not so easy to please).
Abisource developers could agree to do something similar in the future, and perhaps earn some money (provided people out there are willing to pay for creepy featurism).
About Framemaker: I use it for large technical documents (600+ pages on HP-UX) and I really like it. But for the use I make of FrameMaker, I could as well use LyX without any problem. Frames in FrameMaker are a nice plus over LyX, but you'll agree with me that you can't do serious DTP with them anyway, and they are mostly used exactly as LyX floats...
Sorry, I really meant:
If they are going only to sign whole interpreters, and then trust all the scripts such interpreters execute, it's useless.
In the first case, it's pretty useless.
In the second case, while I recognize that the only automation tool that the typical luser knows of (and needs, because it's a luser) is his/hers hands doing the same thing over and over, there would be trouble even USING an Excel sheet requiring the execution of macros in order to work.
Servers shouldn't need such an extreme solution. Lusers are not supposed to put their finger on them, and scripting is usually needed on servers.
IMHO, in order to be effective, an implementation of such a solution as now would require severe redesigning of the way common apps works. I doubt it's an option.
That said: X is not the best at everything, and color calibration is one of these. If there is enough interest, it will be implemented as an extension to the X protocol. Instead of bashing X, go after X implementors, like the XFree86 group, and ask or help them to properly design and implement such thing. Then you'll have fine color calibration in X.
So, unless the GUI developer was moron and specified absolute dimensions for widgets, there is resolution indipendence. Just specify the size of your fonts in tenths of typographic points (the 8th field): the layout manager of the toolkit then will make your app equally usable at 640x400 and 1600x1200.
The real problem here is only with bitmaps: they have a hinerent size in pixels. Buttons containing only a bitmap won't scale (unless the developer arranges things specifically, i.e. scaling the bitmap to be n rows of text high).
I don't know if Tux (the web server) is based on that, or if it implements its own in kernel.
If I understand it right, it's a good idea: optimal loop unrolling is performed in a different manner on different platform.
This way, you have the actual loop in the bytecode, which can be unrolled and translated very efficiently for the specific architecture.
While I believe that nothing could beat a human being when it come to coding to one specific architecture, I believe optimizers can do a damn good job when it comes to support several architectures. Example?
Take a simple loop in ANSI C, compile with the optimizer. Then unroll by hand the very same loop (using something like the Duff's Device). Compare the results. On a single architecture a human can take in account the CPU characteristics, and do the best optimization, but if you have to support several architectures, unrolling by hand could result in better bytecode for some, but worse bytecode for all the others.
So, having an intermediate language (I wouldn't call it "assembly") designed with optimizers in mind should be a Good Thing(TM).
If I remember correctly, one of the mistakes in designing the JVM is that a great deal of information is left out when compiling to bytecode, so JIT compilers can only do a less-than-optimal job (and you pay it in speed). I don't know if the Amiga virtual machine is better at this, but I bet it is.
Where did you read "support for free"?
A lot of Free and Open Source software is offered commercial support, and the FAQ simply states that you won't get support from IBM even if you are willing to pay.
This also mean that if there is enough commercial interest [in offering commercial support for Open AFS], someone else will probably provide that.
AFS stands for "Andrew File System", it's a network filesystem, and has little to do with IBM's journaled filesystem JFS and the effort to port it to Linux.
I can't believe that Microsoft would ever admit it has been cracked and their sources were stolen unless there is some advantage in doing so. Do you?
On the ohter hand, SVGAlib is SVGAlib, and as of today, I'm more inclined to trust an XFree86 X server running as root than whichever app running as root and messing around with SVGAlib. But your mileage may vary, of course.
Could be this one of the reasons behind the free software movement? I believe many (not all) developers are after it because they believe it's for the sake of a better world (please note I said "they believe", even if it probably is real), which is a respectable goal after all, isn't it?
Personally I believe it's more motivating than a goal like "making yourself and the company you work for gain some more bucks", which isn't bad at all, but clearly is somewhat less actractive (at least in some cultures).
Excuse my ignorance, but are you implying there are no emulators of PC hardware running natively on S/390 at all?
Ok for free ones (it's not so common to have a mainframe to fiddle with, and bochs wasn't free until it was acquired by Mandrake), but neither commercial ones? It would be really surprising (for me, at least).