Well, it's the old portability vs performance tradeoff.
Sure, a native driver tuned to the OS is going to give you the best performance. But a portable (eg UDI) driver is going to give you better performance than no driver, which is what you'll have if the hardware vendor hasn't chosen to support your particular platform.
Sure, I'd rather have native Linux drivers for the various gadgets I own. But some of those gadgets only ever came with Windows drivers -- I'll take a UDI driver over the no-driver-at-all that I currently have for those.
This company designs and manufactures its own video capture and compression cards, and also remarkets some third-party cards. All supported under Linux (with a name like that, what else?) and they GPL the drivers.
You seem to have a different definition of "top end".
I've seen a ton of top end stuff for which only NT (or W2K) support exists or will exist. Examples: high-end (broadcast quality) video capture/output cards from the likes of DPS or Matrox, hardware RAID cards, high-end audio cards, etc, etc. Perhaps this is "super high end" to you since these cards are typically a couple thousand dollars each. Certainly I wouldn't by them new for a Linux box (no support), but when I have a roomful of boxes with DPS Perception composite video cards that I can't migrate to Linux, it's a bit frustrating.
That's what you get for trying to run an input device on a printer port.
My UMAX Astra 600S -- the SCSI port version -- works just fine under Linux, never had a problem with it. (I don't use the cheap scanner-only SCSI card that came with it though, it's on a cheap AHA1540-clone card instead.)
Edmund Scientific sells a ton of this kind of stuff. Their stereo microscope page lists stuff ranging from about $150 to $1000. Take your choice.
I recall long hours of drooling over everything in the Edmund catalog when I was a kid. Heck, their catalog (and web site) is still worth some time drooling over. So many toys, so little money, sigh...
It just happens that I spent Friday afternoon finally getting my QX3 (I've had for about a year, picked up for about $50 at a supermarket (!) in an after-Xmas sale last year) running on my Linux box.
I'm using a mostly stock SuSE 7.3 distro with the 2.4.10 kernel, the camera built into the QX3 is the same CPiA chipset that many other webcams use. I haven't done the necessary tweaking run the lamps, I just an external light. The "gqcam" program works fine for viewing/grabbing the images.
Actually if I recall correctly, there was actually a proposal to have the cops ticket people going the speed limit in the left lane if the flow of traffic overall was at a higher (and technically illegal) speed. That suggestion was shot down, but did get some popular support.
The information might be useful for analyzing the survivability of some crashes and using that information in later design, but as far as establishing cause or liability, it is less useful.
Oh sure, the speed and braking info helps some, but without some sort of record of the external environment, you don't get the whole picture. Consider a collision resulting from somebody running a red light -- with no reliable third party witnesses. Data would likely show both vehicles at normal speed -- which driver didn't see the light?
Or a multi-car pileup in sudden white-out conditions -- which happened to me on an otherwise clear, sunny day when a sudden gust of wind blew snow from a field beside the road across the highway, reducing visibility instantly to zero (and unfortunately, somebody decided to slow down at a rate faster than those behind him). By the time the cops showed up, it was a clear, sunny day again.
Or driving at or below the legal limit, but "too fast for conditions" (fog, slick roads, etc) where the conditions are transient (as the above scenario).
Why not just mandate installing video cameras looking over the driver's shoulder?
Around here if you're only doing 65 you're likely to get ticketed for impeding traffic.
Well, not quite, but the legal limit is 75 on the interstates here (Colorado) outside the city. And there was some discussion about getting tough with drivers who drive under the limit in the left lane.
I'd like to see an emulator for that (or similar "classic" Burroughs Large Systems). 48-bit word, tagged words, HLL stack architecture, etc.
Apparently Unisys does actually have an emulator for the B6700's successor "A-series" machines, but it's proprietary (and maybe for internal use only).
Actually that wasn't that hard, because the PDP-11 had a ROM sequence you could toggle the address of. Compare that with the PDP-8, where you did have to toggle in the whole boot loader (at least enough code to read a binary image from the card or paper tape reader).
It's a bit of work to install (the process is reasonably well documented online, but it probably helps if you've had actual hands-on experience operating an S/360), but it works. And there are goodies like compilers for COBOL, FORTRAN, ALGOL and PL/I thrown in, just to round out that retro experience. (My dual 550 MHz P-III emulates a 370/158 faster than the original hardware, as far as CPU goes. Probably slower on I/O).
The ripoff^h^h^h^h^h^hborrowing is obvious to anyone who has read any science fiction. Two of the movies feature sandworms -- the skeleton of a wormlike (or snakelike, worms being inverterbrates) creature in Ep IV, and the mouth at the bottom of the pit thing in Ep VI. Borrowed from that other (and earlier) classic desert planet, Arrakis (Dune).
It wouldn't be hard to find classic SF precedents for everything in Star Wars -- the difficulty might be in arguing which precedent.
But so what? Robert Heinlein admitted to swiping many story ideas from classic literature, "you just file off the serial numbers". (He also said that there are only four or five basic story ideas, the rest is detail.) The Star Wars movies are fun if you don't take them seriously, and thats worth a few entertainment dollars.
Joseph Campbell is a scholar of mythology and heroic fiction, and has published a number of books on the subject. His main point (and here I distill overmuch) is that there are certain classic heroic/mythic themes that ring a chord across all cultures.
You are correct that John W. Campbell was the editor of Astounding and Analog in its heyday, and did much to further the careers of the likes of Isaac Asimov, Gordon Dickson, Frank Herbert and numerous others. But the reference to Joseph Campbell was correct.
Assuming the underlying technology even is patented, they granted a license to implement the BSD version. The GPL'd version is simply a derived work of that (allowed under the BSD license, and since the MSFT license permits BSD licensing, also allowed). The catch is that the new code wrapping the BSD part is GPLd, but there's no (easy) way of disentangling the two.
If Microsft does come after you, just show them the BSD version.
The Microsoft license doesn't prohibit BSD-like licenses (MS loves swiping BSD code). So, developer A uses the specs to implement a bare-bones BSD version, and releases that code only to developer B. Developer B then makes a derivative work of that, fleshing out the details, making it much more useful, etc, and releases that version under the GPL. (Nothing in the BSD prevents this.)
Now, of course, anyone is free to use the original BSD'd code in a non-GPL manner -- if they can figure out which code that is! Since the original BSD version was never publicly released, they have no way of doing that, so they have to use the GPLd version.
Interestingly enough, the GPL itself doesn't require any of those things. The key phrase is "requires in any instance that other software distributed with software subject to such license". The GPL specifically excludes aggregation. That is, I'm free to distribute my non-GPL'd software on the same disk as GPL'd software.
Of course, the MS license specifically excludes by name the GNU GPL and LGPL, but it seems to me you could write your own version of the GPL, call it "Fred's GPL" (or whatever), and license under that. (Note that making a derivative work of GPL'd software is an entirely different thing than merely distributing software with (along side of) GPL'd software.)
(And if necessary, I'm sure you could get FSF's permission to make a "derivative work" of the GNU GPL in order to create Fred's GPL for this purpose.)
Well, duh, ever hear of the Little Ice Age? Circa 1400 to 1800, give or take a half century. Prior to that (about 1000 to 1300), temperatures were warmer than they are today. In England farmers raised wine grapes, the Norse had dairy farms in Greenland.
Climate change happens. Ten thousand years ago a good part of North America (and Europe) was under a mile of ice. I suppose humans take the blame for melting that?
This is great stuff, and sprayable solar panels will go a long way where the silicon haven't.
But there are some applications where it just won't be that useful. The energy density of full sunlight is just a bit over one kilowatt per square meter -- and that's the sunlight intensity, multiply it by the conversion efficiency to get the electrical power, then add in cloud filtering, nighttime, and sun angles at other than local noon in the tropics.
It might run your air conditioner in the summer if you have a roof covered with the stuff, but it isn't going to become the sole source of power for electric highway vehicles. (Look at the designs of the solar race cars.)
...Or that IBM and Apple partnered on development of a new, object oriented OS (based on "Pink" a possible successor to MacOS) to run on a variety of chips.
MFC is a godawful class library. If you need to code crossplatform for win32 and linux, you're far better off switching to something sane like Java or using a class library like Qt.
Slashdot Mirror
Well, it's the old portability vs performance tradeoff.
Sure, a native driver tuned to the OS is going to give you the best performance. But a portable (eg UDI) driver is going to give you better performance than no driver, which is what you'll have if the hardware vendor hasn't chosen to support your particular platform.
Sure, I'd rather have native Linux drivers for the various gadgets I own. But some of those gadgets only ever came with Windows drivers -- I'll take a UDI driver over the no-driver-at-all that I currently have for those.
This company designs and manufactures its own video capture and compression cards, and also remarkets some third-party cards. All supported under Linux (with a name like that, what else?) and they GPL the drivers.
Pretty cool.
You seem to have a different definition of "top end".
I've seen a ton of top end stuff for which only NT (or W2K) support exists or will exist. Examples: high-end (broadcast quality) video capture/output cards from the likes of DPS or Matrox, hardware RAID cards, high-end audio cards, etc, etc. Perhaps this is "super high end" to you since these cards are typically a couple thousand dollars each. Certainly I wouldn't by them new for a Linux box (no support), but when I have a roomful of boxes with DPS Perception composite video cards that I can't migrate to Linux, it's a bit frustrating.
That's what you get for trying to run an input device on a printer port.
My UMAX Astra 600S -- the SCSI port version -- works just fine under Linux, never had a problem with it. (I don't use the cheap scanner-only SCSI card that came with it though, it's on a cheap AHA1540-clone card instead.)
Edmund Scientific sells a ton of this kind of stuff. Their stereo microscope page lists stuff ranging from about $150 to $1000. Take your choice.
I recall long hours of drooling over everything in the Edmund catalog when I was a kid. Heck, their catalog (and web site) is still worth some time drooling over. So many toys, so little money, sigh...
It just happens that I spent Friday afternoon finally getting my QX3 (I've had for about a year, picked up for about $50 at a supermarket (!) in an after-Xmas sale last year) running on my Linux box.
I'm using a mostly stock SuSE 7.3 distro with the 2.4.10 kernel, the camera built into the QX3 is the same CPiA chipset that many other webcams use. I haven't done the necessary tweaking run the lamps, I just an external light. The "gqcam" program works fine for viewing/grabbing the images.
No argument from me about that.
Actually if I recall correctly, there was actually a proposal to have the cops ticket people going the speed limit in the left lane if the flow of traffic overall was at a higher (and technically illegal) speed. That suggestion was shot down, but did get some popular support.
The information might be useful for analyzing the survivability of some crashes and using that information in later design, but as far as establishing cause or liability, it is less useful.
Oh sure, the speed and braking info helps some, but without some sort of record of the external environment, you don't get the whole picture. Consider a collision resulting from somebody running a red light -- with no reliable third party witnesses. Data would likely show both vehicles at normal speed -- which driver didn't see the light?
Or a multi-car pileup in sudden white-out conditions -- which happened to me on an otherwise clear, sunny day when a sudden gust of wind blew snow from a field beside the road across the highway, reducing visibility instantly to zero (and unfortunately, somebody decided to slow down at a rate faster than those behind him). By the time the cops showed up, it was a clear, sunny day again.
Or driving at or below the legal limit, but "too fast for conditions" (fog, slick roads, etc) where the conditions are transient (as the above scenario).
Why not just mandate installing video cameras looking over the driver's shoulder?
Around here if you're only doing 65 you're likely to get ticketed for impeding traffic.
Well, not quite, but the legal limit is 75 on the interstates here (Colorado) outside the city. And there was some discussion about getting tough with drivers who drive under the limit in the left lane.
Like just a few days ago?
I'd like to see an emulator for that (or similar "classic" Burroughs Large Systems). 48-bit word, tagged words, HLL stack architecture, etc.
Apparently Unisys does actually have an emulator for the B6700's successor "A-series" machines, but it's proprietary (and maybe for internal use only).
Actually that wasn't that hard, because the PDP-11 had a ROM sequence you could toggle the address of. Compare that with the PDP-8, where you did have to toggle in the whole boot loader (at least enough code to read a binary image from the card or paper tape reader).
now all you need is the OS
g z
IBM placed the original OS/360 into the public domain a while back. You can get a CD image of it from http://www.cyberdynesys.com/os360.tgz or ftp://ftp.ox.ac.uk/pub/linux/hercos360/os360.tar.
It's a bit of work to install (the process is reasonably well documented online, but it probably helps if you've had actual hands-on experience operating an S/360), but it works. And there are goodies like compilers for COBOL, FORTRAN, ALGOL and PL/I thrown in, just to round out that retro experience. (My dual 550 MHz P-III emulates a 370/158 faster than the original hardware, as far as CPU goes. Probably slower on I/O).
The ripoff^h^h^h^h^h^hborrowing is obvious to anyone who has read any science fiction. Two of the movies feature sandworms -- the skeleton of a wormlike (or snakelike, worms being inverterbrates) creature in Ep IV, and the mouth at the bottom of the pit thing in Ep VI. Borrowed from that other (and earlier) classic desert planet, Arrakis (Dune).
It wouldn't be hard to find classic SF precedents for everything in Star Wars -- the difficulty might be in arguing which precedent.
But so what? Robert Heinlein admitted to swiping many story ideas from classic literature, "you just file off the serial numbers". (He also said that there are only four or five basic story ideas, the rest is detail.) The Star Wars movies are fun if you don't take them seriously, and thats worth a few entertainment dollars.
Joseph Campbell is a scholar of mythology and heroic fiction, and has published a number of books on the subject. His main point (and here I distill overmuch) is that there are certain classic heroic/mythic themes that ring a chord across all cultures.
You are correct that John W. Campbell was the editor of Astounding and Analog in its heyday, and did much to further the careers of the likes of Isaac Asimov, Gordon Dickson, Frank Herbert and numerous others. But the reference to Joseph Campbell was correct.
Nope.
Assuming the underlying technology even is patented, they granted a license to implement the BSD version. The GPL'd version is simply a derived work of that (allowed under the BSD license, and since the MSFT license permits BSD licensing, also allowed). The catch is that the new code wrapping the BSD part is GPLd, but there's no (easy) way of disentangling the two.
If Microsft does come after you, just show them the BSD version.
ROTFL! I see some poor moderator got sucked into ranking all that bafflegab as "informative".
Funny, maybe. But about as informative as trying to learn physics from Star Trek.
There's an easy bypass to such nonsense.
The Microsoft license doesn't prohibit BSD-like licenses (MS loves swiping BSD code). So, developer A uses the specs to implement a bare-bones BSD version, and releases that code only to developer B. Developer B then makes a derivative work of that, fleshing out the details, making it much more useful, etc, and releases that version under the GPL. (Nothing in the BSD prevents this.)
Now, of course, anyone is free to use the original BSD'd code in a non-GPL manner -- if they can figure out which code that is! Since the original BSD version was never publicly released, they have no way of doing that, so they have to use the GPLd version.
(Usual IANAL disclaimer applies, though.)
Interestingly enough, the GPL itself doesn't require any of those things. The key phrase is "requires in any instance that other software distributed with software subject to such license". The GPL specifically excludes aggregation. That is, I'm free to distribute my non-GPL'd software on the same disk as GPL'd software.
Of course, the MS license specifically excludes by name the GNU GPL and LGPL, but it seems to me you could write your own version of the GPL, call it "Fred's GPL" (or whatever), and license under that. (Note that making a derivative work of GPL'd software is an entirely different thing than merely distributing software with (along side of) GPL'd software.)
(And if necessary, I'm sure you could get FSF's permission to make a "derivative work" of the GNU GPL in order to create Fred's GPL for this purpose.)
higher than they were in 1500
Well, duh, ever hear of the Little Ice Age? Circa 1400 to 1800, give or take a half century. Prior to that (about 1000 to 1300), temperatures were warmer than they are today. In England farmers raised wine grapes, the Norse had dairy farms in Greenland.
Climate change happens. Ten thousand years ago a good part of North America (and Europe) was under a mile of ice. I suppose humans take the blame for melting that?
Get a grip.
This is great stuff, and sprayable solar panels will go a long way where the silicon haven't.
But there are some applications where it just won't be that useful. The energy density of full sunlight is just a bit over one kilowatt per square meter -- and that's the sunlight intensity, multiply it by the conversion efficiency to get the electrical power, then add in cloud filtering, nighttime, and sun angles at other than local noon in the tropics.
It might run your air conditioner in the summer if you have a roof covered with the stuff, but it isn't going to become the sole source of power for electric highway vehicles. (Look at the designs of the solar race cars.)
But it's still cool.
I just want my ISP to provide a (reliable, fast) connection to the internet. End of story.
Fortunately that's what my ISP provides. (Oh, yeah, they offer an email account, but I prefer to run my own domain.)
Any software or service an ISP offers beyond that is costing somebody money. Guess who.
...Or that IBM and Apple partnered on development of a new, object oriented OS (based on "Pink" a possible successor to MacOS) to run on a variety of chips.
(Anyone remember Taligent?)
Gah, now there's a revolting thought.
MFC is a godawful class library. If you need to code crossplatform for win32 and linux, you're far better off switching to something sane like Java or using a class library like Qt.
Nope. I just checked the EULA that came with Office 97 (eula8). Nothing at all about which OS you run it on.
Hardly surprising, since back then they couldn't have imagined that any OS but some flavor of Microsoft Windows would install or run it.
The EULA in later versions may vary, I haven't looked.