your program has a particular appeal to newbies and it is not included with most distributions,
the build procedure is unusually complex, or
your program takes ridiculously long to build.
I think most experienced Unix people are comfortable with building from source, and many people just don't trust third-party packages, as they're often badly packaged or out of date.
If you decide to do it anyway, one tool that can help you is checkinstall. It monitors the standard make install process and can create several kinds of packages. I doubt the quality of the generated packages is very good though, and you still have to take in account that different distributions have different policies.
Also, make sure you don't waste effort creating packages for distributions that already include your program. You mention DEBs, but whatever your program is, I'm pretty sure Debian already includes it:)
If Microsoft will actually do this, I predict there'll be tons of "forward to ten people and get a reward" spam... Who would risk it/not/ being a hoax?
FSF's interpretation are not very relevant
on
LGPL is Viral for Java
·
· Score: 3, Insightful
The FSF's interpretation of the LGPL only applies to software owned by the FSF. If I had a different interpretation of the LGPL (which is certainly possible -- many parts are quite vague), that interpretation would apply to my software, and the FSF can do nothing about it.
One example of one such non-standard interpretation is the "Lisp LGPL", used by Franz for their open source libraries. Parts of the LGPL don't make much sense for non-C-like languages such as Common Lisp, so they added a preample which explains their interpretation.
Another real-world example is Pine. Early versions of Pine had a BSD-like license, which allows "modification and distribution". The University of Waterloo interpreted this to mean that you could modify Pine, or distribute an unmodified Pine, but not distribute a modified Pine. This was contrary to everybody else's interpretation, but they owned the copyright so they got to decide. (More recent versions have a different license).
To the amazement of readers of an IBM newsgroup, neither Microsoft nor the USPTO examiners seem to be aware of the existence of the Mainframe-based prior art, which is not cited in the patent."
I don't understand why they are amazed. Mainframe technology is essentielly the Dark Age of Computing. Nobody knows about it, and no place teaches it.
What are "Partitioned Data Sets"? Dunno, I've never heard of them. The link certainly doesn't explain, that's just dinosaur mumbo jumbo. (And what's so special about that editor screenshot?)
This is by the way IBM is porting Linux to their mainframes. Customers might need the high reliability etc., but they still won't buy them if they can't find anyone who knows how to use the native operating systems, let alone program them.
Surprise surprise, Via has just released drivers with support for DRI and all the other goodies...
From: Tim Roberts <timr@probo.com> Date: Wed, 09 Jul 2003 11:32:34 -0700 Subject: [Savage40] Better Driver Out There To: savage40 <savage40@probo.probo.com> Reply-To: Tim Roberts <timr@probo.com> Return-path: savage40-bounces@probo.com
Well, folks, it appears that my Savage driver is now a LONG ways from the state of the art. I am no longer "da man".
Unbeknownst to me, VIA/S3 have been quietly bulking up their snapshot of the Savage driver. Recently, they were persuaded to release their driver to the world in source form:
http://www.linux.org.uk/~alan/S3.zip
I have not tried to compile this yet, but based on a quick perusal of the source code, it looks like it:
* Supports all of the Savage chips * Supports video4linux for videoport/zoomvideo * Supports the Chrontel TV part on ProSavageDDR motherboards * Supports MPEG motion compensation acceleration (XvMC) and (drum roll, please): * Supports DRI and OpenGL
They have made so many changes that it is almost impossible for me to determine whether all of my recent fixes are in their code, but given the thoroughness I see in other places, I suspect that they are.
So, if you have the inclination and ability to build from source, it would be well worth your trouble to give this a try. If you do build binaries for either 4.2.0 or 4.3.0, let me know and I will announce it to this list.
-- - Tim Roberts, timr@probo.com Providenza & Boekelheide, Inc.
He's probably talking about Cfront. Never expect a suit to know the difference between a standard and an implementation:)
Cfront was the first C++ implementation. It worked by translating C++ code to C (in fact, it started out as a simple preprocessor), and as a result it has all kinds of problems with fancier C++ constructs, such as exceptions, STL, and inline functions. According to Mozilla's portability guidelines, the SCO and HP C++ compilers are still based on it.
> I was shocked since I check my mailserver weekly to make sure it isn't an
> open relay. I checked several of the sites that will run checks against your
> mailserver and I was fine. *UGH* I have to call AOL to find what the problem
> is. After waiting on hold for 30 to 45 minutes, the gentlemen on the other
> end of the phone informed that they were having an "issue" where their server
> were rejecting email from IP's starting with a 6. Going to be a long morning
> for somebody over at AOL....
Re:If this is what Jabba does, then Jabba will los
on
Why Java Won't Have Macros
·
· Score: 3, Insightful
You're completely right of course. But as many people are complaining macro's don't fit in Java's everything-is-part-of-a-class philosophy, I'll just point out you can easily put macro's in classes and use them like this (assuming you have an OpenGL class):
Re:Strange, I've been arguing about this all day .
on
Why Java Won't Have Macros
·
· Score: 4, Interesting
They're bad because they don't extend the C syntax, they just change it. Good macros extend the syntax, but keep the new syntax in same style as the original language. If you want to know to what your four macro's lead, look at the famous Bourne shell source code. A few simple definitions like yours in mac.h
result in the horror of xec.c and cmd.c.
Macros are text substitution or syntax tree manipulation alone. Macros are not called, so why you think they have anything to with procedures or functions?
Well, that depends on the language. In Common Lisp and most other Lisp dialects (not Scheme tough), macro's are normal functions that are run at compile-time instead of at run-time. They can do everything normal functions can do, such as calling other functions, doing I/O, etc..
I think the readability argument is bogus: you could say exactly the same about every form of abstraction (functions, classes,...). Of course, if you have a brain dead macro system as in C and you do things like: #define FOO bar + 2 * (seen in flex source), you have a problem. With a decent macro system (such as Common Lisp, Scheme, and Dylan have), you avoid these kind of problems. (btw, Dylan has an ordinary, infix syntax, so having lots of parentheses is not a requirement...)
No, in Lisp macro's aren't used for inline functions , but for syntax extensions. For a demonstration of what real macros can do, look at The Swine Before Perl. That presentation shows how easy it is to implement special syntax for automatons in Scheme, and how natural & simple the result looks.
See This mail on the debian gtk/gnome mailing lists.
On Tue, 2003-06-03 at 14:55, Mark Gordon <mtgordon@ximian.com> wrote:
> There are no plans for an XD2 release for Woody.
>
> -Mark Gordon
Some people are starting to work on an unofficial woody port. Unstable already contains gnome 2.2 and most interesting ximian patches will probably be applied.
Who made this distribution? This isn't an official Debian project at all, in fact the Debian developers knew nothing about it until today. On the whole site there isn't a single email or name given, and the mailing list archives are password protected. I wouldn't trust this project at all, if the developers don't even say their names.
The naming of this subproject is either poorly thought out, or just downright underhanded.
In fact, it isn't even a subproject at all. This thing has nothing to do at all with the Debian project. In fact, the Debian developers are pretty angry about it.
BTW, has anybody even found a name on that website, or even a contact email? Even the mailing list archives are password protected (very un-Debian-like). I wouldn't trust that code at all.
If you'd look in the debian-legal archives, you'd see that the debian people had quite a lot discussions with the latex people. They've now come to an agreement and are drafting a license that would be acceptable to both parties.
They are now going to do the same thing with the fsf: right now they're working on a text and a faq that explain their problems with the gfdl, and then they'll try to convince the fsf to create a new version that fixes those problems./p
If it does require a server side piece, it's not a web browser, per se; but as a general question, is it worthwhile to look into "compressed" web pages, e.g., foo.html.zlib?
This already exists, look for example at mod_gzip for Apache. This will compress pages before transmitting if the browser claims to support it. Mozilla does, I believe IE does too.
Slashdot Mirror
- your program has a particular appeal to newbies and it is not included with most distributions,
- the build procedure is unusually complex, or
- your program takes ridiculously long to build.
I think most experienced Unix people are comfortable with building from source, and many people just don't trust third-party packages, as they're often badly packaged or out of date.If you decide to do it anyway, one tool that can help you is checkinstall. It monitors the standard make install process and can create several kinds of packages. I doubt the quality of the generated packages is very good though, and you still have to take in account that different distributions have different policies.
Also, make sure you don't waste effort creating packages for distributions that already include your program. You mention DEBs, but whatever your program is, I'm pretty sure Debian already includes it :)
If Microsoft will actually do this, I predict there'll be tons of "forward to ten people and get a reward" spam... Who would risk it /not/ being a hoax?
One example of one such non-standard interpretation is the "Lisp LGPL", used by Franz for their open source libraries. Parts of the LGPL don't make much sense for non-C-like languages such as Common Lisp, so they added a preample which explains their interpretation.
Another real-world example is Pine. Early versions of Pine had a BSD-like license, which allows "modification and distribution". The University of Waterloo interpreted this to mean that you could modify Pine, or distribute an unmodified Pine, but not distribute a modified Pine. This was contrary to everybody else's interpretation, but they owned the copyright so they got to decide. (More recent versions have a different license).
To the amazement of readers of an IBM newsgroup, neither Microsoft nor the USPTO examiners seem to be aware of the existence of the Mainframe-based prior art, which is not cited in the patent."
I don't understand why they are amazed. Mainframe technology is essentielly the Dark Age of Computing. Nobody knows about it, and no place teaches it.
What are "Partitioned Data Sets"? Dunno, I've never heard of them. The link certainly doesn't explain, that's just dinosaur mumbo jumbo. (And what's so special about that editor screenshot?)
This is by the way IBM is porting Linux to their mainframes. Customers might need the high reliability etc., but they still won't buy them if they can't find anyone who knows how to use the native operating systems, let alone program them.
Surprise surprise, Via has just released drivers with support for DRI and all the other goodies...
From: Tim Roberts <timr@probo.com>
Date: Wed, 09 Jul 2003 11:32:34 -0700
Subject: [Savage40] Better Driver Out There
To: savage40 <savage40@probo.probo.com>
Reply-To: Tim Roberts <timr@probo.com>
Return-path: savage40-bounces@probo.com
Well, folks, it appears that my Savage driver is now a LONG ways from the state
of the art. I am no longer "da man".
Unbeknownst to me, VIA/S3 have been quietly bulking up their snapshot of the
Savage driver. Recently, they were persuaded to release their driver to the
world in source form:
http://www.linux.org.uk/~alan/S3.zip
I have not tried to compile this yet, but based on a quick perusal of the
source code, it looks like it:
* Supports all of the Savage chips
* Supports video4linux for videoport/zoomvideo
* Supports the Chrontel TV part on ProSavageDDR motherboards
* Supports MPEG motion compensation acceleration (XvMC)
and (drum roll, please):
* Supports DRI and OpenGL
They have made so many changes that it is almost impossible for me to determine
whether all of my recent fixes are in their code, but given the thoroughness I
see in other places, I suspect that they are.
So, if you have the inclination and ability to build from source, it would be
well worth your trouble to give this a try. If you do build binaries for
either 4.2.0 or 4.3.0, let me know and I will announce it to this list.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
Huh, did Mcrosoft ever work on those? I thought Xenix predated System V, and I just can't imagine them working on Motif.
He's probably talking about Cfront. Never expect a suit to know the difference between a standard and an implementation :)
Cfront was the first C++ implementation. It worked by translating C++ code to C (in fact, it started out as a simple preprocessor), and as a result it has all kinds of problems with fancier C++ constructs, such as exceptions, STL, and inline functions. According to Mozilla's portability guidelines, the SCO and HP C++ compilers are still based on it.
No, on my system the latest version of RealVNC (3.3.7) still has this problem. Maybe you're using a different VNC server?
Me, as a matter of fact.
From the spam-l list:
Sorry, no.
You're completely right of course. But as many people are complaining macro's don't fit in Java's everything-is-part-of-a-class philosophy, I'll just point out you can easily put macro's in classes and use them like this (assuming you have an OpenGL class):
They're bad because they don't extend the C syntax, they just change it. Good macros extend the syntax, but keep the new syntax in same style as the original language. If you want to know to what your four macro's lead, look at the famous Bourne shell source code. A few simple definitions like yours in mac.h result in the horror of xec.c and cmd.c.
Well, that depends on the language. In Common Lisp and most other Lisp dialects (not Scheme tough), macro's are normal functions that are run at compile-time instead of at run-time. They can do everything normal functions can do, such as calling other functions, doing I/O, etc..
I think the readability argument is bogus: you could say exactly the same about every form of abstraction (functions, classes, ...). Of course, if you have a brain dead macro system as in C and you do things like:
#define FOO bar + 2 *
(seen in flex source), you have a problem. With a decent macro system (such as Common Lisp, Scheme, and Dylan have), you avoid these kind of problems. (btw, Dylan has an ordinary, infix syntax, so having lots of parentheses is not a requirement...)
No, in Lisp macro's aren't used for inline functions , but for syntax extensions. For a demonstration of what real macros can do, look at The Swine Before Perl. That presentation shows how easy it is to implement special syntax for automatons in Scheme, and how natural & simple the result looks.
See This mail on the debian gtk/gnome mailing lists.
On Tue, 2003-06-03 at 14:55, Mark Gordon <mtgordon@ximian.com> wrote:
> There are no plans for an XD2 release for Woody.
>
> -Mark Gordon
Some people are starting to work on an unofficial woody port. Unstable already contains gnome 2.2 and most interesting ximian patches will probably be applied.
I'm suprised so many people are willing to trust these guys.
Who made this distribution? This isn't an official Debian project at all, in fact the Debian developers knew nothing about it until today. On the whole site there isn't a single email or name given, and the mailing list archives are password protected. I wouldn't trust this project at all, if the developers don't even say their names.
In fact, it isn't even a subproject at all. This thing has nothing to do at all with the Debian project. In fact, the Debian developers are pretty angry about it.
BTW, has anybody even found a name on that website, or even a contact email? Even the mailing list archives are password protected (very un-Debian-like). I wouldn't trust that code at all.
They should drop the word "Debian" because it isn't an official Debian project. Those people have never contacting the Debian developers at all.
If you'd look in the debian-legal archives, you'd see that the debian people had quite a lot discussions with the latex people. They've now come to an agreement and are drafting a license that would be acceptable to both parties.
They are now going to do the same thing with the fsf: right now they're working on a text and a faq that explain their problems with the gfdl, and then they'll try to convince the fsf to create a new version that fixes those problems./p
In Belgium this has been available for a couple of years now. It's called Proton over here and is pretty popular.
Disconnect your disk drives and floppy, and even current systems will probably say "NO ROM BASIC" :) (Last time I tried that was on a Pentium 200).
If it does require a server side piece, it's not a web browser, per se; but as a general question, is it worthwhile to look into "compressed" web pages, e.g., foo.html.zlib?
This already exists, look for example at mod_gzip for Apache. This will compress pages before transmitting if the browser claims to support it. Mozilla does, I believe IE does too.