It's difficult to tell - until the GPLv3 is 100% finalized and Linus makes his final decision on this version, we won't really know. Everything's noise until then. The "or later" clause may not be attractive to Sun either, since later versions of the GPL could be written to disallow dual licensing. That probably wouldn't make SUN happy. Still, it's an interesting observation.
That's one possibility, but the other possibility is for code to go in both directions. Both Solaris and Linux could potentially use code from the other, assuming the Solaris code is not tainted in a manner that would preclude its inclusion in the Linux kernel and vice versa. I use both Solaris and Linux, amongst other UNIX and UNIX-like systems, and they each have good points that make them useful.
No kidding? I met the guy once at a friend's place on the east coast, apparently just after a trip to India regarding outsourcing back in the late 90s. We had an interesting conversation with him about how he felt outsourcing was the next big thing, and I guess he was spot on. (Now there's irony, seeing how the article blames outsourcing on his current conditions...)
Anyway, he wanted to try some apparent chiropractor-like thing he'd learned in India. I assume he meant Yoga, as I've since taken Yoga classes with my wife and it seems similar enough. After a minute or so the idea weirded me out, so it didn't go that far. I guess I'm glad it ended there despite his apparent disappointment.
Yes, thank you again for all the ammunition I'll ever need to avoid those two particular flavors. Linux, FreeBSD and Solaris should suffice for any purposes we'll have.
I do see that I misread your question re: BSD/Solaris apps that will not run under Linux. As for software that was written for BSDs or Solaris that has trouble running on Linux, that's the whole point I suppose. While there may be less of these packages, there tend to be enough volunteers who will work with the software's developers to ensure that it does work under Linux. Developers have more users to gain by supporting the Linux platform, assuming that's their goal. Compiling them is not always a picnic even under Linux, if you've ever built OpenInventor from scratch you'd see what I mean. Sometimes a bit of modification is required. Still, it's almost always possible. The GNU environment actually helps a lot in this regard, and the kernel interfaces tend to be kind to programs from other platforms. Kernel modules are a different story, but that's not end-user application software.
In the end, most software I build runs on the UNIX, FreeBSD and Linux/GNU UNIX-like systems we support. For that reason, I'll call it UNIX software. There's the occasional hiccup with IRIX and Tru64, regardless of where the code came from, but I have both compiled trivial and non-trivial software on all of them when needed. I'm happy to say that I don't need to support the OpenBSD platform in our environment, nor NetBSD for that matter, and won't support its inclusion in the future given the trouble you seem to be having.
Well, we're supposedly discussing the desktop. I'll pick a few from mine. How about KDE? A large number of KDE apps originated on Linux. XMMS definitely originated on Linux, and it works on OpenBSD. The mplayer program works on OpenBSD as well. It took a few minutes to come up with and verify that list. The list grows much larger when you include FreeBSD, since more people seem to use it.
Probably exactly as difficult as I think, I tried. Now you go try instead of pretending its so easy. You are insulting all the people who spent the time getting it working on FreeBSD with your ignorance.
Scarcely, FreeBSD has everything that WINE needs to run. When OpenBSD supports everything that WINE currently needs, it won't be as difficult so much as potentially time consuming given the size of the code. A cursory look into the issue shows that kernel level thread support is currently holding back the OpenBSD port, which isn't a WINE issue as much as an issue for OpenBSD threads. Older versions which did not require this support did run on OpenBSD. Once OpenBSD thread support is considered a stable target, and a WINE developer ports the thread code, OpenBSD should get a port again. WINE can be run on other BSD systems until then.
No, its linux software that dedicated FreeBSD fans have ported.
It's software that now has a FreeBSD port. Your insistence in calling it Linux software is where we disagree and will continue to do so. Unless it accesses a kernel specific resource, there's nothing Linux particular about it. There may be GNUisms, or code that leans toward SysV, but that's a different issue.
We're talking about open source projects remember? Seriously, every project I know developed primarily on a non-linux unix is tested and fixed for linux at least, and usually BSD and solaris as well. This doesn't occur very often going the other way.
For Free and Open Source software, sure it does. Successful projects which interest developers who prefer other platforms are developed for those platforms. That's how Open Source and Free software works. If it doesn't happen, the project was likely not all that successful or interesting for the developers who prefer those target systems. If there aren't very many people who prefer those systems, as seems to be the case with OpenBSD, then it may never be tested. It might work, might not.
You said its trivial to port software, I pointed out an example of how non-trivial it can be.
It works on FreeBSD, which is a BSD and not Linux. Tell me then, why is it so difficult to get it running on OpenBSD? Is WINE FreeBSD software as well? It's not because WINE is impossible to port; probably not even as difficult as you think. It's because most OpenBSD developers don't care enough to put forth the effort. Even Mac OS X/Darwin has a project to get WINE running. Unless someone's interested in paying a developer to manage the difference, or OpenBSD becomes enough like a supported platform (like FreeBSD) that it starts working, then the lack of interest will prevent it from being supported. This is not a failing of all other platforms, nor of the software.
Why do you persist in pretending I give a shit about porting any given piece of software? I have made it very clear several times now that I am simply correcting the false assertion that people don't develop for linux. They do.
I'm not pretending; I'm telling you you're complaining about fringe platforms being ignored that do not in themselves define UNIX. There are in fact ports available for systems that more people care about and use. Many people develop applications on Linux, and if this is all one would base a "Linux application" on then you would be correct. Unless it's using actual kernel functions to utilize a specific resource however, you're using the GNU C library and the functions that come with it. That's the GNU platform, not Linux. Yes, it differs from BSD in some ways. If you're saying that there are a lot of GNU applications that never get ported to your favorite platform, then that in all likelihood means no developers on your favorite platform were interested in assisting with the application's development. If it sees a lot of use and is worth the effort to port, it'll probably will work on FreeBSD at least. A reasonable number of people actively use it. This is not a failing of the GNU platform, nor an issue particular to Linux.
No, there is the C standard actually.
There was the K&R compiler and there have been several variants of ANSI C, but C itself is a rather minimal standard. C compilers have extended the standard simply because C by itself doesn't do that much. C was intended to be small, easy to optimize, and easily extensible. Some extended elements went in several directions on different platforms. The UNIX APIs that we use today are by no means all part of a standard C API, and these differences are typically where you'll find incompatibilities. Most programmers I know go with the current ANSI C standard as supported by their compiler and OS libraries.
No, I do not. Try to read what you are replying to.
You're complaining that a lot of software is written on Linux and somehow never gets ported to other platforms. Yes, there's a lot of software written on Linux. There are a lot of Linux users out there, and many tend to be developers. No, that doesn't mean it's all automagically Linux-only software. It just means that not enough people care to try it or modify it (when necessary) for the less-used platforms. It's the same catch-22 that Linux users complain about with Windows software really. Most developers
That's about low to average, for a house and the worst part is it's more expensive in San Francisco. There they have about $800k median prices. I've looked at houses close to where I live (Mountain View) that went for more than $1M, sometimes much more. It looks like housing prices in general are on the verge of taking a dip though, maybe even a big one. I might just pick up a place here if homes can make it down to what they were 7 years ago. At that time, $50k/year was considered the edge of poverty level for this area. I don't like to think what it might be now.
Right, they would be devloping for solaris. But people don't do that. People who develop primarily on Solaris or a BSD of their choice are almost always nice enough to test their software on other free OSs and make sure it works.
Most definitely not. The vast majority of code out there gets developed for one OS (particularly Win32 and embedded operating systems, but it happens enough in the *NIX world too) and runs there. It gets ported only if the need arises. I've seen a lot of software development where I work now and in previous jobs, and have contributed to open source projects myself (typically offering Linux development services to a project.) That's just how it goes in most cases. When Open Source/Free software supports more than one platform, it's typically because there are multiple developers with different requirements. Most open source applications are developed to scratch an itch, if someone else has their own itch they're welcome to scratch it. Often you'll see projects asking for assistance in testing/developing for other platforms. More people will complain rather than doing anything, but that's human nature.
Go get wine working on openbsd and tell me how easy that is.
Not to be rude, but really, why would most people care? It works on several other platforms, including FreeBSD which is common enough that I have an installation of it myself on my laptop and in VmWare. I even have a copy of Syllable, but not OpenBSD. If there are enough people who want WINE on OpenBSD then it'll get there, but it doesn't sound like there are. Remember that WINE is a large project, and needs a bit of support from those who use fringe platforms to ensure that it works there. Of course, most software packages are not a Win32 API implementation and ABI loader, and thus tend to be much smaller with fewer piles of code to check. An ABI loader in particular can be very system specific since it deals with loading CPU opcodes into an executive layer. Why don't you help them with the port, since you have expertise with so many UNIX systems and seem to want it to work? It's not going to happen without people who care.
It would be just as dumb to develop software for netbsd/arm only and not bother testing it out on other platforms. But that's not what people do.
I work with plenty of people developing for embedded systems, and I see a lot of software that is never ported to anything other than the target system. It's the real world, dumb as it may be. The software you write may be different, and that's great, but people work within their desire/resources and not everyone can/will test on every platform imaginable. Does your code run on Tru64 and IRIX? On all CPUs supported by Linux, or platforms without a flat addressing space? Do you do develop for the VMS or NT POSIX layer?
No need, I actually write unix software in C. I know there's alot of differences. And I test out my code on a wide variety of hardware and software platforms before making releases so that I don't let BSDisms creep into my software.
That's great, but as you already know you're in the minority if you feel the need to test on multiple platforms. Developers will write to their target platform, be it Linux, BSD, Solaris, AIX or whatever. There's nothing special about this, and it takes an interested contributor to fix it in the open source/Free software world. In the closed source world it takes money more than anything else. If your definition of UNIX software must include every variant, then there are few to no true UNIX developers left. Luckily, most large software projects have multiple developers and people who manage and keep alive code for various platforms.
As previously mentioned, WINE works on FreeBSD and PC-BSD. It works on Solaris, Windows, and is packaged for six Linux distributions. Why doesn't it work on OpenBSD as well, considering they actually package binaries for the aforementioned platforms? In all likelihood, it's because noone cares enough to do anything about
Not really. Not everything is dependent on one platform or another. By your logic, if people wrote software for Solaris then they were writing code not for UNIX but for Solaris only; In order to compile for SunOS 4.x, HPUX, AIX, IRIX, Tru64, Free/Net/OpenBSD, and other UNIX systems there would need to be changes made because each system is a bit different.
He's not wrong in stating that most code can be compiled on all systems, because it can with little effort. Some projects may not be as widely ported as others, and might need changes to work on your favorite OS/Kernel, but I've built software for many systems that weren't necessarily the original coder's targets and it's not that difficult. You're simply trying to pin Linux and GNU systems down as the only odd ones out there, whereas most systems have a variety of small differences.
The most differences for that matter are probably between the BSDs and SysV based systems. Take a look at the output of autoconf's "configure" on multiple UNIX flavors and you'll see what I mean; even SysV systems can have different numbers of arguments for various library functions.
Perhaps, but there is an Age of Empires game as well as a MechAssault game on the DS already. Halo may be unlikely, since it's a franchise whose marketing was closely coupled to the Xbox, but who knows what could happen in the future.
That does indeed back up your observation, but it doesn't invalidate the original poster's point. Linux software is very similar, and often identical, to what you are calling UNIX software. "Porting" is generally trivial when compared to ports between other, less similar systems.
Many UNIX systems are different in small ways, so there will typically be a few changes needed to make any given software package run on different systems. I've built software on Linux systems from kernel 1.2 to 2.6, SunOS 4.x, Solaris, IRIX, Tru64, SCO, FreeBSD, and a number of other UNIX variants. They each have their differences, but the basic concepts of X11 and the basic C libraries are very similar.
This doesn't change the fact that many people do in fact write linux software instead of unix software.
That's a result of the fact that there are in fact many more Linux users than users of the other *NIX systems. (OS X excepted of course, as it's less often used as an *NIX for various reasons.) It's like complaining that there's more Windows software than OS X, or Solaris software vs. AIX, and complaining alone won't get you anywhere.
In the case of Linux software however, you're a lot closer to a "port" (really portability patches) than a Winxx/OS X port. The X11 backend is the same, most of the C library is the same, and the differences typically aren't that difficult to work around. Differences exist in other forms of *NIX as well, remember that your favorite OS isn't the only one out there. The effort to perfect a software package for another *NIX/X11 platform is typically quite minimal when compared to systems with wildly different APIs, and that was really the point.
Just having returned from Japan, there also seemed to be more games outside of the virtual console. I could have picked up as many controllers as I wanted. Joshin Pit, Midori and Yodobashi camera all had them in stock. Out of the electronics stores I visited though, only Yodobashi-Umeda had the power supplies which is what I was after. I brought the US Wii along for my niece and nephews to try out, and of course the Japanese games wouldn't play on it so I could only look at the games that may never make it here.
Incidentally, and even more off topic, we were far luckier with the DS as it's region-free. The dictionary app was an excellent purchase for me, and my wife picked up an English TOEIC preparation program. DQM: Joker isn't bad either, if you like pokemon-style monster fighting/RPG games. I wonder if it'll ever come stateside; as it is, it's entertaining Japanese reading practice if nothing else.
At the risk of sounding like some sort of Sony fanboy, out of the lot none of the others really had the 3D capabilities of the PSX. The Saturn had a decent amount of power for those who could develop for it, and I did enjoy the games I had for it, but the PSX really outclassed the Saturn for 3D games with its geometry engine. I had Tomb Raider for the Saturn, seeing it on the PSX it was pretty obvious which system was the fish out of water in 3D games with large areas. The Sega CD and Duo were both interesting 16 bit era systems, I still have my Sega CD for that matter as it had some excellent RPG and very playable action games, but power-wise they both fared much worse than the 32 bit Saturn which was a 2D/audio monster.
If you're trying to mention the 3DO or CDi (never mind the Jaguar with its CD attachment) as competitors, you're selling the PSX laughably short. Neither system had the games to compete, the 3DO was probably at its best with the Putt Putt games and that's sad. The CDi didn't have even that much and when it came to marketing, it seemed to get caught up in the FMV craze that marred the Sega CD. It was "Interactive" all right. I still remember that cheesy commercial with the couple playing "Voyeur" and acting like they really cared. That system died the death it deserved.
Hopefully the Wii continues to fulfill its promise of bringing the 3rd dimension into game play instead of just the display. It really is about time for another real leap forward in gaming. I've been quite impressed so far by a few of the games I've played, but it's up to the developers to bring us more interesting ways to control the action.
FWIW, Red Steel calibrates your screen size by having you point at objects in the beginning. Integrating acceleration information with previously known absolute information is prone to error from what I've seen, even with significantly more expensive systems, but using just the relative information is a reasonable approximation when you're playing a game.
I have the wii console; it still amazes me that someone could break the strap that comes with the controller. It looks and feels just as strong as the one on my digital camera. I've never let go of the controller myself, nor has any one of the approximately two dozen people who have tried the system since I bought it. My wife did smack our television once while playing tennis, but she was just too close to the screen and neither the TV nor the controller sustained any real damage.
I'd be willing to bet that the people who broke the strap were angry at missing a shot or something similar, and actively tried to throw the controller in frustration. To that end, I don't care how foolproof you try to design something. Fools will still find a way to exceed design parameters. More interesting might be the fact that the controllers in the stories I've heard still function, despite being thrown at these sort of velocities.
NASA has plenty of corporate partners, including several large players in the aerospace industry. Lockheed Martin has a facility right next to Ames. The NASA/Google partnership is old news though, we were joking about GAmes (Google/Ames) maybe a year ago. This is just some guy setting up a website for publicity purposes, which is definitely not NASA-sponsored. There's no responsible official named at the bottom.
From my understanding, they're injecting Capsaicin. Now, I'm a bit of a pepper fan and have a fairly large collection of peppers and habanero-based hot sauces (Dave's Insanity series, various Blair's concoctions, Mad Dog series, Vicious Viper, Pure Cap etc). Capsaicin is not a newly discovered substance, is available from a renewable resource - I have a red savina plant myself, and it by no means needs to be that expensive to produce.
The highest priced food additive products are the most highly concentrated variants like Blair's Reserve series, but even they tend to go for around $100. You probably wouldn't want to inject that high a concentration in your body anyway. While the initial medical product containing the capsaicin might be expensive, I'd be willing to wager there are alternate approaches to introducing it (cue the jokes about suppositories) of equal efficacy that do not violate whatever patents they might come up with.
That depends on how much junk loads after they get into XP, assuming that's what they're running. I've seen recent XP systems take more than 5 minutes to load completely, counting all the little apps that load into the taskbar once you've logged in. Knoppix would have been ready to go with time to spare.
Personally, I bring out live CDs like knoppix once someone's system is dead. I use it to help recover their systems or their documents, opening their files with OpenOffice or a text editor when in doubt. More than a few have shown a lot of interest in Linux after seeing their systems or data brought back from the dead, and I'm happy to help if they're interested in an install.
Supposedly there will be, although it hasn't arrived yet. It's been a while since the last Star Wars movie came out, and Spaceballs 2 was supposed to be out a year later. Still, Spaceballs was a full movie whereas SiN Episodes was clearly sold as a vehicle for future content. Apples, oranges and all that.
Yup, this project spanned multiple years and quite a bit of effort went into ensuring a good lifespan for the cards. They weren't exactly brand name cards though, we just bought a lot of cheaper ones. The device was under development, so many things ended up changing from release to release. Some storage was also needed for data acquisition, which was certainly part of the issue.
I've seen this problem happen in practice, with a development embedded system that booted off two flash cards. It ended up lasting 6 to 8 months or so before we needed to put in another flash card (it used CF cards, one 32mb which took all required R/W operations and one 1GB which was RO) and we took images for when the CF cards died. There was no swap, no journaling, and temp files were moved to a ramdisk where possible, but some files needed to be modified during development and the CF cards didn't last. Actually, some files were not readable after the flash failure. Perhaps this was due to an inconsistent filesystem state.
I guess it remains to be seen; McDonald's and other restaurants do not need to be the only source for vegetable oil, they just happen to be a convenient source for people who want to test the waters. If biodiesel truly takes off, the current petroleum companies would no doubt find a way to make a profit. This would probably involve researching which plants provide the greatest amount of oil and then producing as much of them as possible.
Our infrastructure at this point is highly dependent on petroleum, and our supply chain has been honed by years of experience to produce as much fuel as possible from crude. I don't believe for an instant that we couldn't come up with significantly better and more productive methods of producing biodiesel if that's the direction industry starts taking.
Are you sure about that? Vegetable oil from fast food restaurants as you have observed is indeed a waste product. Even if you only count the vegetable oil coming out of fast food places, the oil did not take millions of years to form. As for the pollution, you may be generating gasses, but the resulting output is indeed cleaner than current petroleum based diesel.
If it becomes profitable to produce vegetable oil on a much larger scale, I guarantee you people will find ways of producing more with less. This would also give companies an incentive to clean up unused land that could be used for farming. We have a lot invested in getting the most out of petroleum, it's time we start doing the same with alternative fuels. Vegetable oil is a close analog that should be able to use similar techniques before we rely on more radical methods.
As long as you can make fuel without using petroleum, it's a step in the right direction. The important thing for the US at this point is to reduce our reliance on foreign oil. We know the supply is not unlimited, and each barrel of oil we import is money leaving our economy. More likely we'll see biodiesel combined with other alternatives working together to replace our current runaway usage of petroleum-based products, but we need to start somewhere. This is a good - and functionally proven - place to start.
Slashdot Mirror
It's difficult to tell - until the GPLv3 is 100% finalized and Linus makes his final decision on this version, we won't really know. Everything's noise until then. The "or later" clause may not be attractive to Sun either, since later versions of the GPL could be written to disallow dual licensing. That probably wouldn't make SUN happy. Still, it's an interesting observation.
That's one possibility, but the other possibility is for code to go in both directions. Both Solaris and Linux could potentially use code from the other, assuming the Solaris code is not tainted in a manner that would preclude its inclusion in the Linux kernel and vice versa. I use both Solaris and Linux, amongst other UNIX and UNIX-like systems, and they each have good points that make them useful.
No kidding? I met the guy once at a friend's place on the east coast, apparently just after a trip to India regarding outsourcing back in the late 90s. We had an interesting conversation with him about how he felt outsourcing was the next big thing, and I guess he was spot on. (Now there's irony, seeing how the article blames outsourcing on his current conditions...)
Anyway, he wanted to try some apparent chiropractor-like thing he'd learned in India. I assume he meant Yoga, as I've since taken Yoga classes with my wife and it seems similar enough. After a minute or so the idea weirded me out, so it didn't go that far. I guess I'm glad it ended there despite his apparent disappointment.
Yes, thank you again for all the ammunition I'll ever need to avoid those two particular flavors. Linux, FreeBSD and Solaris should suffice for any purposes we'll have.
I do see that I misread your question re: BSD/Solaris apps that will not run under Linux. As for software that was written for BSDs or Solaris that has trouble running on Linux, that's the whole point I suppose. While there may be less of these packages, there tend to be enough volunteers who will work with the software's developers to ensure that it does work under Linux. Developers have more users to gain by supporting the Linux platform, assuming that's their goal. Compiling them is not always a picnic even under Linux, if you've ever built OpenInventor from scratch you'd see what I mean. Sometimes a bit of modification is required. Still, it's almost always possible. The GNU environment actually helps a lot in this regard, and the kernel interfaces tend to be kind to programs from other platforms. Kernel modules are a different story, but that's not end-user application software.
In the end, most software I build runs on the UNIX, FreeBSD and Linux/GNU UNIX-like systems we support. For that reason, I'll call it UNIX software. There's the occasional hiccup with IRIX and Tru64, regardless of where the code came from, but I have both compiled trivial and non-trivial software on all of them when needed. I'm happy to say that I don't need to support the OpenBSD platform in our environment, nor NetBSD for that matter, and won't support its inclusion in the future given the trouble you seem to be having.
Name some examples then.
Well, we're supposedly discussing the desktop. I'll pick a few from mine. How about KDE? A large number of KDE apps originated on Linux. XMMS definitely originated on Linux, and it works on OpenBSD. The mplayer program works on OpenBSD as well. It took a few minutes to come up with and verify that list. The list grows much larger when you include FreeBSD, since more people seem to use it.
Probably exactly as difficult as I think, I tried. Now you go try instead of pretending its so easy. You are insulting all the people who spent the time getting it working on FreeBSD with your ignorance.
Scarcely, FreeBSD has everything that WINE needs to run. When OpenBSD supports everything that WINE currently needs, it won't be as difficult so much as potentially time consuming given the size of the code. A cursory look into the issue shows that kernel level thread support is currently holding back the OpenBSD port, which isn't a WINE issue as much as an issue for OpenBSD threads. Older versions which did not require this support did run on OpenBSD. Once OpenBSD thread support is considered a stable target, and a WINE developer ports the thread code, OpenBSD should get a port again. WINE can be run on other BSD systems until then.
No, its linux software that dedicated FreeBSD fans have ported.
It's software that now has a FreeBSD port. Your insistence in calling it Linux software is where we disagree and will continue to do so. Unless it accesses a kernel specific resource, there's nothing Linux particular about it. There may be GNUisms, or code that leans toward SysV, but that's a different issue.
PEOPLE WRITE SOFTWARE UNDER LINUX.
Fixed it for you, and now we're crystal clear.
We're talking about open source projects remember? Seriously, every project I know developed primarily on a non-linux unix is tested and fixed for linux at least, and usually BSD and solaris as well. This doesn't occur very often going the other way.
For Free and Open Source software, sure it does. Successful projects which interest developers who prefer other platforms are developed for those platforms. That's how Open Source and Free software works. If it doesn't happen, the project was likely not all that successful or interesting for the developers who prefer those target systems. If there aren't very many people who prefer those systems, as seems to be the case with OpenBSD, then it may never be tested. It might work, might not.
You said its trivial to port software, I pointed out an example of how non-trivial it can be.
It works on FreeBSD, which is a BSD and not Linux. Tell me then, why is it so difficult to get it running on OpenBSD? Is WINE FreeBSD software as well? It's not because WINE is impossible to port; probably not even as difficult as you think. It's because most OpenBSD developers don't care enough to put forth the effort. Even Mac OS X/Darwin has a project to get WINE running. Unless someone's interested in paying a developer to manage the difference, or OpenBSD becomes enough like a supported platform (like FreeBSD) that it starts working, then the lack of interest will prevent it from being supported. This is not a failing of all other platforms, nor of the software.
Why do you persist in pretending I give a shit about porting any given piece of software? I have made it very clear several times now that I am simply correcting the false assertion that people don't develop for linux. They do.
I'm not pretending; I'm telling you you're complaining about fringe platforms being ignored that do not in themselves define UNIX. There are in fact ports available for systems that more people care about and use. Many people develop applications on Linux, and if this is all one would base a "Linux application" on then you would be correct. Unless it's using actual kernel functions to utilize a specific resource however, you're using the GNU C library and the functions that come with it. That's the GNU platform, not Linux. Yes, it differs from BSD in some ways. If you're saying that there are a lot of GNU applications that never get ported to your favorite platform, then that in all likelihood means no developers on your favorite platform were interested in assisting with the application's development. If it sees a lot of use and is worth the effort to port, it'll probably will work on FreeBSD at least. A reasonable number of people actively use it. This is not a failing of the GNU platform, nor an issue particular to Linux.
No, there is the C standard actually.
There was the K&R compiler and there have been several variants of ANSI C, but C itself is a rather minimal standard. C compilers have extended the standard simply because C by itself doesn't do that much. C was intended to be small, easy to optimize, and easily extensible. Some extended elements went in several directions on different platforms. The UNIX APIs that we use today are by no means all part of a standard C API, and these differences are typically where you'll find incompatibilities. Most programmers I know go with the current ANSI C standard as supported by their compiler and OS libraries.
No, I do not. Try to read what you are replying to.
You're complaining that a lot of software is written on Linux and somehow never gets ported to other platforms. Yes, there's a lot of software written on Linux. There are a lot of Linux users out there, and many tend to be developers. No, that doesn't mean it's all automagically Linux-only software. It just means that not enough people care to try it or modify it (when necessary) for the less-used platforms. It's the same catch-22 that Linux users complain about with Windows software really. Most developers
That's about low to average, for a house and the worst part is it's more expensive in San Francisco. There they have about $800k median prices. I've looked at houses close to where I live (Mountain View) that went for more than $1M, sometimes much more. It looks like housing prices in general are on the verge of taking a dip though, maybe even a big one. I might just pick up a place here if homes can make it down to what they were 7 years ago. At that time, $50k/year was considered the edge of poverty level for this area. I don't like to think what it might be now.
Right, they would be devloping for solaris. But people don't do that. People who develop primarily on Solaris or a BSD of their choice are almost always nice enough to test their software on other free OSs and make sure it works.
Most definitely not. The vast majority of code out there gets developed for one OS (particularly Win32 and embedded operating systems, but it happens enough in the *NIX world too) and runs there. It gets ported only if the need arises. I've seen a lot of software development where I work now and in previous jobs, and have contributed to open source projects myself (typically offering Linux development services to a project.) That's just how it goes in most cases. When Open Source/Free software supports more than one platform, it's typically because there are multiple developers with different requirements. Most open source applications are developed to scratch an itch, if someone else has their own itch they're welcome to scratch it. Often you'll see projects asking for assistance in testing/developing for other platforms. More people will complain rather than doing anything, but that's human nature.
Go get wine working on openbsd and tell me how easy that is.
Not to be rude, but really, why would most people care? It works on several other platforms, including FreeBSD which is common enough that I have an installation of it myself on my laptop and in VmWare. I even have a copy of Syllable, but not OpenBSD. If there are enough people who want WINE on OpenBSD then it'll get there, but it doesn't sound like there are. Remember that WINE is a large project, and needs a bit of support from those who use fringe platforms to ensure that it works there. Of course, most software packages are not a Win32 API implementation and ABI loader, and thus tend to be much smaller with fewer piles of code to check. An ABI loader in particular can be very system specific since it deals with loading CPU opcodes into an executive layer. Why don't you help them with the port, since you have expertise with so many UNIX systems and seem to want it to work? It's not going to happen without people who care.
It would be just as dumb to develop software for netbsd/arm only and not bother testing it out on other platforms. But that's not what people do.
I work with plenty of people developing for embedded systems, and I see a lot of software that is never ported to anything other than the target system. It's the real world, dumb as it may be. The software you write may be different, and that's great, but people work within their desire/resources and not everyone can/will test on every platform imaginable. Does your code run on Tru64 and IRIX? On all CPUs supported by Linux, or platforms without a flat addressing space? Do you do develop for the VMS or NT POSIX layer?
No need, I actually write unix software in C. I know there's alot of differences. And I test out my code on a wide variety of hardware and software platforms before making releases so that I don't let BSDisms creep into my software.
That's great, but as you already know you're in the minority if you feel the need to test on multiple platforms. Developers will write to their target platform, be it Linux, BSD, Solaris, AIX or whatever. There's nothing special about this, and it takes an interested contributor to fix it in the open source/Free software world. In the closed source world it takes money more than anything else. If your definition of UNIX software must include every variant, then there are few to no true UNIX developers left. Luckily, most large software projects have multiple developers and people who manage and keep alive code for various platforms.
As previously mentioned, WINE works on FreeBSD and PC-BSD. It works on Solaris, Windows, and is packaged for six Linux distributions. Why doesn't it work on OpenBSD as well, considering they actually package binaries for the aforementioned platforms? In all likelihood, it's because noone cares enough to do anything about
Not really. Not everything is dependent on one platform or another. By your logic, if people wrote software for Solaris then they were writing code not for UNIX but for Solaris only; In order to compile for SunOS 4.x, HPUX, AIX, IRIX, Tru64, Free/Net/OpenBSD, and other UNIX systems there would need to be changes made because each system is a bit different.
He's not wrong in stating that most code can be compiled on all systems, because it can with little effort. Some projects may not be as widely ported as others, and might need changes to work on your favorite OS/Kernel, but I've built software for many systems that weren't necessarily the original coder's targets and it's not that difficult. You're simply trying to pin Linux and GNU systems down as the only odd ones out there, whereas most systems have a variety of small differences.
The most differences for that matter are probably between the BSDs and SysV based systems. Take a look at the output of autoconf's "configure" on multiple UNIX flavors and you'll see what I mean; even SysV systems can have different numbers of arguments for various library functions.
Perhaps, but there is an Age of Empires game as well as a MechAssault game on the DS already. Halo may be unlikely, since it's a franchise whose marketing was closely coupled to the Xbox, but who knows what could happen in the future.
That does indeed back up your observation, but it doesn't invalidate the original poster's point. Linux software is very similar, and often identical, to what you are calling UNIX software. "Porting" is generally trivial when compared to ports between other, less similar systems.
Many UNIX systems are different in small ways, so there will typically be a few changes needed to make any given software package run on different systems. I've built software on Linux systems from kernel 1.2 to 2.6, SunOS 4.x, Solaris, IRIX, Tru64, SCO, FreeBSD, and a number of other UNIX variants. They each have their differences, but the basic concepts of X11 and the basic C libraries are very similar.
This doesn't change the fact that many people do in fact write linux software instead of unix software.
That's a result of the fact that there are in fact many more Linux users than users of the other *NIX systems. (OS X excepted of course, as it's less often used as an *NIX for various reasons.) It's like complaining that there's more Windows software than OS X, or Solaris software vs. AIX, and complaining alone won't get you anywhere.
In the case of Linux software however, you're a lot closer to a "port" (really portability patches) than a Winxx/OS X port. The X11 backend is the same, most of the C library is the same, and the differences typically aren't that difficult to work around. Differences exist in other forms of *NIX as well, remember that your favorite OS isn't the only one out there. The effort to perfect a software package for another *NIX/X11 platform is typically quite minimal when compared to systems with wildly different APIs, and that was really the point.
Just having returned from Japan, there also seemed to be more games outside of the virtual console. I could have picked up as many controllers as I wanted. Joshin Pit, Midori and Yodobashi camera all had them in stock. Out of the electronics stores I visited though, only Yodobashi-Umeda had the power supplies which is what I was after. I brought the US Wii along for my niece and nephews to try out, and of course the Japanese games wouldn't play on it so I could only look at the games that may never make it here.
Incidentally, and even more off topic, we were far luckier with the DS as it's region-free. The dictionary app was an excellent purchase for me, and my wife picked up an English TOEIC preparation program. DQM: Joker isn't bad either, if you like pokemon-style monster fighting/RPG games. I wonder if it'll ever come stateside; as it is, it's entertaining Japanese reading practice if nothing else.
At the risk of sounding like some sort of Sony fanboy, out of the lot none of the others really had the 3D capabilities of the PSX. The Saturn had a decent amount of power for those who could develop for it, and I did enjoy the games I had for it, but the PSX really outclassed the Saturn for 3D games with its geometry engine. I had Tomb Raider for the Saturn, seeing it on the PSX it was pretty obvious which system was the fish out of water in 3D games with large areas. The Sega CD and Duo were both interesting 16 bit era systems, I still have my Sega CD for that matter as it had some excellent RPG and very playable action games, but power-wise they both fared much worse than the 32 bit Saturn which was a 2D/audio monster.
If you're trying to mention the 3DO or CDi (never mind the Jaguar with its CD attachment) as competitors, you're selling the PSX laughably short. Neither system had the games to compete, the 3DO was probably at its best with the Putt Putt games and that's sad. The CDi didn't have even that much and when it came to marketing, it seemed to get caught up in the FMV craze that marred the Sega CD. It was "Interactive" all right. I still remember that cheesy commercial with the couple playing "Voyeur" and acting like they really cared. That system died the death it deserved.
Hopefully the Wii continues to fulfill its promise of bringing the 3rd dimension into game play instead of just the display. It really is about time for another real leap forward in gaming. I've been quite impressed so far by a few of the games I've played, but it's up to the developers to bring us more interesting ways to control the action.
FWIW, Red Steel calibrates your screen size by having you point at objects in the beginning. Integrating acceleration information with previously known absolute information is prone to error from what I've seen, even with significantly more expensive systems, but using just the relative information is a reasonable approximation when you're playing a game.
I have the wii console; it still amazes me that someone could break the strap that comes with the controller. It looks and feels just as strong as the one on my digital camera. I've never let go of the controller myself, nor has any one of the approximately two dozen people who have tried the system since I bought it. My wife did smack our television once while playing tennis, but she was just too close to the screen and neither the TV nor the controller sustained any real damage.
I'd be willing to bet that the people who broke the strap were angry at missing a shot or something similar, and actively tried to throw the controller in frustration. To that end, I don't care how foolproof you try to design something. Fools will still find a way to exceed design parameters. More interesting might be the fact that the controllers in the stories I've heard still function, despite being thrown at these sort of velocities.
NASA has plenty of corporate partners, including several large players in the aerospace industry. Lockheed Martin has a facility right next to Ames. The NASA/Google partnership is old news though, we were joking about GAmes (Google/Ames) maybe a year ago. This is just some guy setting up a website for publicity purposes, which is definitely not NASA-sponsored. There's no responsible official named at the bottom.
From my understanding, they're injecting Capsaicin. Now, I'm a bit of a pepper fan and have a fairly large collection of peppers and habanero-based hot sauces (Dave's Insanity series, various Blair's concoctions, Mad Dog series, Vicious Viper, Pure Cap etc). Capsaicin is not a newly discovered substance, is available from a renewable resource - I have a red savina plant myself, and it by no means needs to be that expensive to produce.
The highest priced food additive products are the most highly concentrated variants like Blair's Reserve series, but even they tend to go for around $100. You probably wouldn't want to inject that high a concentration in your body anyway. While the initial medical product containing the capsaicin might be expensive, I'd be willing to wager there are alternate approaches to introducing it (cue the jokes about suppositories) of equal efficacy that do not violate whatever patents they might come up with.
That depends on how much junk loads after they get into XP, assuming that's what they're running. I've seen recent XP systems take more than 5 minutes to load completely, counting all the little apps that load into the taskbar once you've logged in. Knoppix would have been ready to go with time to spare.
Personally, I bring out live CDs like knoppix once someone's system is dead. I use it to help recover their systems or their documents, opening their files with OpenOffice or a text editor when in doubt. More than a few have shown a lot of interest in Linux after seeing their systems or data brought back from the dead, and I'm happy to help if they're interested in an install.
Supposedly there will be, although it hasn't arrived yet. It's been a while since the last Star Wars movie came out, and Spaceballs 2 was supposed to be out a year later. Still, Spaceballs was a full movie whereas SiN Episodes was clearly sold as a vehicle for future content. Apples, oranges and all that.
Yup, this project spanned multiple years and quite a bit of effort went into ensuring a good lifespan for the cards. They weren't exactly brand name cards though, we just bought a lot of cheaper ones. The device was under development, so many things ended up changing from release to release. Some storage was also needed for data acquisition, which was certainly part of the issue.
I've seen this problem happen in practice, with a development embedded system that booted off two flash cards. It ended up lasting 6 to 8 months or so before we needed to put in another flash card (it used CF cards, one 32mb which took all required R/W operations and one 1GB which was RO) and we took images for when the CF cards died. There was no swap, no journaling, and temp files were moved to a ramdisk where possible, but some files needed to be modified during development and the CF cards didn't last. Actually, some files were not readable after the flash failure. Perhaps this was due to an inconsistent filesystem state.
I guess it remains to be seen; McDonald's and other restaurants do not need to be the only source for vegetable oil, they just happen to be a convenient source for people who want to test the waters. If biodiesel truly takes off, the current petroleum companies would no doubt find a way to make a profit. This would probably involve researching which plants provide the greatest amount of oil and then producing as much of them as possible.
Our infrastructure at this point is highly dependent on petroleum, and our supply chain has been honed by years of experience to produce as much fuel as possible from crude. I don't believe for an instant that we couldn't come up with significantly better and more productive methods of producing biodiesel if that's the direction industry starts taking.
Are you sure about that? Vegetable oil from fast food restaurants as you have observed is indeed a waste product. Even if you only count the vegetable oil coming out of fast food places, the oil did not take millions of years to form. As for the pollution, you may be generating gasses, but the resulting output is indeed cleaner than current petroleum based diesel.
If it becomes profitable to produce vegetable oil on a much larger scale, I guarantee you people will find ways of producing more with less. This would also give companies an incentive to clean up unused land that could be used for farming. We have a lot invested in getting the most out of petroleum, it's time we start doing the same with alternative fuels. Vegetable oil is a close analog that should be able to use similar techniques before we rely on more radical methods.
As long as you can make fuel without using petroleum, it's a step in the right direction. The important thing for the US at this point is to reduce our reliance on foreign oil. We know the supply is not unlimited, and each barrel of oil we import is money leaving our economy. More likely we'll see biodiesel combined with other alternatives working together to replace our current runaway usage of petroleum-based products, but we need to start somewhere. This is a good - and functionally proven - place to start.