Only if you want the outside world to be able to talk to your lightbulbs and fridge!
Good point. Very few household devices would need to talk to the outside world. Although perhaps more than at first glance. Your fridge might want to talk to its manufacturer (or vice versa) for software updates or service calls if it detects a problem, for example. Your blender might want to conduct an email love affair with that cute toaster oven it sat next to on the store shelf. That sort of thing.:-)
Meanwhile, how long before somebody builds a webcam into a light bulb?
The overall forecast for power-line-based home networks is now beyond the 32 million nodes initally projected.
Time for IPv6? Or do we just put every toaster, refrigerator and light bulb in the house on an unroutable domain and handle the translation in the router/firewall/proxy built into the fuse box?
More seriously, this ain't bad. Speed is comparable to 10base Ethernet, but I'll still run Cat 5 cable in my new house (faster, and for now cheaper, since I already have the NICs and hub). One nice thing about signal-over-AC is that you don't need a separate cable to the device -- the power cord is the network cable, very convenient for appliance-type devices.
While he does raise a few good points, I think the manner in which he does so is more grandstanding than anything else. It actually distracts from the main message. Reminds me of the time at a Usenix about 15 years ago that he delivered a paper while dressed in a harem girl outfit.
Yes, in some ways Linux is playing "catch up" -- it has to, it didn't magically spring into existence fully formed. But in other ways (eg, look at some of the details of the kernel architecture) it is leading edge. At least with respect to real-world software, as opposed to academic exercises like Version 8 Unix or Plan 9.
As for MS innovation -- well, they've boldly copied the UI from such as Mac and NeXT, and they've boldly gone where no sane software designer has gone before -- dissolved the barrier between application and OS making such wonderful features as ILOVEYOU.vbs and a whole plague of viruses and BSODs possible. If that's innovation, I'll take playing catch-up, thanks.
Motif is pretty bad, [...] I've never tried coding any Motif apps,
Another expert heard from.:-)
[GTK is] not as ugly as Motif,
By default they look pretty much the same.
ontop of things GTK is themeable,
So is OpenMotif now. There's (in dev, almost alpha) a patch, it even reads GTK themes. And the developers have proposed an additional API back to the GTK project to make extracting themes (and building theme editors) easier.
Quoting from the MotifZone discussion
The GTK+ converter converts existing GTK+ themes to a resource file. The Motif Theme engine will be kicked off if a special resource is set. The Motif Theme Engine will read the Motif Theme (the converted GTK+ theme) and then be applied to the Motif user interface. This should all work with no changes to the API or the application itself.
Phase 2 Once Phase 1 becomes stable, phase 2 will be to merge the GTK+ theme converter in with the Motif Theme Engine and dynamically apply the theme.
To simplify this process and minimize memory/cpu resources longer term, we have suggested an addition to the GTK+ API to allow us to extract the theme (this API would also be useful for GTK+ theme editors in general).
They also plan to do something similar for Qt 2.0.
The open source guidelines specify that there has to be no discrimination against a particular area or endeavor of work
Except (at least in the GPL case) against linking to "incompatibly licensed" code.
the [OpenMotif] license [...] only lets you use it on certain platforms.
Not quite. It'll let you use it on any platform so long as that platform is open source. If Windows (hah) or Solaris (maybe) were to open their source tomorrow, you could freely use OpenMotif on them (although that might not be helpful on Windows:-). The restriction is not on the specific platform, but on the license of the platform. In this sense it is no different than the GPL. (Read that carefully - I said "in this sense" -- obviously there are other senses in which it differs.)
this is restrictionware
And the GPL is not?
Both the GPL and the OpenMotif licenses place restrictions on the licensee. In both cases the effect is to encourage software to be free.
Correlation between liking Motif and license?
on
RMS On 'Open' Motif
·
· Score: 5
On a quick read of the above messages, there seems to be a fairly high correlation between one's opinion of Motif and one's opinion of the OpenMotif license. Those that think the license sucks seem (with exceptions) to also think that Motif is ugly, dead, etc. Well, they obviously aren't going to use it anyway, so who cares what they think?
Personally, I like Motif. I've developed with it (and LessTif) for nearly a decade (on and off), it has mature GUI builders, a UIL, is Xt-based (so it cooperates with other Xt-based toolkits, unlike GTK and Qt), and there's already a patch (in alpha) to OpenMotif to make it themeable (using GTK themes). If it's so ugly, why do other toolkits copy its look? (Granted, the defaults are poorly chosen, but who uses the defaults?) And while I would like to see the OpenMotif license more open that it is, Stallman seems oblivious to the subtleties of the license. As I wrote elsewhere:
"they have not made Motif available within the free software community; instead, they have invited the people in the free software community to leave the community by using Motif." -- RMS
This is where he's wrong. To that part of the free software community that only uses free software, Open Motif is indeed free in all senses. It's only if folks have already chosen to leave the free software community by using a non-free OS that OpenMotif becomes non-free.
Motif is hardly dead -- too many existing projects out there use it and there's too big an expertise pool of existing Motif developers (on the proprietary Unix side) for that.
Heck, X10 (the version before X11, not the home automation system) had transparent windows.
Mind, I think the usage of the term is somewhat different. (IIRC, you couldn't draw anything on a transparent window, it was just useful for intercepting events. Gosh it's been a long time since I did X10 programming...)
"the energy cost of sending humans and their life-support supplies into space is still too high"
The energy cost is perhaps a couple of dollars a pound, at current energy (eg electricity) rates. Yes, it takes a fair bit of energy to get there, but that isn't the driving cost of the system. The fuel costs for a Shuttle launch are perhaps a few million dollars, out of the $500 million or more per launch actual cost.
The problem is (a) systems engineering (the Shuttle design goals seem to have been to ensure that every congressional district in the US has some involvement in it, a real kludge) and (b) the politics of coming up with something that threatens to break the rice bowls of Big Aerospace. (If you though Microsoft tactics were bad, you ain't seen nothing compared to what NASA and the big aerospace companies are willing to do to defend their monopoly and government handouts).
A lot of us that had/have the Grand Dream have seen it smashed over and over by the likes of NASA bureaucrats. It isn't the organization it was in the 1960s, at all. (As witness, for example, the recent string of brilliant Mars successes.)
Somewhat misleading. I don't know whether your BSD bias has crept into your comments, or whether your (apparent) ignorance on some of the fine points has caused the bias in the first place.
Either way, some clarification is in order.
GPL can never be used in a commercial product
So what are Red Hat, SuSE, and Caldera, to name but a few? Perhaps you meant "closed source" product, rather than "commercial". There is a difference.
GPL code can never be used in any application that is not also 100% GPL code
Not quite correct. It can be used in any non-GPL'd application that is not distributed. There's a lot of software development done entirely for in-house use. The GPL might technically apply to these if they use GPL'd source, but in practise it never applies if the application is never distributed to anyone else.
Finally, any mods made to GPL code must be made public - you must post the source, or provide it on request.
Same error as above. If I never post (or otherwise distribute) the binaries of mods I make to GPL'd code, I need never post the sources, either, and I can tell anybody asking for them to buzz off.
BSD can be used by anybody, for anything.
True. Some people, though, regard this as a serious flaw. Microsoft (among others) has made a lot of money off of BSD'd code, with no particular benefit to the rest of the developer community.
The proponents of GPL feel that imposing a non-commercial business model is the best way to keep software "free"
Cart before the horse. The GPL doesn't impose a non-commercial business model, although it does tend to (as a byproduct, via free market forces) enforce an upper limit on "what the market will bear" for the software.
Proponents of BSD feel it is the only "free" license, as it doesn't require you to become a non-profit to use the code
Neither does the GPL.
you can integrate it [BSD code] into proprietary [closed source] apps
This is certainly an advantage for those that want to take proprietary advantage of code somebody else has written. It's hard to see how this is an advantage to the authors of such code, unless they're happy just knowing that some of their code is buried in a Microsoft or Apple program somewhere, one that they can't even use unless they pay Microsoft or Apple for the privilege. Still, it seems that there are such folks out there.
Personally, I think that corporate subsidized BSD-type development WILL easily surpass GPL's contributions - as more and more corporations realize the value of releasing open source.
To date this doesn't seem to be the case. Most corporate developed software that has been open sourced has been released under some license that is far more restrictive than BSD.
Some corps release their work as GPL to prevent competitors from being able to benefit from it,
Not quite. The competitors may certainly benefit from it, since they may freely use it. However, the competitors won't benefit any more than the original authors, since they (competitors) can't incorporate the GPL'd source into their own closed product, or if they do incorporate the GPL'd code, they must then open up their own extensions such that the original company also has access. (Effectively levelling the playing field for all involved.)
Of course, there are problems using BSD code in GPL applications, as GPL demands that the code become GPL. In most of these cases, the BSD authors have allowed GPL forks of the code.
In most cases the BSD authors have no control over whether their code goes into GPL'd applications. So long as the BSD license doesn't place any restrictions on the code that the GPL doesn't (and in some cases where there's an advertising or author-acknowledgement clause, it might), the GPL "infects" any BSD-ish (or public domain, for that matter) code that gets rolled in to a GPL'd application. (Of course, the originalBSD or PD code is available outside the GPL). BSD authors shouldn't be particularly upset about this -- the license allows their code to be incorporated into totally closed and proprietary applications, too.
n the end, I think corporate subsidized BSD has to win. It actually has financial backing, so programmers can earn a paycheck for their work, instead of working as a waiter to subsidize your coding as one of the GPL authors recommended.
Hey, everyone should have a hobby. More seriously, whichcorporate subsidized BSD? Apple? Meanwhile, there are plenty of places (Red Hat, for example) paying programmers to write GPL'd code.
Competing implementations of an API is no bad thing. "Choice for the sake of choice" aside, in any software implementation there are going to be trade-offs, design decisions and compromises that will give the result different properties (memory footprint, speed, etc.) than if different decisions had been made.
Even if (when) Motif goes to a completely LGPL/X/whatever Open Source license, there may be situations where you'd rather use Lesstif because it fits your design tradeoffs better.
(Of course, one of the problems here is that while Lesstif and Motif may be fully compatible at the API level, they aren't necessarily "bug for bug" compatible. Since most (all?) commercial Motifs are derived from the same reference source, those are generally bug for bug compatible. (I'm talking about behaviour bugs - misimplementations of the spec, not things like memory leaks.))
I doubt you'll be able to link both into the same program at once, but I can't imagine why you'd want to. Certainly they can both live on the same machine at once, just set up different lib and include paths for them, with choices made at compile and link times.
I think this is neat. Even if the incompatible licenses mean that Lesstif can't use Motif code directly (of course, if Motif were LGPL'd there'd be no need for Lesstif at all), this makes reverse engineering Motif a whole heck of a lot easier, so Lesstif can become more completely compatible. (Meanwhile, the Lesstif project also has some addtional widget sets that help reproduce/improve-upon commercial Motif widget sets.)
This also encourages the porting of existing Unix apps that require real Motif (ie use features that aren't complete in Lesstif), so we'll see more (commercial) software for Linux and *BSD. And many of those in-house apps (I'm thinking of a couple in particular that I've been involved with, a million or so lines of code, Motif-based GUI, and requiring something like a Sun workstation on every user's desk) will port more cleanly to Linux without having to worry about buying Motif licenses. (Sure, the Motif license for Linux was cheaper than a Sun-Solaris box anyway, but the minds of pointy haired bosses work in mysterious ways.)
agreements that basically said the company owns any idea they think of while in employment of the company (in or outside of work).
Yep, such language is not uncommon in such NDA/IP ownership/etc agreements. A while back I was asked to sign such (along with the usual paperwork) as a condition of employment at [large long distance telco]. They faxed me the docs to sign and send back.
Now, they hadn't countersigned the docs, and I figure anything in a contract is open to negotiation, but rather than simply cross out the offending verbiage I retyped the document, printed it out in the same format using the same font, and signed and returned that. Not my fault if they didn't read it before accepting it.
seems like I remember seeing multiple monitor setups udner X as early as '88.
We were running some multi-headed machines back in early 1987, but if I recall right X treated each of them as a different display (foo:0, foo:1 etc). This was under X10, not X11. Might have been with X11 that came the ability to treat them as two views onto a single virtual display.
If the above phrases are true (and frankly I'm a bit sceptical), then somebody is writing lousy software (or they're writing it in perl or something equally inappropriate for the task). This goes double if it's a driver for something that offers hardware acceleration for DVD playing, like the Hollywood card.
For comparison, under Windows (yeah, I know, but there's no Linux software) my puny little 233MHz Winchip (supports MMX and 3Dnow! but otherwise is essentially a 486 in drag - 156 bogomips) plays DVDs (using PowerDVD) at a viewable frame rate (it isn't 30 fps, probably more like 20) with no sound problems. All this with software decoding (the cheap VGA card doesn't add any support either).
There are Linux software solutions that require a couple of passes -- decrypting the VOBs and then playing them via eg mpeg2play -- if any driver for hardware decoding is worse than that, the only excuse is that it's a debugging version and must be writing a ton of stuff to a log file somewhere.
(Of course, current solutions are for strictly linear playback, you miss out on some of the extra features like branching or multiple camera angles.)
It may well be encrypted too, but the message (encrypted or not) is also hidden by steganography: the thing doesn't look like an encrypted message. Which was probably the point.
My guess is is that it's stego'd into the jpg image. Hmm, maybe not, that'd require a bit more than pen and notebook unless one was really a glutton for punishment. So it's likely in the text. But $25 isn't enough to persuade me to spend much more time on it.
Oh, that day is already here. JIT compiling VMs have been around for a while, and processor speeds are at least 4x if not 8x faster than they were when Java was introduced.
But remember Transmeta? Remember that their Crusoe chip, while currently targeted at the x86 market, was also demoed running Java byte code 'natively' (ie doing the code morph thing from Java bytecode to Crusoe internal instructions).
I like Java for apps because its cleaner and easier to debug than C++, and has a whopping great set of (cross platform!) APIs. And for many apps, the speed is already good enough. But I still use C for lower level stuff, and C or C++ if I need to tie in to an existing C library. (Why mess with JNI).
nd I wouldnt go on a plane where the pilot could get out and tamper with it.
Heck, I am a pilot and neither I nor any pilot I know would fly a plane that couldn't be opened up and inspected by the pilot. Now, I'm not likely to go fixing anything other than low fuel or oil, since I'm not an airframe/powerplant mechanic -- unless for some reason I've had to make a forced landing somewhere and it's the only way I have to get out.
(Not only that, but part of the pre-takeoff checklist is, effectively, to deliberately induce faults (magneto failure, fuel starvation) to ensure that the engine responds as expected.)
So what happens if (for some bizarre reason) Adobe decides to get out of the video editing business and drops all support for Premiere? This time you're stuck with proprietary file formats and not even the option of hiring somebody to continue to support the package, because it's closed source.
(And while Adobe might be an extreme example, I'm sure there are plenty of proprietary software vendors who have gone toes-up and left their customers in the lurch.)
Which is to say, the Motif API and functionality can be had for free via Lesstif. If you want the honest-to-god Motif reference implementation from X/Open, that costs.
That said, your first pararaph is indisputable (at least, I won't dispute it. Anything is disputable here on/.) A lot of unix/Motif programmers are discovering Linux/Lesstif, and the skill set ports very nicely, but you raise good points in your second paragraph. I wouldn't say the nails are quite in the coffin, but the developer certainly has more choice now than in the days when the only real choice was Motif (given that the alternatives were a dying OpenLook or lame raw Xlib. I've worked on X GUIs back in the days before Motif (on X10), so we rolled our own inhouse menu languages and forms languages. Motif was a godsend.)
X Resources are a cheap cop-out for providing source, for real customisability
Not a cop-out at all. To take a personal example, when I rolled out a (in-house) app to a couple of hundred users, there's no way that 99% of them have the ability (skill) to customize source (let alone that management is going to let them do that), but they all (in theory, maybe half in practise) have the ability to make a few simple edits to an X resource file. (And many of them did.)
Could I have added user-customization as part of the program (ie preferences settings, etc)? Sure, if I'd been allowed to take twice the time to complete the project (a smart GUI front end to a legacy app for designing high speed copper telco circuits). That wasn't an option, getting the needed application functionality in there was the important thing, customizabilty via resources was just a bonus that came free with using Motif.
(BTW, the app had to run on a Pyramid, with folks using their Sparcstations as X terminals to this particular app. Has Qt or GTK been ported to the Pyramid yet?)
take a look at KDE2's XML GUI
That's a nice approach, and not necessarily restricted to any particular GUI toolkit. But I expect it will be a while before anyone planning a multi-hundred-thousand-(or million)-dollar enterprise project makes it a critical component. (Just as a ballpark, the above project from start to rollout was probably in the $300,000 range, including design, coding, QA, documentation, and trainging the users (not counting salary for the users while in training))
Nothing could be further from the truth. There are more lines of code written for Motif than for any other unix GUI out there, and that's probably still true. Sure, there's a lot of Qt and GTK showing up on Linux, but all (well most) the in-house custom apps written for traditional unix (AIX, Solaris, HP/UX, etc) are Motif.
When you're building enterprise applications that take years and dozens of programmers to design and implement (and I've worked on a few such in my time), you choose a GUI that (a) is reasonably mature (measured in feature stability for years, not months), (b) is well documented (the O'Reilly Motif books have been around forever. Docs for Qt or GTK is just starting to appear), (c) is understood by the majority of your unix programming staff, and (d) is well supported by mature third-party tools like GUI-builders, prototyping languages, etc, etc. To the extent that I've seen any move away from this, it hasn't been toward doing GTK or Qt on a unix desktop machine, but rather toward putting the GUI on NT workstation communicating with the main app logic on a unix server.
Motif is neither particularly hard to program (GUI builders aside, it's real easy to wrap C++ classes around) nor inherently ugly. I find Motif far easier than Qt or GTK to program for the simple reason that I've done a ton of the former and very little of the latter; I suspect the converse is true for those claiming that Motif is hard. And I've seen incredibly ugly interfaces built with every GUI toolkit out there -- some people just have no sense of aesthetics or interface design. But it's also possible to build some very good looking Motif interfaces (and there are a couple of good books on that subject.)
[NB, for brevity I include Linux with 'unix' above and include Lesstif with Motif.]
[Further note: back during the original "GUI toolkit wars" (Motif vs OpenLook) I originally favored OpenLook -- particularly if using the Xol API which kept you 99.9% code-compatible with Motif. But OL really is dead.]
Quite a few folks here seem to think that if the source is available somewhere, a redistributer of (unmodified) GPL'd binaries doesn't need to supply or make available the source themselves.
This just isn't so. Read section 3, it's very explicit about that. Only non-commercial redistributers (ie, if I burn a copy of a RedHat CD for a friend) of unmodified binaries are allowed to make the offer of source from a third party -- and then only if that redistributer received such a written offer in the first place.
If the CD I'm copying also came with a CD full of source, and no written offer that the source was on some ftp site (regardless of whether the source really is there or not), then I have to burn a copy of that source CD for my friend too (no written offer, no third-party responsibility).
In effect, the GPL only allows source distribution, with the option of including a precompiled binary as a convenience. (I know, that's not the wording, but that's the effect.)
Amen. I have no need of a card that runs Quake at even 30 frames/second -- I don't play Quake. (Let's see, last computer game I played was Myst, last multiplayer game was probably xtrek (no, not nettrek, but it's predecessor based on X10)). I had more fun hacking on the source code to 'adventure' than playing it...
But combining video capture, MPEG acceleration, etc onto a single card would certainly free up some slots in my computer. (Which is maxed out, what with sound, SCSI, NIC, FireWire, TV card, and VGA card). I've been considering buying the ATI All-In-Wonder card for just that reason when I put my next system together. (Just how well is that card - the AGP version - supported under Linux?).
Heck, how about putting the X server right on the card too?
He wasn't even close to being there at the beginning. The 'net (okay, darpanet back then) started life in 1969, the year Gore was graduating from college (with a degree in government). He didn't even run for Congress until 1976, by which time the net was far more than just "a couple researchers".
Slashdot Mirror
Only if you want the outside world to be able to talk to your lightbulbs and fridge!
:-)
Good point. Very few household devices would need to talk to the outside world. Although perhaps more than at first glance. Your fridge might want to talk to its manufacturer (or vice versa) for software updates or service calls if it detects a problem, for example. Your blender might want to conduct an email love affair with that cute toaster oven it sat next to on the store shelf. That sort of thing.
Meanwhile, how long before somebody builds a webcam into a light bulb?
The overall forecast for power-line-based home networks is now beyond the 32 million nodes initally projected.
Time for IPv6? Or do we just put every toaster, refrigerator and light bulb in the house on an unroutable domain and handle the translation in the router/firewall/proxy built into the fuse box?
More seriously, this ain't bad. Speed is comparable to 10base Ethernet, but I'll still run Cat 5 cable in my new house (faster, and for now cheaper, since I already have the NICs and hub). One nice thing about signal-over-AC is that you don't need a separate cable to the device -- the power cord is the network cable, very convenient for appliance-type devices.
Oh really? Can you tell me any other instance where people act contrary to their own self interests? I can't think of any.
:-)
You're joking, right?
Smoking.
Drinking (to excess).
Doing drugs (ditto).
Overeating.
Buying lottery tickets.
Using Windows
Replying to comments on Slashdot...
While he does raise a few good points, I think the manner in which he does so is more grandstanding than anything else. It actually distracts from the main message. Reminds me of the time at a Usenix about 15 years ago that he delivered a paper while dressed in a harem girl outfit.
Yes, in some ways Linux is playing "catch up" -- it has to, it didn't magically spring into existence fully formed. But in other ways (eg, look at some of the details of the kernel architecture) it is leading edge. At least with respect to real-world software, as opposed to academic exercises like Version 8 Unix or Plan 9.
As for MS innovation -- well, they've boldly copied the UI from such as Mac and NeXT, and they've boldly gone where no sane software designer has gone before -- dissolved the barrier between application and OS making such wonderful features as ILOVEYOU.vbs and a whole plague of viruses and BSODs possible. If that's innovation, I'll take playing catch-up, thanks.
Another expert heard from.
[GTK is] not as ugly as Motif,
By default they look pretty much the same.
ontop of things GTK is themeable,
So is OpenMotif now. There's (in dev, almost alpha) a patch, it even reads GTK themes. And the developers have proposed an additional API back to the GTK project to make extracting themes (and building theme editors) easier.
Quoting from the MotifZone discussion
They also plan to do something similar for Qt 2.0.
The open source guidelines specify that there has to be no discrimination against a particular area or endeavor of work
:-). The restriction is not on the specific platform, but on the license of the platform. In this sense it is no different than the GPL. (Read that carefully - I said "in this sense" -- obviously there are other senses in which it differs.)
Except (at least in the GPL case) against linking to "incompatibly licensed" code.
the [OpenMotif] license [...] only lets you use it on certain platforms.
Not quite. It'll let you use it on any platform so long as that platform is open source. If Windows (hah) or Solaris (maybe) were to open their source tomorrow, you could freely use OpenMotif on them (although that might not be helpful on Windows
this is restrictionware
And the GPL is not?
Both the GPL and the OpenMotif licenses place restrictions on the licensee. In both cases the effect is to encourage software to be free.
Personally, I like Motif. I've developed with it (and LessTif) for nearly a decade (on and off), it has mature GUI builders, a UIL, is Xt-based (so it cooperates with other Xt-based toolkits, unlike GTK and Qt), and there's already a patch (in alpha) to OpenMotif to make it themeable (using GTK themes). If it's so ugly, why do other toolkits copy its look? (Granted, the defaults are poorly chosen, but who uses the defaults?) And while I would like to see the OpenMotif license more open that it is, Stallman seems oblivious to the subtleties of the license. As I wrote elsewhere:
Motif is hardly dead -- too many existing projects out there use it and there's too big an expertise pool of existing Motif developers (on the proprietary Unix side) for that.
Heck, X10 (the version before X11, not the home automation system) had transparent windows.
Mind, I think the usage of the term is somewhat different. (IIRC, you couldn't draw anything on a transparent window, it was just useful for intercepting events. Gosh it's been a long time since I did X10 programming...)
"the energy cost of sending humans and their life-support supplies into space is still too high"
The energy cost is perhaps a couple of dollars a pound, at current energy (eg electricity) rates. Yes, it takes a fair bit of energy to get there, but that isn't the driving cost of the system. The fuel costs for a Shuttle launch are perhaps a few million dollars, out of the $500 million or more per launch actual cost.
The problem is (a) systems engineering (the Shuttle design goals seem to have been to ensure that every congressional district in the US has some involvement in it, a real kludge) and (b) the politics of coming up with something that threatens to break the rice bowls of Big Aerospace. (If you though Microsoft tactics were bad, you ain't seen nothing compared to what NASA and the big aerospace companies are willing to do to defend their monopoly and government handouts).
A lot of us that had/have the Grand Dream have seen it smashed over and over by the likes of NASA bureaucrats. It isn't the organization it was in the 1960s, at all. (As witness, for example, the recent string of brilliant Mars successes.)
Somewhat misleading. I don't know whether your BSD bias has crept into your comments, or whether your (apparent) ignorance on some of the fine points has caused the bias in the first place.
Either way, some clarification is in order.
GPL can never be used in a commercial product
So what are Red Hat, SuSE, and Caldera, to name but a few? Perhaps you meant "closed source" product, rather than "commercial". There is a difference.
GPL code can never be used in any application that is not also 100% GPL code
Not quite correct. It can be used in any non-GPL'd application that is not distributed. There's a lot of software development done entirely for in-house use. The GPL might technically apply to these if they use GPL'd source, but in practise it never applies if the application is never distributed to anyone else.
Finally, any mods made to GPL code must be made public - you must post the source, or provide it on request.
Same error as above. If I never post (or otherwise distribute) the binaries of mods I make to GPL'd code, I need never post the sources, either, and I can tell anybody asking for them to buzz off.
BSD can be used by anybody, for anything.
True. Some people, though, regard this as a serious flaw. Microsoft (among others) has made a lot of money off of BSD'd code, with no particular benefit to the rest of the developer community.
The proponents of GPL feel that imposing a non-commercial business model is the best way to keep software "free"
Cart before the horse. The GPL doesn't impose a non-commercial business model, although it does tend to (as a byproduct, via free market forces) enforce an upper limit on "what the market will bear" for the software.
Proponents of BSD feel it is the only "free" license, as it doesn't require you to become a non-profit to use the code
Neither does the GPL.
you can integrate it [BSD code] into proprietary [closed source] apps
This is certainly an advantage for those that want to take proprietary advantage of code somebody else has written. It's hard to see how this is an advantage to the authors of such code, unless they're happy just knowing that some of their code is buried in a Microsoft or Apple program somewhere, one that they can't even use unless they pay Microsoft or Apple for the privilege. Still, it seems that there are such folks out there.
Personally, I think that corporate subsidized BSD-type development WILL easily surpass GPL's contributions - as more and more corporations realize the value of releasing open source.
To date this doesn't seem to be the case. Most corporate developed software that has been open sourced has been released under some license that is far more restrictive than BSD.
Some corps release their work as GPL to prevent competitors from being able to benefit from it,
Not quite. The competitors may certainly benefit from it, since they may freely use it. However, the competitors won't benefit any more than the original authors, since they (competitors) can't incorporate the GPL'd source into their own closed product, or if they do incorporate the GPL'd code, they must then open up their own extensions such that the original company also has access. (Effectively levelling the playing field for all involved.)
Of course, there are problems using BSD code in GPL applications, as GPL demands that the code become GPL. In most of these cases, the BSD authors have allowed GPL forks of the code.
In most cases the BSD authors have no control over whether their code goes into GPL'd applications. So long as the BSD license doesn't place any restrictions on the code that the GPL doesn't (and in some cases where there's an advertising or author-acknowledgement clause, it might), the GPL "infects" any BSD-ish (or public domain, for that matter) code that gets rolled in to a GPL'd application. (Of course, the originalBSD or PD code is available outside the GPL). BSD authors shouldn't be particularly upset about this -- the license allows their code to be incorporated into totally closed and proprietary applications, too.
n the end, I think corporate subsidized BSD has to win. It actually has financial backing, so programmers can earn a paycheck for their work, instead of working as a waiter to subsidize your coding as one of the GPL authors recommended.
Hey, everyone should have a hobby. More seriously, whichcorporate subsidized BSD? Apple? Meanwhile, there are plenty of places (Red Hat, for example) paying programmers to write GPL'd code.
Competing implementations of an API is no bad thing. "Choice for the sake of choice" aside, in any software implementation there are going to be trade-offs, design decisions and compromises that will give the result different properties (memory footprint, speed, etc.) than if different decisions had been made.
Even if (when) Motif goes to a completely LGPL/X/whatever Open Source license, there may be situations where you'd rather use Lesstif because it fits your design tradeoffs better.
(Of course, one of the problems here is that while Lesstif and Motif may be fully compatible at the API level, they aren't necessarily "bug for bug" compatible. Since most (all?) commercial Motifs are derived from the same reference source, those are generally bug for bug compatible. (I'm talking about behaviour bugs - misimplementations of the spec, not things like memory leaks.))
I doubt you'll be able to link both into the same program at once, but I can't imagine why you'd want to. Certainly they can both live on the same machine at once, just set up different lib and include paths for them, with choices made at compile and link times.
I think this is neat. Even if the incompatible licenses mean that Lesstif can't use Motif code directly (of course, if Motif were LGPL'd there'd be no need for Lesstif at all), this makes reverse engineering Motif a whole heck of a lot easier, so Lesstif can become more completely compatible. (Meanwhile, the Lesstif project also has some addtional widget sets that help reproduce/improve-upon commercial Motif widget sets.)
This also encourages the porting of existing Unix apps that require real Motif (ie use features that aren't complete in Lesstif), so we'll see more (commercial) software for Linux and *BSD. And many of those in-house apps (I'm thinking of a couple in particular that I've been involved with, a million or so lines of code, Motif-based GUI, and requiring something like a Sun workstation on every user's desk) will port more cleanly to Linux without having to worry about buying Motif licenses. (Sure, the Motif license for Linux was cheaper than a Sun-Solaris box anyway, but the minds of pointy haired bosses work in mysterious ways.)
agreements that basically said the company owns any idea they think of while in employment of the company (in or outside of work).
Yep, such language is not uncommon in such NDA/IP ownership/etc agreements. A while back I was asked to sign such (along with the usual paperwork) as a condition of employment at [large long distance telco]. They faxed me the docs to sign and send back.
Now, they hadn't countersigned the docs, and I figure anything in a contract is open to negotiation, but rather than simply cross out the offending verbiage I retyped the document, printed it out in the same format using the same font, and signed and returned that. Not my fault if they didn't read it before accepting it.
Not that it ever came to a test, mind.
seems like I remember seeing multiple monitor setups udner X as early as '88.
We were running some multi-headed machines back in early 1987, but if I recall right X treated each of them as a different display (foo:0, foo:1 etc). This was under X10, not X11. Might have been with X11 that came the ability to treat them as two views onto a single virtual display.
If the above phrases are true (and frankly I'm a bit sceptical), then somebody is writing lousy software (or they're writing it in perl or something equally inappropriate for the task). This goes double if it's a driver for something that offers hardware acceleration for DVD playing, like the Hollywood card.
For comparison, under Windows (yeah, I know, but there's no Linux software) my puny little 233MHz Winchip (supports MMX and 3Dnow! but otherwise is essentially a 486 in drag - 156 bogomips) plays DVDs (using PowerDVD) at a viewable frame rate (it isn't 30 fps, probably more like 20) with no sound problems. All this with software decoding (the cheap VGA card doesn't add any support either).
There are Linux software solutions that require a couple of passes -- decrypting the VOBs and then playing them via eg mpeg2play -- if any driver for hardware decoding is worse than that, the only excuse is that it's a debugging version and must be writing a ton of stuff to a log file somewhere.
(Of course, current solutions are for strictly linear playback, you miss out on some of the extra features like branching or multiple camera angles.)
It may well be encrypted too, but the message (encrypted or not) is also hidden by steganography: the thing doesn't look like an encrypted message. Which was probably the point.
My guess is is that it's stego'd into the jpg image. Hmm, maybe not, that'd require a bit more than pen and notebook unless one was really a glutton for punishment. So it's likely in the text. But $25 isn't enough to persuade me to spend much more time on it.
Oh, that day is already here. JIT compiling VMs have been around for a while, and processor speeds are at least 4x if not 8x faster than they were when Java was introduced.
But remember Transmeta? Remember that their Crusoe chip, while currently targeted at the x86 market, was also demoed running Java byte code 'natively' (ie doing the code morph thing from Java bytecode to Crusoe internal instructions).
I like Java for apps because its cleaner and easier to debug than C++, and has a whopping great set of (cross platform!) APIs. And for many apps, the speed is already good enough. But I still use C for lower level stuff, and C or C++ if I need to tie in to an existing C library. (Why mess with JNI).
nd I wouldnt go on a plane where the pilot could get out and tamper with it.
Heck, I am a pilot and neither I nor any pilot I know would fly a plane that couldn't be opened up and inspected by the pilot. Now, I'm not likely to go fixing anything other than low fuel or oil, since I'm not an airframe/powerplant mechanic -- unless for some reason I've had to make a forced landing somewhere and it's the only way I have to get out.
(Not only that, but part of the pre-takeoff checklist is, effectively, to deliberately induce faults (magneto failure, fuel starvation) to ensure that the engine responds as expected.)
So what happens if (for some bizarre reason) Adobe decides to get out of the video editing business and drops all support for Premiere? This time you're stuck with proprietary file formats and not even the option of hiring somebody to continue to support the package, because it's closed source.
(And while Adobe might be an extreme example, I'm sure there are plenty of proprietary software vendors who have gone toes-up and left their customers in the lurch.)
Which is to say, the Motif API and functionality can be had for free via Lesstif. If you want the honest-to-god Motif reference implementation from X/Open, that costs.
/.) A lot of unix/Motif programmers are discovering Linux/Lesstif, and the skill set ports very nicely, but you raise good points in your second paragraph. I wouldn't say the nails are quite in the coffin, but the developer certainly has more choice now than in the days when the only real choice was Motif (given that the alternatives were a dying OpenLook or lame raw Xlib. I've worked on X GUIs back in the days before Motif (on X10), so we rolled our own inhouse menu languages and forms languages. Motif was a godsend.)
That said, your first pararaph is indisputable (at least, I won't dispute it. Anything is disputable here on
X Resources are a cheap cop-out for providing source, for real customisability
Not a cop-out at all. To take a personal example, when I rolled out a (in-house) app to a couple of hundred users, there's no way that 99% of them have the ability (skill) to customize source (let alone that management is going to let them do that), but they all (in theory, maybe half in practise) have the ability to make a few simple edits to an X resource file. (And many of them did.)
Could I have added user-customization as part of the program (ie preferences settings, etc)? Sure, if I'd been allowed to take twice the time to complete the project (a smart GUI front end to a legacy app for designing high speed copper telco circuits). That wasn't an option, getting the needed application functionality in there was the important thing, customizabilty via resources was just a bonus that came free with using Motif.
(BTW, the app had to run on a Pyramid, with folks using their Sparcstations as X terminals to this particular app. Has Qt or GTK been ported to the Pyramid yet?)
take a look at KDE2's XML GUI
That's a nice approach, and not necessarily restricted to any particular GUI toolkit. But I expect it will be a while before anyone planning a multi-hundred-thousand-(or million)-dollar enterprise project makes it a critical component. (Just as a ballpark, the above project from start to rollout was probably in the $300,000 range, including design, coding, QA, documentation, and trainging the users (not counting salary for the users while in training))
Motif is dead because nobody codes for it anymore
Nothing could be further from the truth. There are more lines of code written for Motif than for any other unix GUI out there, and that's probably still true. Sure, there's a lot of Qt and GTK showing up on Linux, but all (well most) the in-house custom apps written for traditional unix (AIX, Solaris, HP/UX, etc) are Motif.
When you're building enterprise applications that take years and dozens of programmers to design and implement (and I've worked on a few such in my time), you choose a GUI that (a) is reasonably mature (measured in feature stability for years, not months), (b) is well documented (the O'Reilly Motif books have been around forever. Docs for Qt or GTK is just starting to appear), (c) is understood by the majority of your unix programming staff, and (d) is well supported by mature third-party tools like GUI-builders, prototyping languages, etc, etc. To the extent that I've seen any move away from this, it hasn't been toward doing GTK or Qt on a unix desktop machine, but rather toward putting the GUI on NT workstation communicating with the main app logic on a unix server.
Motif is neither particularly hard to program (GUI builders aside, it's real easy to wrap C++ classes around) nor inherently ugly. I find Motif far easier than Qt or GTK to program for the simple reason that I've done a ton of the former and very little of the latter; I suspect the converse is true for those claiming that Motif is hard. And I've seen incredibly ugly interfaces built with every GUI toolkit out there -- some people just have no sense of aesthetics or interface design. But it's also possible to build some very good looking Motif interfaces (and there are a couple of good books on that subject.)
[NB, for brevity I include Linux with 'unix' above and include Lesstif with Motif.]
[Further note: back during the original "GUI toolkit wars" (Motif vs OpenLook) I originally favored OpenLook -- particularly if using the Xol API which kept you 99.9% code-compatible with Motif. But OL really is dead.]
Quite a few folks here seem to think that if the source is available somewhere, a redistributer of (unmodified) GPL'd binaries doesn't need to supply or make available the source themselves.
This just isn't so. Read section 3, it's very explicit about that. Only non-commercial redistributers (ie, if I burn a copy of a RedHat CD for a friend) of unmodified binaries are allowed to make the offer of source from a third party -- and then only if that redistributer received such a written offer in the first place.
If the CD I'm copying also came with a CD full of source, and no written offer that the source was on some ftp site (regardless of whether the source really is there or not), then I have to burn a copy of that source CD for my friend too (no written offer, no third-party responsibility).
In effect, the GPL only allows source distribution, with the option of including a precompiled binary as a convenience. (I know, that's not the wording, but that's the effect.)
Amen. I have no need of a card that runs Quake at even 30 frames/second -- I don't play Quake. (Let's see, last computer game I played was Myst, last multiplayer game was probably xtrek (no, not nettrek, but it's predecessor based on X10)). I had more fun hacking on the source code to 'adventure' than playing it...
But combining video capture, MPEG acceleration, etc onto a single card would certainly free up some slots in my computer. (Which is maxed out, what with sound, SCSI, NIC, FireWire, TV card, and VGA card). I've been considering buying the ATI All-In-Wonder card for just that reason when I put my next system together. (Just how well is that card - the AGP version - supported under Linux?).
Heck, how about putting the X server right on the card too?
He wasn't even close to being there at the beginning. The 'net (okay, darpanet back then) started life in 1969, the year Gore was graduating from college (with a degree in government). He didn't even run for Congress until 1976, by which time the net was far more than just "a couple researchers".