the FSF made a special exception for when the Bison skeleton file is outputted by Bison and placed into code; such code would not have to be subjected to the GPL.
True, but in that case, the FSF owned the copyright to the entire program, and hence were free to offer new license terms as they saw fit.
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?
See my earlier comment. All UCB are doing (in fact, all they can do) is offering to relicense the code on which they own the copyright under the new terms. Although many programs use the BSD license, UCB don't own copyright on most of them, and hence have no say in future licensing terms.
Individuals authors will have to rerelease the source under the new license terms (or offer to relicense existing source under the new terms). No doubt some will do so, and some will not -- either because they want the advertising clause present (and they have every right to do so), or because they don't know or don't care about it.
An interesting (and welcome) move. However, it's worth pointing out that they're not changing existing licenses retroactively. If it were possible to do that, there would be nothing to stop someone relicensing a program with an OSD-compliant license under terms that meant it was no longer freely redistributable. No, what UCB are doing is effectively offering new licensing terms. Individuals are free to either accept those terms, or stick with their original licenses. Of course, in this case, there's no benefit to sticking with the old terms, but the difference is worth pointing out.
Does anyone have more info about the DG/UX support? Is this for Intel based DG/UX machines only (which tend to use Cirrus chips)? I'm more interested in the old m88k based machines, 'coz I've got two of them! They're stuck with the standard Xdg server, which deosn't support MITSHM, for example (although it does have a DG-specific DG-SHM extension).
On a completely different note, my G400 works just fine with the XSVGA server from 3.3.4, but hangs completely when using the VGA16 server (e.g., when trying to use XF86Setup). Still, I managed to hand tweak the config file (reminds me of the good old days!), and it works just fine now -- 1600x1200 at 32bpp:-)
Anyone else notice the article said they demonstrated Merced running on W2K and Linux? Surely it should be the other way round -- W2K and Linux running on Merced?
Sorry, but this makes me very suspicious. 911 is so cirtical that I can't believe they'd risk using the setup they've described. Where's the hot swap failover for when something dies? OK, the HP server may be fault tollerant, but if a client goes down, the fact that the server's still up is irrelevant -- calls are lost or significantly delayed.
Sure, Linux will give much less downtime than the NT boxes, but neither will provide the necessary *guaranteed* uptimes from a single box. What happens if someone kicks the power cable out? I'd expect some sort of hot swap failover cluster for an application like this, whatever the OS. Running on a single box is just running on borrowed time.
256 colours is enough (or even too many!)
on
Mozilla M9 Released
·
· Score: 1
It looks like a bitmap that someone made [...] on a computer that couldn't show more that 256 colors!
As it should do. The world is not a Linux machine. Mozilla is designed to run on pretty much any Unix. Most of the SparcStations in use today still only have an 8-bit framebuffer, for example. Just because your Linux PC can run a 24/32-bit X server, there's no reason to discriminate against those who can't (BTW, 24-bit SBUS framebuffers are prohibitively expensive and require two free SBUS slots, so telling people to upgrade isn't an option). Besides, 256 colours is *more* than enough for an animated spinner. You've just got to design it right.
PS. I know several people that are still stuck using a mono X server at work...
Arse! Someone please moderate this down. Finger trouble made me hit submit instead of preview. I thought I'd caught it before it was sent, but obviously not. The "proper" comment is directly below...
I'm pleased to see this. It is without doubt the right decision, because:
Avery Dennison is in no way related to network infrastructure, so they certainly shouldn't be granted exclusive use of a.net domain.
As the article says, others have a legitimate claim on the domain. Just because it happens to be someone else's trademark has little bearing on anything. The domains aren't being used to infringe the trademark -- they're being used in a completely different context.
There's only room for one of each domain on the Internet, and first come first served is as good a way of deciding who gets what as any other. Otherwise, domain ownership will turn into a farce, where the corporation that can afford the most lawyers always wins.
Thank you! At least someone gets what I'm trying to say. This is exactly what happened to me. When the SunPro compiler broke we had over 3 weeks of downtime waiting for them to fix it before giving up and going with gcc. I'll guarantee that I could find someone prepared to fix gcc quicker that at a total cost less than the downtime for the SunPro compiler.
I was very surprised as to how many people would be prepared to put up with a closed source compiler. It's the one component of your development system that's absolutely critical, and I couldn't justify going the closed source route. I've already been bitten by that one since Sun didn't fix a bug in their SunPro compiler many years ago. We were forced to switch to gcc just to get the code to compile, and haven't looked back since.
I might consider it if the source was held in escrow, but the conditions for source code release to me would have to be very favourable. It's worth noting that I personally don't have the compiler expertise to be able to fix most problems that are likely to occur anyway. However, if I have the source, I can at least pay someone else that does have the expertise to do it for me.
BTW, it's nice to see that a company like Borland/Inprise still has a sense of humour (re: question 35).
Slower than other remote display protocols, especially ICA
Do you have any proof for this? Both protocols have their advantages and disadvantages, but empirical evidence suggests ICA is slower than X, and LBX is faster than both. Certainly, both Wincenter and Terminal Server are slow as hell for me over ethernet. I'd hate to think what they'd be like over a 14.4 modem (in comparison, X over said modem is slow but usable).
Yes, fonts are copyrightable. However, if they were published as a set of purely numeric data, they wouldn't be. It is because fonts are programs (at least with PostScript -- I assume TrueType is the same), that they are copyrightable. In fact, Adobe took a deliberate design decision when creating the Type 1 font format to make each font a PostScript program, specifically to allow fonts to be copyrighted.
Of course, if you scan in a font, trace the outline and save it as a new font, you're creating a different program, and hence no copyright infringement has occurred (except in the case where the traced outline happens to be identical to the original, right down to the last hint -- but the chances of that happening are so small as to be negligible).
More benchmarketing again... Benchmarks for polygons / sec are typically based on the simplest polygon possible -- a 3 pixel solid "triangle". At 60Hz, a standard television isn't capable of displaying more than 12 million or so polygons per second anyway. For a high resolution monitor at 100Hz, this rises to about 50-60 million, so the 75 million number is pretty meaningless.
Furthermore, real-life polygons aren't only 3 pixels, and they're not solid colour. They're larger, and they're textured. Also, although your scene could theoretically contain more than 75 million polygons, you're relying on your application to be able to calculate which ones are visible, and pass their coordinates to the renderer at a rate fast enough to keep up. Although possible, I'd guess this is unlikely to be the case with PSX2.
Can't comment about the States, 'coz I don't live there:-) However, here in the UK, it's relatively straightforward. When I started contracting, I saw an independent financial advisor, who told me to do a number of things (in the UK, contractors typically form their own limited companies -- this may be different in the US):
Personal permanent health insurance. This provides benefits should you be unable to work for an extended period of time. They typically start paying out after either 4 or 13 weeks, depending on how much premium you pay. Look for a policy that covers same occupation, i.e., if you can't program for a while, they won't force you to work in McDonalds (this is sadly suprisingly common).
Executive pension. Not a lot to say about this, other than pick one of the rare ones (less than 5%) that don't do front end loading, otherwise your pension fund won't break even before about year 6 or so. This is a big issue with IR35, and you may be forced into a permie position and need to transfer to a personal pension.
Executive permanent health insurance. Pays out for pension contributions should you be unable to work, with similar conditions to the personal equivalent.
Life insurance. Covers your dependents if you die (I already have this as part of my mortgage), and may also pay a lump sum should you be permanently disabled.
Private healtcare. Unlike the US, we have the NHS, and private healthcare is strictly a luxury item. That said, if you ever need a stay in hospital, you'll be glad you got it. Just pick one you like the look of. Now being offered by banks and building societies at a discount the normal PPP / BUPA etc. premiums, but check the exclusion clauses.
All this adds up to be quite expensive, but it's probably worth it. Off the top of my head, I think I'm paying about 100-150 quid per month for the insurance, plus a shitload for the pension (about a grand a month!).
I'm currently running Linux on x86 hardware, but that's solely because it currently gives me the best bangs per buck
Yep, couldn't agree more. Virtually everything else out there is superior in terms of design, build quality, etc., but when it comes down to it, market pressures have forced PC prices down so much that everything else is just not good enough value. I love my Sparc to bits -- PCs don't even come close to the simplicity and elegance of its design (why, oh why, haven't SCA drives become commonplace in the PC world?). However, your average punter isn't going to spend money on a decent RISC machine to get the same performance as a PC costing half as much, no matter how good the build quality. At the high end, pricing is closer to parity, but that's mostly due to Intel's extertionate pricing of Xeon's so they match equivalent Sparc / Alpha / MIPS offerings.
If there was a cheap PPC option, I'd almost certainly go for it. That said, I'd still have to keep my x86 boxen to run those binary apps that don't yet have an open source equivalent of sufficient quality.
How much do you care what kind of processor you are running? The answer has to do with whether Linux does an adequate job of hiding platform differences so that porting a piece of software to a different machine is just a matter of a recompile.
Linux already does that, and does it very well. I can compile virtually everything on my Sparc Linux box just as easily as I can on my Intel ones. The only exceptions are the few dolts that assume Linux == x86, and do things like include x86 assembler for a few routines ("for performance"). That's all well and good, but it makes your app gratuitously non-portable, when it needn't be. autoconf should be able to detect the platforms for which you can substitute fast hand-crafted assembler for slower but functionally identical C routines. That gives you proper portability with performance benefits on certain platforms. Either way, 99% of apps that use autoconf just compile straight out of the box on all my Linux platforms.
He talks about programming in Perl, Scriptics and Python. However, Scriptics, of course, is the company set up by John Ousterhout to try and make some money out of his Tcl scripting language. Pretty much throughout the article, the word "Scriptics" should be replaced with "Tcl".
As I understand it (not having used Debian since the pre-apt days), apt is just a front end that sits on top of dpkg, much the same way as dselect used to do. There's no reason you couldn't have the same or a very similar front end running on top on RPM. dselect was one of the few reasons I stuck with Debian for so long. But in the end, I just found Red Hat easier to work with. Plus it was nice to have a single distribution on all my platforms (I understand Debian may now have a Sparc version available, but they didn't at the time).
I wouldn't buy from someone who didn't run the product they sell, makes me question the quality of the product.
Indeed. In fact, they don't seem to have even looked at their own site from a Unix box. That's why it's full of font tags setting the face to Arial. On my Netscape, that renders as Courier, because unsurprisingly, Arial (being a Micros~1 font) isn't available. What they should be doing is specifying alternative fonts like Helvetica and a generic font family (in this case, "sans-serif").
The world's most popular sport is, of course, football. It's just that Americans can't bring themselves to call it football because they already have a game by the same name that's played mostly with the hands. Go figure...
Yeah, flamebait, I know, but then we are talking about a country that has a "world" series where only one nation competes:-)
AdvanSys have been making decent SCSI controllers for a while. More importantly, they've been providing official GPLed drivers for Linux for years. I bought mine solely on the grounds of their Linux support (at the time, the Adaptec cards weren't well supported), and I've never regretted it. I'd recommend them to anyone.
OK, so bcc compiles twice as fast as gcc for their tests I wonder how long they took to find something (xgalaga) that gave them the results they wanted? Either way, quite a gain, although I suspect it'll be closer to ~30% faster for real life projects.
However, compilation times and executable size are nice, but the real test will be runtime performance. Unless it produces faster code, no-one will use it...
Slashdot Mirror
True, but in that case, the FSF owned the copyright to the entire program, and hence were free to offer new license terms as they saw fit.
See my earlier comment. All UCB are doing (in fact, all they can do) is offering to relicense the code on which they own the copyright under the new terms. Although many programs use the BSD license, UCB don't own copyright on most of them, and hence have no say in future licensing terms.
Individuals authors will have to rerelease the source under the new license terms (or offer to relicense existing source under the new terms). No doubt some will do so, and some will not -- either because they want the advertising clause present (and they have every right to do so), or because they don't know or don't care about it.
An interesting (and welcome) move. However, it's worth pointing out that they're not changing existing licenses retroactively. If it were possible to do that, there would be nothing to stop someone relicensing a program with an OSD-compliant license under terms that meant it was no longer freely redistributable. No, what UCB are doing is effectively offering new licensing terms. Individuals are free to either accept those terms, or stick with their original licenses. Of course, in this case, there's no benefit to sticking with the old terms, but the difference is worth pointing out.
On a completely different note, my G400 works just fine with the XSVGA server from 3.3.4, but hangs completely when using the VGA16 server (e.g., when trying to use XF86Setup). Still, I managed to hand tweak the config file (reminds me of the good old days!), and it works just fine now -- 1600x1200 at 32bpp :-)
Of course, you didn't close your HTML tags properly. You should have used /WHINE. Just being picky :-) Oh, and I can't view the site either :-(
Anyone else notice the article said they demonstrated Merced running on W2K and Linux? Surely it should be the other way round -- W2K and Linux running on Merced?
Sure, Linux will give much less downtime than the NT boxes, but neither will provide the necessary *guaranteed* uptimes from a single box. What happens if someone kicks the power cable out? I'd expect some sort of hot swap failover cluster for an application like this, whatever the OS. Running on a single box is just running on borrowed time.
As it should do. The world is not a Linux machine. Mozilla is designed to run on pretty much any Unix. Most of the SparcStations in use today still only have an 8-bit framebuffer, for example. Just because your Linux PC can run a 24/32-bit X server, there's no reason to discriminate against those who can't (BTW, 24-bit SBUS framebuffers are prohibitively expensive and require two free SBUS slots, so telling people to upgrade isn't an option). Besides, 256 colours is *more* than enough for an animated spinner. You've just got to design it right.
PS. I know several people that are still stuck using a mono X server at work...
A GPLed Flash plugin for Netscape can be found at http://www.geocities.com/TimesSquare/Labyrinth/508 4/flash.html. The web page claims it works on HP/UX. I've only tried it (briefly) on Linux.
Arse! Someone please moderate this down. Finger trouble made me hit submit instead of preview. I thought I'd caught it before it was sent, but obviously not. The "proper" comment is directly below...
Thank you! At least someone gets what I'm trying to say. This is exactly what happened to me. When the SunPro compiler broke we had over 3 weeks of downtime waiting for them to fix it before giving up and going with gcc. I'll guarantee that I could find someone prepared to fix gcc quicker that at a total cost less than the downtime for the SunPro compiler.
I might consider it if the source was held in escrow, but the conditions for source code release to me would have to be very favourable. It's worth noting that I personally don't have the compiler expertise to be able to fix most problems that are likely to occur anyway. However, if I have the source, I can at least pay someone else that does have the expertise to do it for me.
BTW, it's nice to see that a company like Borland/Inprise still has a sense of humour (re: question 35).
Do you have any proof for this? Both protocols have their advantages and disadvantages, but empirical evidence suggests ICA is slower than X, and LBX is faster than both. Certainly, both Wincenter and Terminal Server are slow as hell for me over ethernet. I'd hate to think what they'd be like over a 14.4 modem (in comparison, X over said modem is slow but usable).
Of course, if you scan in a font, trace the outline and save it as a new font, you're creating a different program, and hence no copyright infringement has occurred (except in the case where the traced outline happens to be identical to the original, right down to the last hint -- but the chances of that happening are so small as to be negligible).
Furthermore, real-life polygons aren't only 3 pixels, and they're not solid colour. They're larger, and they're textured. Also, although your scene could theoretically contain more than 75 million polygons, you're relying on your application to be able to calculate which ones are visible, and pass their coordinates to the renderer at a rate fast enough to keep up. Although possible, I'd guess this is unlikely to be the case with PSX2.
- Personal permanent health insurance. This provides benefits should you be unable to work for an extended period of time. They typically start paying out after either 4 or 13 weeks, depending on how much premium you pay. Look for a policy that covers same occupation, i.e., if you can't program for a while, they won't force you to work in McDonalds (this is sadly suprisingly common).
- Executive pension. Not a lot to say about this, other than pick one of the rare ones (less than 5%) that don't do front end loading, otherwise your pension fund won't break even before about year 6 or so. This is a big issue with IR35, and you may be forced into a permie position and need to transfer to a personal pension.
- Executive permanent health insurance. Pays out for pension contributions should you be unable to work, with similar conditions to the personal equivalent.
- Life insurance. Covers your dependents if you die (I already have this as part of my mortgage), and may also pay a lump sum should you be permanently disabled.
- Private healtcare. Unlike the US, we have the NHS, and private healthcare is strictly a luxury item. That said, if you ever need a stay in hospital, you'll be glad you got it. Just pick one you like the look of. Now being offered by banks and building societies at a discount the normal PPP / BUPA etc. premiums, but check the exclusion clauses.
All this adds up to be quite expensive, but it's probably worth it. Off the top of my head, I think I'm paying about 100-150 quid per month for the insurance, plus a shitload for the pension (about a grand a month!).Yep, couldn't agree more. Virtually everything else out there is superior in terms of design, build quality, etc., but when it comes down to it, market pressures have forced PC prices down so much that everything else is just not good enough value. I love my Sparc to bits -- PCs don't even come close to the simplicity and elegance of its design (why, oh why, haven't SCA drives become commonplace in the PC world?). However, your average punter isn't going to spend money on a decent RISC machine to get the same performance as a PC costing half as much, no matter how good the build quality. At the high end, pricing is closer to parity, but that's mostly due to Intel's extertionate pricing of Xeon's so they match equivalent Sparc / Alpha / MIPS offerings.
If there was a cheap PPC option, I'd almost certainly go for it. That said, I'd still have to keep my x86 boxen to run those binary apps that don't yet have an open source equivalent of sufficient quality.
Linux already does that, and does it very well. I can compile virtually everything on my Sparc Linux box just as easily as I can on my Intel ones. The only exceptions are the few dolts that assume Linux == x86, and do things like include x86 assembler for a few routines ("for performance"). That's all well and good, but it makes your app gratuitously non-portable, when it needn't be. autoconf should be able to detect the platforms for which you can substitute fast hand-crafted assembler for slower but functionally identical C routines. That gives you proper portability with performance benefits on certain platforms. Either way, 99% of apps that use autoconf just compile straight out of the box on all my Linux platforms.
He talks about programming in Perl, Scriptics and Python. However, Scriptics, of course, is the company set up by John Ousterhout to try and make some money out of his Tcl scripting language. Pretty much throughout the article, the word "Scriptics" should be replaced with "Tcl".
As I understand it (not having used Debian since the pre-apt days), apt is just a front end that sits on top of dpkg, much the same way as dselect used to do. There's no reason you couldn't have the same or a very similar front end running on top on RPM. dselect was one of the few reasons I stuck with Debian for so long. But in the end, I just found Red Hat easier to work with. Plus it was nice to have a single distribution on all my platforms (I understand Debian may now have a Sparc version available, but they didn't at the time).
Indeed. In fact, they don't seem to have even looked at their own site from a Unix box. That's why it's full of font tags setting the face to Arial. On my Netscape, that renders as Courier, because unsurprisingly, Arial (being a Micros~1 font) isn't available. What they should be doing is specifying alternative fonts like Helvetica and a generic font family (in this case, "sans-serif").
Yeah, flamebait, I know, but then we are talking about a country that has a "world" series where only one nation competes :-)
AdvanSys have been making decent SCSI controllers for
a while. More importantly, they've been providing official
GPLed drivers for Linux for years. I bought mine
solely on the grounds of their Linux support (at the
time, the Adaptec cards weren't well supported), and
I've never regretted it. I'd recommend them to anyone.
However, compilation times and executable size are nice, but the real test will be runtime performance. Unless it produces faster code, no-one will use it...