Oh well... I think it's quite ludicrous that someone would let an animal browse the web, but I think it'd be neat to see my lab pick out his own food from dogfood.com...
Somebody had better start working on a scent transfer protocol that works over TCP/IP.
I don't see any number keys - also I assume you are typing IN ALL CAPS...
That's a pretty silly assumption, considering the screen shot very clearly shows mixed-case text (and most of it is lower-case, at that).
Like the normal keyboard built-into the Palm (which is based on QWERTY), numbers and symbols are on separate keyboards. The "123" key switches to the number pad, for example. The "shf" and "cap" keys probably work as they do with the standard Palm keyboard as well, as "shift lock" and "caps lock" keys. (the symbols on the keys also update to show what would actually be generated by hitting that key)
This would suck for typing up Canadian or British postal codes. Having the symbols on another keyboard also sucks for writing code. That isn't what these things are for though. They're for writing quick notes in English. (yes, English; the Fitaly isn't really well suited to other natural languages, because the arrangement of the keys is based on the frequency of consecutive letter pairs in English text).
I had Parallax. I got it with a ten-pack of games for the C64. It also included Usagi Yojimbo, Wiz-Ball, a bunch I can't remember at all, and Paradroid. Paradroid was my favorite.
There's a pretty good Java applet version of Paradroid at J*va on the Brain called "Urbanoids". Actually, there are a bunch of other cool Java games there, like Iceblox and 3D-Blox, which the penguin fans among us should enjoy.
The amount of development they do is fairly insignificant when compared to the amount of development effort required to produce all of the software on the CDs they sell.
So I think the original poster's point on this thread is valid: if you are selling into a 99.999% environment, you shouldn't have trouble getting people to buy support contracts from you, and if you do, it may be that you need to look at your support infrastructure and your sales force to see where the problem is.
My point is, having the development staff work for your company isn't much of an asset, except perhaps from a PR standpoint. A company that's totally dedicated to providing support can do so better than a company that is paying for developers who give their work to the competition.
Not really true. Most of the lines of code written aren't part of a 'software product'. They're part of in-house stuff to control payrolls of large companies, operations of factories, etc.
I said a significant proportion of that software. I didn't say all of that software.
Not the original developers? Yeah, I'm gonna trust my 5 nines environment to someone who says they can do the support a little cheaper?
Think of Red Hat/Cygnus or Linuxcare. They can provide support for pretty well any open source software that runs on Linux. You've probably heard of them, but you've probably never heard of Joe Developer. Think about it, both of these companies base their entire businesses on providing support for software that other people wrote.
They can do this for numerous reasons. They're reasonably well known and well established than the typical open source development team. They've also got a lot more resources at theire disposal. To top it off, they can either charge less, or throw in support for additional software (like Linux, the database you're using, whatever) "for free", because they don't have the overhead of doing the original development.
This is also why 95% of software is written by people being paid to do so.
A significant proportion of that software that people are "paid to develop" is then sold by the companies that paid for its development. Walk into any computer store to see what I mean.
The other "freeloaders" frequently would not pay for your product anyway, they are poor studants, super cash straped start-ups, and places where you product is super-over-kill.
Sometimes they wouldn't have paid for it. Some would have though. While there is a myth created by many proprietary software companies that "every pirated copy is a lost sale", many in the open source community like to spread the inverse myth, that none of these unpaid for copies are lost sales.
Fact is, some of them are lost saes, and some aren't. The exact proportion is hard to determine, and of course depends upon the product. With virtually any product though, some of those peopl who would have obtained it for free would have paid for it if that was the only way they could get it.
I think ultimately, you have to try and determine whether it balanaces out. In some situations, it might be acceptable to have some copies "get away for free", given that you'll occasionally be getting bugfixes "for free", plus there's the good PR. For some (most?) software, the lost sales might outweight the benefits of open source.
Componies will pay for support on mature products that havn't been observed to break if their breakage will cause a large loss of money, or if the support contract is quite cheep. How many places that have never had a disk failure buy RAID arrays? Or support contracts on new hardware? Support contracts on the RAIDs even?
I think you're right that many companies, especially for mission-critical applications, will pay for support contracts even if they don't need them. The question is, will they buy them from you, the small-time developer they've never heard of, or will they by their support from something like Red Hat/Cygnus or Linuxcare? Those companies can support your software too, if it's open source. They might even be able to support it better than you can, since they've got more resources at their disposal. They also don't have the overhead of developing your product, so they can potentially charge less, while still making a hgher profit than you would.
This is called 'competition' and is a good thing. There is no such thing as 'creating a market' anyway, nor is anybody entitled to 'own' some particular market niche.
Aside from that the GPL is the perfect poison pill against that kind of free riders.
The people who developed the software need to at least make back their investment in developing the software in the first place. Others can provide cheaper support contracts because they don't have the overhead of actually doing original development. If they can provide the same work at a lower cost, guess who gets the support contract? Not the original developers.
The GPL is the perfect poison pill against people planning on making money by doing original development.
Using a program requires loading it into RAM, which is considered copying. Thus, you can't use the program except if you agree to the license. If you have no license to use copyrighted material, you can't legally use it.
Your interpretation can be summed up as: "You don't have to do what I say, but then you can't use this software at all." If that's the case, then why did they bother stating it at all? The same is true even for Microsoft's EULAs. I don't have to agree with them, but in that case I'm not supposed to use the software.
The only thing that bothers me is: what's to keep them from catering to specific commercial interests?
I think the people at Google understand very clearly that while their money comes from the advertisers, they only have advertisers because of their users. They don't want to piss off their users, and they understand that the key to keeping users is to provide the best results, with no BS.
In fact, they put pretty big restrictions on their advertisers. Ever notice how the ads are really small text-only ads, that are related to your query? If an advertiser doesn't like the restrictions, it's easy to get another advertiser. It's hard to replace a million pissed off users.
Almost any USAn educational instituation could get an.edu
The University of Waterloo, in Waterloo, Ontario, Canada, used to be "waterloo.edu". They later changed to "uwaterloo.ca". So it wasn't limited to "USAn" educational institutions, at one point in time.
Well, let's say I'm an architect. I use L33tCAD, which has a fabulous open CAD format. However, for some odd reason my customers keep sending me stuff in AutoCAD format, which as you know is closed. Unfortunately, L33tCAD doesn't have all the features of AutoCAD, and doesn't really import properply, but heck, I am going to take a stand and tell my customers to shove it even though AutoCAD owns the CAD market.
Yes, I would look like an unprofessional fool.
In fact, in the world of engineering, DXF is more of a "defacto" standard than the closed DWG (AutoCAD drawing) format. AutoCAD can import/export DXF, as can virtually all other CAD software. If you demanded that things be sent in DWG format, you'd look like more of an unprofessional fool.
While there are certainly are benefits to there being a standard document format, that are huge disadvantages to that standard being one that is proprietary and closed. The Word.doc format cannot be extended by anyone outside Microsoft, nor can Word documents be processed by any software (reliably) except Microsoft Word.
Suppose someone wanted a tool that would ensure that their documents didn't contain any deleted information? Or a tool that performed some other useful transformation/validation of their documents? All of these tools essentially have to either come from Microsoft, or be written as Word macros. With an open format, there would be far more innovation in the field of document processing.
And you fail to realize that many of us don't us Microsoft operating systems not for religious reasons, but for practical reasons. 99% of the work I do can't be done as efficiently under Windows as it can under UNIX. Why should I need to have a second computer just to handle that 1% of the time when someone sends me a document in Word format? With an open format, I could view the document on the OS I use for everything else.
To sum it up, yes, there are advantages to having a standard document format. It would be far better if that was an open and portable "de jure" standard, rather than a non-portable, closed, proprietary "de facto" standard. Unfortunately, once a standard has become entrenched, it often becomes very difficult for people to switch to something else even if it's measurably superior.
That's what I meant when I said it's a hack. The original version of that post used, ahem, stronger language. I wasn't out to cause a flame-fest though, so I softened it considerably before posting it.
The way Enlightenment handles relative sizes and positions of "border parts" is also a joke, incidently. You need to specify the index of the part that the current part is based on. This naturally leads to problems if you add or remove border parts before a border part that others point at. E also doesn't do any checking for cyclic dependencies, so it's very easy to inadvertently make a theme that causes E to infinitely recurse as it tries to position/size the border part.
I don't think it would've been that hard to make a simple Yacc/Bison grammar for a real configuration language. Sawfish's adaptation of an existing scripting language is an even better idea though. (I wish it was either Guile or Python though...)
I don't want to start a WM flame-war, but...
on
Gnome On Your PDA?
·
· Score: 1
Anybody who's ever started e with a badly formed theme (and got the lovely pink borders) knows that e itself is very, very fast. It's imlib that's slow, and using all of those pixmaps.
I used E for several months. Then I tried out Sawfish (back when it was called sawmill) just to see what it was like. I immediately noticed that my machine seemed a lot faster, and many operations (like switching desktops) became less clunky. Sawfish uses imlib, and I'm using the same theme I used on E (except the Sawfish version, of course), so I don't think it's fair to blame imlib for E's "lack of speed". E is slow, its configuration language is a hack, and it's becoming more bloated all the time.
They're assuming that nobody has noticed that JVMs can run python, scheme, prolog, and jeeze what else?
Ada, TCL, Haskell, Lisp, BASIC, Logo, ML, Eiffel, Oberon-2, Sather, COBOL (erk), and numerous other languages I've never even heard of. There's a good list here.
Odd, FORTRAN wasn't on that list. There is an f2j compiler available too. Gives new meaning to that old quote:
"Real FORTRAN programmers can program FORTRAN in any language." --Allen Brown
AFC, Microsoft's "Application Foundation Classes" was a class library for Java that claimed to be "platform-neutral". Of course, in actual fact, it relied on bugs in the Microsoft VM, so anything more complicated than "Hello World" wouldn't run correctly anywhere but on Microsoft's VM. I think they've stopped trying to pretend that AFC is really platform neutral by now, but I don't think anyone (except maybe some VB-lovin' MSCE's) uses it anymore, either.
The MKS Toolkit is a complete re-write of the standard "core tools" you'd expect to see on UNIX (rather than a recompile of UNIX tools using a special compiler an library, which is essentially what cygwin is).
Say what? I considered that move by Microsoft to be 'innovative'...
Neither cygwin nor MKS Toolkit are made by Microsoft, so I'm not sure what you're referring to. Cygwin is made by Cygnus (now part of Red Hat), and MKS Toolkit is made by Mortice Kern Systems.
Make a "full-length trailer" available on the Web. Just be sure to make it either start or end with "coming soon to a theatre near you", and advertise it as a trailer for the soon to be released movie.
Pull a Microsoft. It says "Films which receive their first public exhibition or distribution in any manner other than as a theatrical motion picture..." [emphasis mine]. So make it a "non-public" exhibition by having a click-though agreement before people can watch it, ala Microsoft's Kerberos extensions.
But honestly, I don't think it matters. There are other award shows now, and there will be other award shows in the future. It would only be fitting for a "Net movie" awards show to be broadcast on the 'net.
cygwin might as well be unix. It's all built from the same source.
Tools don't work well in a vacuum. The cygwin tools, in an attempt to use Posix compliant pathnames, are mostly incompatible with any non-cygwin tool on Windows. For example, if I want to cat the file foo.txt in the bar directory of drive E:, I have to type:
cat//e/bar/foo.txt
But if I want to edit it in Vim, I have to type:
vim e:/bar/foo.txt
This becomes especially irritating if you try and do things like:
find//e/snarf -type f -name 'pattern' | xargs winprg
where winprg is some windows program. Cygwin's find will of course dump out a bunch of cygwin-style pathnames. It is occasionally possible to fool some of the cygwin tools into using a windows-style pathname. I shouldn't have to be constantly second-guessing my tools to use them though.
Also, something I recently discovered is that you can't cat together binary files with the cygwin cat! cat is a text tool, so it doesn't work on binary files. I think it stops after the first ^Z. I have yet to see a version of cat on UNIX that didn't happliy concatenate binary files correctly.
It's been a while since I downloaded the cygwin tools (I've got b20 installed), so it might have changed since then. I hope so.
I've also used the MKS toolkit. The MKS Toolkit is a complete re-write of the standard "core tools" you'd expect to see on UNIX (rather than a recompile of UNIX tools using a special compiler an library, which is essentially what cygwin is). Unfortunately, the only shell included is ksh. (I think the newest version might also include csh or tcsh) I would much rather use bash than ksh (nicer keybindings overall). The MKS ksh also has some incredibly irritating bugs relating to filename completeion and mixed-case filenames. MKS Toolkit also costs a couple of hundred dollars... significantly more than an entire Linux distro, which would include an OS plus the tools.
Another thing that drives me crazy about trying to develop under Windows is (believe it or not) the stupid "console" windows. It's a bit minor, but xterm, rxvt, and even gnome-terminal are all significantly better than the stupid Win32 console. Cutting and pasting is easier (and if you put the Win32 console in "Quickedit" mode, it acts stupid when you click on it to focus. It selects where you clicked, and won't let you type.) and you can actually resize without having to go into a "Properties" dialog.
Plus there's the fact that "mapped drives" are flakey on Windows. If you ever try to build a large project on a Windows build machine, but you have the sources on some other server (yes, NT or UNIX) you'll start getting all sorts of weird compiler errors, seemingly at random. I'm not sure exactly what causes this flakiness. I thought NFS was bad, but SMB seems to be much worse.
the race will be on to market gene therapy for couples to ensure their children are super-geniuses, who will all go out and found dot.coms and make a fortune.
why dont people get the idea "DO NOT REINVENT THE WHEEL"
Throwing out your old nasty code so you can rewrite it isn't called "reinventing the wheel". It's called "throwing one away". Yes, GIMP 2.0 might take longer to be released. Provided they don't go crazy and decide to make an "application platform" instead of the thing they're supposed to be making, it could actually speed up development, because the architecture should be cleaner and easier to understand. Besides, the GIMP code isn't nearly as nasty as the Netscape code was.
Maybe you're referring to the fact that GIMP is an image manipulation/paint program, and there are lots of those out there. Not many of them are scriptable though. Very few run on Linux. Even less are open source, and let you make your own tweaks/bugfixes/improvements. Plus it's free (as in beer -- I covered the other free in the previous sentence). These attributes together make the GIMP useful and valuable to some people. If it had no unique qualities, then maybe it would be "reinventing the wheel". But that isn't the case here.
Gimp-2.0 will be a total rewrite. This doesn't mean that we will not reuse any code from the current codebase, but we want to change the basic architecture and build the most advanced image processing system out there.
This sounds like a good plan to me. It would be really nice to be able to write scripts that run GIMP and execute efficiently. For example, if you're making images for a website, you probably want your "source" images to be in xcf (gzipped or bzipped probably), but the "published" images need to be in GIF, JPEG, or PNG. Having a script (or Makefile...) that would tell GIMP to produce the published images whenever the "source" images change would be incredibly useful. This is somewhat possible today, but GIMP has a very long startup time (so invoking it once for each image is not a good idea), plus it seems to be really unstable when running in batch mode.
Doing a "complete rewrite" will also make it easier for more developers to get involved. It's always hard to get into the code of something that's been around a while and has accumulated significant bloat. (I'm not saying that GIMP is particularly bloated, but all projects tend to "fatten" with time)
BTW, has anyone else tried to get involved in GIMP development? Whenever I went to the GIMP IRC channel to ask some GIMP development questions, people always seemed really reluctant to talk about development, and instead just wanted to talk about random subjects. Where's the place to talk about GIMP development?
Slashdot Mirror
Hmmm, the Wine logo seems to be a bit unstable on my system. :-)
BTW, how was the logo made? It would be cool if it was drawn with a tool running under Wine...
Oh well... I think it's quite ludicrous that someone would let an animal browse the web, but I think it'd be neat to see my lab pick out his own food from dogfood.com...
Somebody had better start working on a scent transfer protocol that works over TCP/IP.
because they can learn words you don't need to teach them sign language.
You need to "learn words" in order to learn sign language. Gorillas can't speak words, but that may be a physical problem more than a mental one.
(okay, maybe I'm being pedantic...)
I don't see any number keys - also I assume you are typing IN ALL CAPS...
That's a pretty silly assumption, considering the screen shot very clearly shows mixed-case text (and most of it is lower-case, at that).
Like the normal keyboard built-into the Palm (which is based on QWERTY), numbers and symbols are on separate keyboards. The "123" key switches to the number pad, for example. The "shf" and "cap" keys probably work as they do with the standard Palm keyboard as well, as "shift lock" and "caps lock" keys. (the symbols on the keys also update to show what would actually be generated by hitting that key)
This would suck for typing up Canadian or British postal codes. Having the symbols on another keyboard also sucks for writing code. That isn't what these things are for though. They're for writing quick notes in English. (yes, English; the Fitaly isn't really well suited to other natural languages, because the arrangement of the keys is based on the frequency of consecutive letter pairs in English text).
I had Parallax. I got it with a ten-pack of games for the C64. It also included Usagi Yojimbo, Wiz-Ball, a bunch I can't remember at all, and Paradroid. Paradroid was my favorite.
There's a pretty good Java applet version of Paradroid at J*va on the Brain called "Urbanoids". Actually, there are a bunch of other cool Java games there, like Iceblox and 3D-Blox, which the penguin fans among us should enjoy.
Redhat actually does do a lot of development.
The amount of development they do is fairly insignificant when compared to the amount of development effort required to produce all of the software on the CDs they sell.
So I think the original poster's point on this thread is valid: if you are selling into a 99.999% environment, you shouldn't have trouble getting people to buy support contracts from you, and if you do, it may be that you need to look at your support infrastructure and your sales force to see where the problem is.
My point is, having the development staff work for your company isn't much of an asset, except perhaps from a PR standpoint. A company that's totally dedicated to providing support can do so better than a company that is paying for developers who give their work to the competition.
Not really true. Most of the lines of code written aren't part of a 'software product'. They're part of in-house stuff to control payrolls of large companies, operations of factories, etc.
I said a significant proportion of that software. I didn't say all of that software.
Not the original developers? Yeah, I'm gonna trust my 5 nines environment to someone who says they can do the support a little cheaper?
Think of Red Hat/Cygnus or Linuxcare. They can provide support for pretty well any open source software that runs on Linux. You've probably heard of them, but you've probably never heard of Joe Developer. Think about it, both of these companies base their entire businesses on providing support for software that other people wrote.
They can do this for numerous reasons. They're reasonably well known and well established than the typical open source development team. They've also got a lot more resources at theire disposal. To top it off, they can either charge less, or throw in support for additional software (like Linux, the database you're using, whatever) "for free", because they don't have the overhead of doing the original development.
This is also why 95% of software is written by people being paid to do so.
A significant proportion of that software that people are "paid to develop" is then sold by the companies that paid for its development. Walk into any computer store to see what I mean.
The other "freeloaders" frequently would not pay for your product anyway, they are poor studants, super cash straped start-ups, and places where you product is super-over-kill.
Sometimes they wouldn't have paid for it. Some would have though. While there is a myth created by many proprietary software companies that "every pirated copy is a lost sale", many in the open source community like to spread the inverse myth, that none of these unpaid for copies are lost sales.
Fact is, some of them are lost saes, and some aren't. The exact proportion is hard to determine, and of course depends upon the product. With virtually any product though, some of those peopl who would have obtained it for free would have paid for it if that was the only way they could get it.
I think ultimately, you have to try and determine whether it balanaces out. In some situations, it might be acceptable to have some copies "get away for free", given that you'll occasionally be getting bugfixes "for free", plus there's the good PR. For some (most?) software, the lost sales might outweight the benefits of open source.
Componies will pay for support on mature products that havn't been observed to break if their breakage will cause a large loss of money, or if the support contract is quite cheep. How many places that have never had a disk failure buy RAID arrays? Or support contracts on new hardware? Support contracts on the RAIDs even?
I think you're right that many companies, especially for mission-critical applications, will pay for support contracts even if they don't need them. The question is, will they buy them from you, the small-time developer they've never heard of, or will they by their support from something like Red Hat/Cygnus or Linuxcare? Those companies can support your software too, if it's open source. They might even be able to support it better than you can, since they've got more resources at their disposal. They also don't have the overhead of developing your product, so they can potentially charge less, while still making a hgher profit than you would.
This is called 'competition' and is a good thing. There is no such thing as 'creating a market' anyway, nor is anybody entitled to 'own' some particular market niche.
Aside from that the GPL is the perfect poison pill against that kind of free riders.
The people who developed the software need to at least make back their investment in developing the software in the first place. Others can provide cheaper support contracts because they don't have the overhead of actually doing original development. If they can provide the same work at a lower cost, guess who gets the support contract? Not the original developers.
The GPL is the perfect poison pill against people planning on making money by doing original development.
Using a program requires loading it into RAM, which is considered copying. Thus, you can't use the program except if you agree to the license. If you have no license to use copyrighted material, you can't legally use it.
Your interpretation can be summed up as: "You don't have to do what I say, but then you can't use this software at all." If that's the case, then why did they bother stating it at all? The same is true even for Microsoft's EULAs. I don't have to agree with them, but in that case I'm not supposed to use the software.
The only thing that bothers me is: what's to keep them from catering to specific commercial interests?
I think the people at Google understand very clearly that while their money comes from the advertisers, they only have advertisers because of their users. They don't want to piss off their users, and they understand that the key to keeping users is to provide the best results, with no BS.
In fact, they put pretty big restrictions on their advertisers. Ever notice how the ads are really small text-only ads, that are related to your query? If an advertiser doesn't like the restrictions, it's easy to get another advertiser. It's hard to replace a million pissed off users.
Almost any USAn educational instituation could get an .edu
The University of Waterloo, in Waterloo, Ontario, Canada, used to be "waterloo.edu". They later changed to "uwaterloo.ca". So it wasn't limited to "USAn" educational institutions, at one point in time.
Well, let's say I'm an architect. I use L33tCAD, which has a fabulous open CAD format. However, for some odd reason my customers keep sending me stuff in AutoCAD format, which as you know is closed. Unfortunately, L33tCAD doesn't have all the features of AutoCAD, and doesn't really import properply, but heck, I am going to take a stand and tell my customers to shove it even though AutoCAD owns the CAD market.
.doc format cannot be extended by anyone outside Microsoft, nor can Word documents be processed by any software (reliably) except Microsoft Word.
Yes, I would look like an unprofessional fool.
In fact, in the world of engineering, DXF is more of a "defacto" standard than the closed DWG (AutoCAD drawing) format. AutoCAD can import/export DXF, as can virtually all other CAD software. If you demanded that things be sent in DWG format, you'd look like more of an unprofessional fool.
While there are certainly are benefits to there being a standard document format, that are huge disadvantages to that standard being one that is proprietary and closed. The Word
Suppose someone wanted a tool that would ensure that their documents didn't contain any deleted information? Or a tool that performed some other useful transformation/validation of their documents? All of these tools essentially have to either come from Microsoft, or be written as Word macros. With an open format, there would be far more innovation in the field of document processing.
And you fail to realize that many of us don't us Microsoft operating systems not for religious reasons, but for practical reasons. 99% of the work I do can't be done as efficiently under Windows as it can under UNIX. Why should I need to have a second computer just to handle that 1% of the time when someone sends me a document in Word format? With an open format, I could view the document on the OS I use for everything else.
To sum it up, yes, there are advantages to having a standard document format. It would be far better if that was an open and portable "de jure" standard, rather than a non-portable, closed, proprietary "de facto" standard. Unfortunately, once a standard has become entrenched, it often becomes very difficult for people to switch to something else even if it's measurably superior.
That's what I meant when I said it's a hack. The original version of that post used, ahem, stronger language. I wasn't out to cause a flame-fest though, so I softened it considerably before posting it.
The way Enlightenment handles relative sizes and positions of "border parts" is also a joke, incidently. You need to specify the index of the part that the current part is based on. This naturally leads to problems if you add or remove border parts before a border part that others point at. E also doesn't do any checking for cyclic dependencies, so it's very easy to inadvertently make a theme that causes E to infinitely recurse as it tries to position/size the border part.
I don't think it would've been that hard to make a simple Yacc/Bison grammar for a real configuration language. Sawfish's adaptation of an existing scripting language is an even better idea though. (I wish it was either Guile or Python though...)
Anybody who's ever started e with a badly formed theme (and got the lovely pink borders) knows that e itself is very, very fast. It's imlib that's slow, and using all of those pixmaps.
I used E for several months. Then I tried out Sawfish (back when it was called sawmill) just to see what it was like. I immediately noticed that my machine seemed a lot faster, and many operations (like switching desktops) became less clunky. Sawfish uses imlib, and I'm using the same theme I used on E (except the Sawfish version, of course), so I don't think it's fair to blame imlib for E's "lack of speed". E is slow, its configuration language is a hack, and it's becoming more bloated all the time.
Ada, TCL, Haskell, Lisp, BASIC, Logo, ML, Eiffel, Oberon-2, Sather, COBOL (erk), and numerous other languages I've never even heard of. There's a good list here.
Odd, FORTRAN wasn't on that list. There is an f2j compiler available too. Gives new meaning to that old quote:
AFC, Microsoft's "Application Foundation Classes" was a class library for Java that claimed to be "platform-neutral". Of course, in actual fact, it relied on bugs in the Microsoft VM, so anything more complicated than "Hello World" wouldn't run correctly anywhere but on Microsoft's VM. I think they've stopped trying to pretend that AFC is really platform neutral by now, but I don't think anyone (except maybe some VB-lovin' MSCE's) uses it anymore, either.
Neither cygwin nor MKS Toolkit are made by Microsoft, so I'm not sure what you're referring to. Cygwin is made by Cygnus (now part of Red Hat), and MKS Toolkit is made by Mortice Kern Systems.
- Make a "full-length trailer" available on the Web. Just be sure to make it either start or end with "coming soon to a theatre near you", and advertise it as a trailer for the soon to be released movie.
- Pull a Microsoft. It says "Films which receive their first public exhibition or distribution in any manner other than as a theatrical motion picture..." [emphasis mine]. So make it a "non-public" exhibition by having a click-though agreement before people can watch it, ala Microsoft's Kerberos extensions.
But honestly, I don't think it matters. There are other award shows now, and there will be other award shows in the future. It would only be fitting for a "Net movie" awards show to be broadcast on the 'net.cygwin might as well be unix. It's all built from the same source.
//e/bar/foo.txt
//e/snarf -type f -name 'pattern' | xargs winprg
Tools don't work well in a vacuum. The cygwin tools, in an attempt to use Posix compliant pathnames, are mostly incompatible with any non-cygwin tool on Windows. For example, if I want to cat the file foo.txt in the bar directory of drive E:, I have to type:
cat
But if I want to edit it in Vim, I have to type:
vim e:/bar/foo.txt
This becomes especially irritating if you try and do things like:
find
where winprg is some windows program. Cygwin's find will of course dump out a bunch of cygwin-style pathnames. It is occasionally possible to fool some of the cygwin tools into using a windows-style pathname. I shouldn't have to be constantly second-guessing my tools to use them though.
Also, something I recently discovered is that you can't cat together binary files with the cygwin cat! cat is a text tool, so it doesn't work on binary files. I think it stops after the first ^Z. I have yet to see a version of cat on UNIX that didn't happliy concatenate binary files correctly.
It's been a while since I downloaded the cygwin tools (I've got b20 installed), so it might have changed since then. I hope so.
I've also used the MKS toolkit. The MKS Toolkit is a complete re-write of the standard "core tools" you'd expect to see on UNIX (rather than a recompile of UNIX tools using a special compiler an library, which is essentially what cygwin is). Unfortunately, the only shell included is ksh. (I think the newest version might also include csh or tcsh) I would much rather use bash than ksh (nicer keybindings overall). The MKS ksh also has some incredibly irritating bugs relating to filename completeion and mixed-case filenames. MKS Toolkit also costs a couple of hundred dollars... significantly more than an entire Linux distro, which would include an OS plus the tools.
Another thing that drives me crazy about trying to develop under Windows is (believe it or not) the stupid "console" windows. It's a bit minor, but xterm, rxvt, and even gnome-terminal are all significantly better than the stupid Win32 console. Cutting and pasting is easier (and if you put the Win32 console in "Quickedit" mode, it acts stupid when you click on it to focus. It selects where you clicked, and won't let you type.) and you can actually resize without having to go into a "Properties" dialog.
Plus there's the fact that "mapped drives" are flakey on Windows. If you ever try to build a large project on a Windows build machine, but you have the sources on some other server (yes, NT or UNIX) you'll start getting all sorts of weird compiler errors, seemingly at random. I'm not sure exactly what causes this flakiness. I thought NFS was bad, but SMB seems to be much worse.
the race will be on to market gene therapy for couples to ensure their children are super-geniuses, who will all go out and found dot.coms and make a fortune.
It doesn't take a "super-genius" to found a dot.com. It just takes a monkey of moderate intelligence who wears a suit.
why dont people get the idea "DO NOT REINVENT THE WHEEL"
Throwing out your old nasty code so you can rewrite it isn't called "reinventing the wheel". It's called "throwing one away". Yes, GIMP 2.0 might take longer to be released. Provided they don't go crazy and decide to make an "application platform" instead of the thing they're supposed to be making, it could actually speed up development, because the architecture should be cleaner and easier to understand. Besides, the GIMP code isn't nearly as nasty as the Netscape code was.
Maybe you're referring to the fact that GIMP is an image manipulation/paint program, and there are lots of those out there. Not many of them are scriptable though. Very few run on Linux. Even less are open source, and let you make your own tweaks/bugfixes/improvements. Plus it's free (as in beer -- I covered the other free in the previous sentence). These attributes together make the GIMP useful and valuable to some people. If it had no unique qualities, then maybe it would be "reinventing the wheel". But that isn't the case here.
Gimp-2.0 will be a total rewrite. This doesn't mean that we will not reuse any code from the current codebase, but we want to change the basic architecture and build the most advanced image processing system out there.
This sounds like a good plan to me. It would be really nice to be able to write scripts that run GIMP and execute efficiently. For example, if you're making images for a website, you probably want your "source" images to be in xcf (gzipped or bzipped probably), but the "published" images need to be in GIF, JPEG, or PNG. Having a script (or Makefile...) that would tell GIMP to produce the published images whenever the "source" images change would be incredibly useful. This is somewhat possible today, but GIMP has a very long startup time (so invoking it once for each image is not a good idea), plus it seems to be really unstable when running in batch mode.
Doing a "complete rewrite" will also make it easier for more developers to get involved. It's always hard to get into the code of something that's been around a while and has accumulated significant bloat. (I'm not saying that GIMP is particularly bloated, but all projects tend to "fatten" with time)
BTW, has anyone else tried to get involved in GIMP development? Whenever I went to the GIMP IRC channel to ask some GIMP development questions, people always seemed really reluctant to talk about development, and instead just wanted to talk about random subjects. Where's the place to talk about GIMP development?