I don't think they would have "had no problems" in another 2 or 3 years, they would have had the exact same problems they had now. What makes you think that the market 2-3 years from now would be more favorable? No one wants to wait 6-12 months just to pay more for a linux version that will probably break when the next major release of a distribution is released when a version for Windows is 1/5 the price in the bargain bin and will continue to run for several years given MSs backward compatiblity track record.
I bough Civ:CTP and Q3A from Loki because I wanted to see them do well, but the truth is the target market is not that huge to begin with and is also not so big on games. The ones that are big on games get their fix in Windows because Loki was too slow, the sad reality. Another reality we face is that Linux development in general is geared to open source projects, where breaking binary compatibilty frequently is at least somewhat acceptable, and API compatibility isn't much longer lived. Now with Loki gone, all those customers won't be able to upgrade too much in the future and continue to have the games they bought run correctly. For the most part, duplicate libraries can be maintained, but with a different libc major things would probably break.
Linux gets very nice ABI/APIs this way, but sacrifices the ability to play nice with binary-only products, and makes maintaining and updating a product much more expensive to companies, since they have to provide so many builds and modify source to keep current.
Oh, linking to c code from c++ is always easy (as is the case with SDL, from personal experience). Now using a C++ library from a C program.... That is tricky... You either have to make some really strange looking function call or have a thin C++ compiled wrapper to get the symbol names to something a C program can begin to understand...
Re:Glad the source is gonna be hosted
on
Last Word on Loki
·
· Score: 2
Of course, if you want to do any more stuff with VCD and smpeg, PythonTheater/Xtheater is pretty easy to read and implements seekable VCD playback (http://xtheater.sourceforge.net/). Its code may be helpful in any enhancements to your app you might want to make. And if you run ROX, PythonTheater is AppDir based, so it's even cooler:)
They should have renamed the executable to quack3.exe before benchmarking:)
Kidding aside, it's cool to see Radeon 8500 definitively beat out the more expensive competitor in a next gen game, but of course, as anandtech points out, there was a bug with fog in the ATI driver which may have helped performance as a side effect. Now the question is how long until the linux drivers support some sort of hardware accelerated 3D on 8500 chips.
Also, in XFree 4.2.0, are XVideo overlays working for Radeon 8500? All I see is 2D is supported, but 3D is not, and 2D "supported" could mean a lot of things. Also, does the GATOS stuff work with the 8500DV?
I've been considering purchasing an All-in-Wonder 8500DV, but if good support is not coming soon, I might hold off...
That worked fine when it was just one button. Now, when you have (typically) four to six buttons under a thumb, you need more dexterity for buttons than controlling a stick. I wondered the same thing so I tried playing with the buttons under the left hand and I had a hard time hitting the buttons I intended to compared to using my right hand, while I didn't really lose anything in terms of control.
I see a lot of people concluded from this that the Linux gaming market is not viable. While that may be the case, Loki in no way demonstrates it.
The problem here is they port a game after it is popular, with a lead time of at least 6 months to get from Windows to Linux. The Linux users who also like to play games alot are typically on x86 architecture, and have some version of Windows (even 95) lying around. Is it worth it to wait 6 months to a year to play a game on Linux, especially since by then the Windows version is in the bargain bin at 1/5 the price of the Linux version.
*If* there is a potential viable Linux gaming market (and that is a big *if*, the Linux desktop userbase is already small compared to Windows, and of those users, I would venture to say that most don't really care that much about games.), then the only hope to see it come forth is if the playing field is level, meaning that releases would have to be simultaneous, equally available (on the shelves), and equally priced. Given the circumstances, only Transgaming can have a short enough lead time to really sell enough to have any good numbers.
My guess would be that they woul dprobably get a list of the default MAC addressess for all these "cable/dsl routers" by linksys and the like and deny dhcp requests for those addresses... That would probably get the largest chunk of the customers. If they did this, Windows ICS and Linux IP MASQ/NAT (or OpenBSD, or FreeBSD, or whatever), would be immune...
Easy solution, maintain a bandwidth cap on each cable modem that is consistant with the typical usage. For example I have (currently) 2 Megabit down, and 768 kilobit upstream. The actual hardware is capable of higher speeds, but the cable modem has that cap on it. If so many people are actively using it such that their pipe can no longer support 2 Megabit per person, they will use SNMP to change the value after some sort of notification, I'm sure (the cable modem I use is SNMP managed). Of course, I keep an eye on that setting and if I see my cap go down, then I'd probably make a phone call to complain, unless I received warning.
Don't even bother with analogies like this, they are complete crap and inapplicable. You can interpret the situation however you like. In this case, I could say each "car" is an IP and the "road" is the ISP's pipe. Each computer system behind NAT would be considered passengers and that would be legal. Of course, then you have 4 people going 70 MPH and the entire anaolgy goes to pot there.
My stance is simple, pay per IP. You can play name games all you want with bandwidth versus speed, but the reality is that whether you call it bandwidth or speed, in computers it can be divided differently. The fact that there are multiple clients in a residence getting service in no way impacts the service any differently than a single client. Maybe four systems would generate 4x the traffic on average, but that is why our cable modems are capped anyway, right?
I'm just glad my AOL-Time-Warner owned roadrunner service explicitly tells me it is ok to run NATed systems and even that so long as I don't run for profit, I can operate whatever services I want on my connection. If they went out to screw me over though, then I would be mad as I have no alternative (too far from a CO for DSL, dialup is too crappy for NAT or services to be at all worth it).
But they really need to get over the Not-Invented-Here syndrome in so many places. One thing that stands out to me is that noatun is a crappy media player compared to other applications out there. Only video files I managed to get to play with it were MPG video files, and even then it crashed 8 times out of 10 (And this was KDE 2.2.2). In it they use mpeglib, which now works, but I wonder why they didn't use smpeg, which was more mature, from the start, was it simply because the lib was written by the author of kmpg, an older KDE media player? I wonder why they didn't have avifile support, that would be an easy way to play a *lot* more files. Compare noatun to, say, mplayer, which plays avi/asf, mpg, viv, rm (few), and mov, not to mention others. Within a couple of days using smpeg and avifile you can write a better media player than noatun...
On a positive note, it is good to see the widespread planned use of.ogg files.. In modern systems there is no reason to use wav anymore, and.ogg gives the KDE team a nice, perfectly legal way of reducing filesize (unlike mp3, which probably would be better for this except for legal reasons, since ogg takes more CPU time to decode still)
What about their open-source projects? Though many didn't acheive anything that impressive, smpeg is an extremely useful library for multimedia. OpenAL sounded nice as well, but I don't know how much that would be missed... Though not directly hosted by lokigames, how would SDL development progress, given that it is maintained by Sam Lantinga, same person chiefly responsible for SMPEG.
Granted, at least in the case of smpeg, there are plenty of alternatives (ffmpeg, mpeglib come to mind), but smpeg is *really* easy to write for. But SDL fills a very important role for multimedia and game development..
Well, RDRAM is crap in single-bank configurations. High-latency, and low bandwidth (relative to DDR). True, RDRAM runs at effective rates of 800 MHz, but the data path is reduced to 16 bits over the SDRAM 64 bit typical bus. Granted, RDRAM can allegedly be more easily configured in configurations where modules can be run in parallell, providing effective 32-bit bus, but I haven't seen this implemented in any consumer grade PC motherboards, and even then it wouldn't be clear cut that RDRAM would be a winner (especially with it's high latency). The only reason why RDRAM could even win is because RDRAM is much more efficient in a way, it can come much closer to its theoretical bandwidth than SDRAM can come to its theoretical limit.
In essence, Rambus memory is a complete bust, and Intel is *finally* giving up at least in part.
As much as your arguments may have sound logical reasoning, it really means nothing to consumers who don't develop. Consumers could care less how much of a pain in the ass it was for developers, they just care what they see. On that front, I think KDE, Gnome, and others offer a lot more power in their interfaces than Windows, and provided a pre-install, would be as easy to use as Windows, except you can't download any old application on the internet and expect it to run. MS seems less concerned about actually improving the product and more about making it different enough for an upgrade, while leveraging their position in the OS market to control other markets (IE, Media-related stuff (WMP, CD burning, simple movie editor)) All this said about developer space issues not making much of a difference, your argument still has a couple of flaws, so I do have some counterpoints:
1) The way drivers work in XFree isn't horrible, it's the amount of work required on behalf of the user that isn't so hot given the current tools. Automated tools to modify the XF86Config and copy files around can make things easier on the end user. But there is good reason why this can't be done as a simple tab on a nice control panel, Windows lets common users wreak all kinds of hell with the system, while Linux distros don't want things to be world writable... The core architecture is fine, it is user-space tools that keep this from working well. Just look at BeOS, loading device drivers was as simple as dragging it to a certain directory. I would argue a User would be more comfortable using a "wizard" interface, even if it doesn't have to do much, over copying a file, it just doesn't have that "customized" feel to it, if you understand me.
I have no idea about 2, probably a valid issue, considering the titles available for Windows vs. Linux, DirectX dominates and will continue to, unless MS loses a lot of market share for some inexplicable reason.
3) Hurd is a piece of crap. That said, Linux has "enough" modularity to provide the benefits that would be seen at the user level. Things like drivers can be loaded as modules with little difficulty. Of course, the problem is that modules are tied to kernel modules, but as nVidia shows, you can make a thin source layer to load a binary-only driver that enables a closed-source driver to run on different kernel revs. Of course , the layer should probably be available in the kernel itself, but kernel developers want open source drivers, something much easier to debug...
*Might* have been true at one point, but no longer. Might still be a superior architecture for content creation/changing, but the file format/codec support was always insufficient, though it was better than Linux at on epoint (Linux has now passed it, easily). Be's Media player was absolute crap, couldn't even playMPG system files well, they would have horrible frame loss. Media was decoded faster under linux on my 200 MHz machine than it was on my 400 MHz under BeOS. I truly admired the OS and thought it would be awesome for Desktop users, but I never did accept the claim that it was a superior multimedia OS, I thought it *could* be, with a lot of work, but for now if I had to do content creation quickly, I'd still have to use either Windows or Mac. The tools are coming slowly for Linux, but nothing on the level of Premiere...
That being said, if they would want to put some work into Be's media capabilities, It might be a good choice for a net appliance. Of course, *if* AOL wants to acquire an OS, it'll probably just let it sit still for the most part and just use it as leverage to keep MS from yanking the carpet out from under them...
One thing omitted in the Release notes...
on
Xfree86 4.2.0 Out
·
· Score: 3, Informative
Unless they royally screwed something up in the past few months, a show stopping XVideo bug with tdfx that was in 4.1.0 was fixed. I've been running CVS for months because of the bug. Basicly, if UYUV or YUY2 colorspace overlays were opened with the tdfx driver, the whole thing would crash out.... Shortly after then it was fixed in CVS, but it takes so long for them to release, I just had to use CVS. So if you use tdfx and certain media programs crash your X (particularly DivX videos are notable...), this is a *very* cool update...
That you can download Redhat for free:) On a related note, most companies buy *licenses* for OSes, when AOL gets interested, they buy the *OS*.
More seriously this seems plain wrong. Not too long ago I was AOL free. Then they bought my cable company and with it my internet connection and a good deal of the channels I like to watch. And now they may buy up the company that produces my distro. Well, if things go ok, then I could always switch to another distro, hopefully. Of course, with a player like AOL in the Linux distro market, I could see trouble waiting to happen with efforts not only to control RedHat distribution, but other distributions as well.. Looking to make a redhat-derived distribution? May not be as easy (I know, the GPL should legally prevent this, but big corps seem to be able to pour enough money at legal problems to make them go away.)
There is an unfortunate trend in most open-source projects that really needs to slow down. Gnome 2.x will be API incompatible with 1.x, and they are already planning a 3.x that will break 2.x compatibility. Sure, this sort of change means the available APIs can be very nice and slick and not have to suffer the clunkiness of older API design concepts, but it also means that people, organizations, and companies have a harder time maintaining products through time. As much as Windows irks me, they did keep backward compatibility right, similar to the x86 family. Not only are the latest Windows releases API compatible, but also ABI compatible with previous versions dating back to win16 and DOS days. Sure, your API is messy just as x86 assembly is messy, but I think that a lot of open source projects are getting to the point where they should decide on an ABI/API that is "good enough" to keep supporting through future versions. Sure, additions can be made, but breaking exisiting applications in the name of progress isn't popular among businesses that don't want to spend extra development time and money just to keep up with extreme API changes...
Of course, a longer pipeline not only means less work per clock, it means that when a branch misprediction occurs, more calculations are wasted in performing the operations proceeding the branch, and that work all gets flush on a mis-prediction.
One point, even if they do produce reliable, secure code, doesn't mean they are no longer the evil empire, they are the evil empire with better stuff:) They are the evil empire because they want to control a lot more than they should, and while this is no different than most other businesses, they are much closer to success... But then again you probably already knew that, just didn't think about it... Of course, AOL-Time-Warner is at least as scary as MS, if not more so now, IMHO...
Yes, but that would be insufficient since cheaters often rename identifiers and scramble the code a bit, enough to fool diff, but certainly not enough to fool these systems.
Of course it would be completely useless as all of the cheating detection systems I've ever seen could care less about the symbol names, only about stuff like the structures of the data and execution traces...
You would be surprised how well this works in practice, even in intro classes. When I was a freshman taking intro to cs, they used one of these programs and got few false positives. If it matched exactly, down to the variable names, then it would be completely pointless. The one that my college was using back then matched regardless of variable/function names, or any source formatting. Essentially, it examined the overall algorithm and run-time execution paths to determine if there was likely cheating.
Besides, even if the system turns up a high match between two programs falsely, it is ultimately a human who gets to review the case and make the call, after (presumably) discussing the matter with the student before actually doing anything that would leave a mark on the record.
And as an answer to the knee-jerk reaction of "that's not how it works in the real world!" I tend to agree, but not completely. As an instructor of mine once said you have to learn to dribble before you can play with other people in a team in Basketball, and as such one needs to develop his or her own personal programming skills independently before he or she may work effectively in teams.
Of course, some could argue that learning in teams would be more effective and perhaps more useful, but the point is there needs to be a mix of team and independent projects. Without independent projects at all, it is difficult to be sure that everyone is competent to pull their own weight, and part of the role of Universities in the world of business is to certify that a graduate possesses a good skillset, and without both team and individual assignments, this is impossible.
Of course, as is the case with everything, this doesn't stop cheating. If one collaborates with someone completely unrelated to the class, it can't catch that, but then again, there aren't that many people inclined to work their butt off at no benefit to them just to help some other person get a good grade.... Of course, I have seen the case where a guy goes way out of his way to help a pretty girl, but that is another story entirely...
Re:I was such a TNG addict back in the day
on
Star Trek TNG DVDs
·
· Score: 2
Ok, so you are saying seeing Wesley at the Helm of the enterprise caused you to skip class and work instead? Now either this is really stupid, and if true, well, I have no idea what to think of you... I would imagine that the scenario in TNG was more along the lines of how time worked in the Simpsons. Aside from the unavoidable aging of the real actors, it seems that while time passes and there is some cause and effect between episodes, the structure is in a sort of suspended animation and time doesn't really pass that much, or at least time doesn't factor into the writing that much.
Slashdot Mirror
I don't think they would have "had no problems" in another 2 or 3 years, they would have had the exact same problems they had now. What makes you think that the market 2-3 years from now would be more favorable? No one wants to wait 6-12 months just to pay more for a linux version that will probably break when the next major release of a distribution is released when a version for Windows is 1/5 the price in the bargain bin and will continue to run for several years given MSs backward compatiblity track record.
I bough Civ:CTP and Q3A from Loki because I wanted to see them do well, but the truth is the target market is not that huge to begin with and is also not so big on games. The ones that are big on games get their fix in Windows because Loki was too slow, the sad reality. Another reality we face is that Linux development in general is geared to open source projects, where breaking binary compatibilty frequently is at least somewhat acceptable, and API compatibility isn't much longer lived. Now with Loki gone, all those customers won't be able to upgrade too much in the future and continue to have the games they bought run correctly. For the most part, duplicate libraries can be maintained, but with a different libc major things would probably break.
Linux gets very nice ABI/APIs this way, but sacrifices the ability to play nice with binary-only products, and makes maintaining and updating a product much more expensive to companies, since they have to provide so many builds and modify source to keep current.
Oh, linking to c code from c++ is always easy (as is the case with SDL, from personal experience). Now using a C++ library from a C program.... That is tricky... You either have to make some really strange looking function call or have a thin C++ compiled wrapper to get the symbol names to something a C program can begin to understand...
Of course, if you want to do any more stuff with VCD and smpeg, PythonTheater/Xtheater is pretty easy to read and implements seekable VCD playback (http://xtheater.sourceforge.net/). Its code may be helpful in any enhancements to your app you might want to make. And if you run ROX, PythonTheater is AppDir based, so it's even cooler :)
They should have renamed the executable to quack3.exe before benchmarking :)
Kidding aside, it's cool to see Radeon 8500 definitively beat out the more expensive competitor in a next gen game, but of course, as anandtech points out, there was a bug with fog in the ATI driver which may have helped performance as a side effect. Now the question is how long until the linux drivers support some sort of hardware accelerated 3D on 8500 chips.
Also, in XFree 4.2.0, are XVideo overlays working for Radeon 8500? All I see is 2D is supported, but 3D is not, and 2D "supported" could mean a lot of things. Also, does the GATOS stuff work with the 8500DV?
I've been considering purchasing an All-in-Wonder 8500DV, but if good support is not coming soon, I might hold off...
That worked fine when it was just one button. Now, when you have (typically) four to six buttons under a thumb, you need more dexterity for buttons than controlling a stick. I wondered the same thing so I tried playing with the buttons under the left hand and I had a hard time hitting the buttons I intended to compared to using my right hand, while I didn't really lose anything in terms of control.
I see a lot of people concluded from this that the Linux gaming market is not viable. While that may be the case, Loki in no way demonstrates it.
The problem here is they port a game after it is popular, with a lead time of at least 6 months to get from Windows to Linux. The Linux users who also like to play games alot are typically on x86 architecture, and have some version of Windows (even 95) lying around. Is it worth it to wait 6 months to a year to play a game on Linux, especially since by then the Windows version is in the bargain bin at 1/5 the price of the Linux version.
*If* there is a potential viable Linux gaming market (and that is a big *if*, the Linux desktop userbase is already small compared to Windows, and of those users, I would venture to say that most don't really care that much about games.), then the only hope to see it come forth is if the playing field is level, meaning that releases would have to be simultaneous, equally available (on the shelves), and equally priced. Given the circumstances, only Transgaming can have a short enough lead time to really sell enough to have any good numbers.
My guess would be that they woul dprobably get a list of the default MAC addressess for all these "cable/dsl routers" by linksys and the like and deny dhcp requests for those addresses... That would probably get the largest chunk of the customers. If they did this, Windows ICS and Linux IP MASQ/NAT (or OpenBSD, or FreeBSD, or whatever), would be immune...
Easy solution, maintain a bandwidth cap on each cable modem that is consistant with the typical usage. For example I have (currently) 2 Megabit down, and 768 kilobit upstream. The actual hardware is capable of higher speeds, but the cable modem has that cap on it. If so many people are actively using it such that their pipe can no longer support 2 Megabit per person, they will use SNMP to change the value after some sort of notification, I'm sure (the cable modem I use is SNMP managed). Of course, I keep an eye on that setting and if I see my cap go down, then I'd probably make a phone call to complain, unless I received warning.
Don't even bother with analogies like this, they are complete crap and inapplicable. You can interpret the situation however you like. In this case, I could say each "car" is an IP and the "road" is the ISP's pipe. Each computer system behind NAT would be considered passengers and that would be legal. Of course, then you have 4 people going 70 MPH and the entire anaolgy goes to pot there.
My stance is simple, pay per IP. You can play name games all you want with bandwidth versus speed, but the reality is that whether you call it bandwidth or speed, in computers it can be divided differently. The fact that there are multiple clients in a residence getting service in no way impacts the service any differently than a single client. Maybe four systems would generate 4x the traffic on average, but that is why our cable modems are capped anyway, right?
I'm just glad my AOL-Time-Warner owned roadrunner service explicitly tells me it is ok to run NATed systems and even that so long as I don't run for profit, I can operate whatever services I want on my connection. If they went out to screw me over though, then I would be mad as I have no alternative (too far from a CO for DSL, dialup is too crappy for NAT or services to be at all worth it).
But they really need to get over the Not-Invented-Here syndrome in so many places. One thing that stands out to me is that noatun is a crappy media player compared to other applications out there. Only video files I managed to get to play with it were MPG video files, and even then it crashed 8 times out of 10 (And this was KDE 2.2.2). In it they use mpeglib, which now works, but I wonder why they didn't use smpeg, which was more mature, from the start, was it simply because the lib was written by the author of kmpg, an older KDE media player? I wonder why they didn't have avifile support, that would be an easy way to play a *lot* more files. Compare noatun to, say, mplayer, which plays avi/asf, mpg, viv, rm (few), and mov, not to mention others. Within a couple of days using smpeg and avifile you can write a better media player than noatun...
.ogg files.. In modern systems there is no reason to use wav anymore, and .ogg gives the KDE team a nice, perfectly legal way of reducing filesize (unlike mp3, which probably would be better for this except for legal reasons, since ogg takes more CPU time to decode still)
On a positive note, it is good to see the widespread planned use of
What about their open-source projects? Though many didn't acheive anything that impressive, smpeg is an extremely useful library for multimedia. OpenAL sounded nice as well, but I don't know how much that would be missed... Though not directly hosted by lokigames, how would SDL development progress, given that it is maintained by Sam Lantinga, same person chiefly responsible for SMPEG.
Granted, at least in the case of smpeg, there are plenty of alternatives (ffmpeg, mpeglib come to mind), but smpeg is *really* easy to write for. But SDL fills a very important role for multimedia and game development..
Well, RDRAM is crap in single-bank configurations. High-latency, and low bandwidth (relative to DDR). True, RDRAM runs at effective rates of 800 MHz, but the data path is reduced to 16 bits over the SDRAM 64 bit typical bus. Granted, RDRAM can allegedly be more easily configured in configurations where modules can be run in parallell, providing effective 32-bit bus, but I haven't seen this implemented in any consumer grade PC motherboards, and even then it wouldn't be clear cut that RDRAM would be a winner (especially with it's high latency). The only reason why RDRAM could even win is because RDRAM is much more efficient in a way, it can come much closer to its theoretical bandwidth than SDRAM can come to its theoretical limit.
In essence, Rambus memory is a complete bust, and Intel is *finally* giving up at least in part.
As much as your arguments may have sound logical reasoning, it really means nothing to consumers who don't develop. Consumers could care less how much of a pain in the ass it was for developers, they just care what they see. On that front, I think KDE, Gnome, and others offer a lot more power in their interfaces than Windows, and provided a pre-install, would be as easy to use as Windows, except you can't download any old application on the internet and expect it to run. MS seems less concerned about actually improving the product and more about making it different enough for an upgrade, while leveraging their position in the OS market to control other markets (IE, Media-related stuff (WMP, CD burning, simple movie editor)) All this said about developer space issues not making much of a difference, your argument still has a couple of flaws, so I do have some counterpoints:
1) The way drivers work in XFree isn't horrible, it's the amount of work required on behalf of the user that isn't so hot given the current tools. Automated tools to modify the XF86Config and copy files around can make things easier on the end user. But there is good reason why this can't be done as a simple tab on a nice control panel, Windows lets common users wreak all kinds of hell with the system, while Linux distros don't want things to be world writable... The core architecture is fine, it is user-space tools that keep this from working well. Just look at BeOS, loading device drivers was as simple as dragging it to a certain directory. I would argue a User would be more comfortable using a "wizard" interface, even if it doesn't have to do much, over copying a file, it just doesn't have that "customized" feel to it, if you understand me.
I have no idea about 2, probably a valid issue, considering the titles available for Windows vs. Linux, DirectX dominates and will continue to, unless MS loses a lot of market share for some inexplicable reason.
3) Hurd is a piece of crap. That said, Linux has "enough" modularity to provide the benefits that would be seen at the user level. Things like drivers can be loaded as modules with little difficulty. Of course, the problem is that modules are tied to kernel modules, but as nVidia shows, you can make a thin source layer to load a binary-only driver that enables a closed-source driver to run on different kernel revs. Of course , the layer should probably be available in the kernel itself, but kernel developers want open source drivers, something much easier to debug...
*Might* have been true at one point, but no longer. Might still be a superior architecture for content creation/changing, but the file format/codec support was always insufficient, though it was better than Linux at on epoint (Linux has now passed it, easily). Be's Media player was absolute crap, couldn't even playMPG system files well, they would have horrible frame loss. Media was decoded faster under linux on my 200 MHz machine than it was on my 400 MHz under BeOS. I truly admired the OS and thought it would be awesome for Desktop users, but I never did accept the claim that it was a superior multimedia OS, I thought it *could* be, with a lot of work, but for now if I had to do content creation quickly, I'd still have to use either Windows or Mac. The tools are coming slowly for Linux, but nothing on the level of Premiere...
That being said, if they would want to put some work into Be's media capabilities, It might be a good choice for a net appliance. Of course, *if* AOL wants to acquire an OS, it'll probably just let it sit still for the most part and just use it as leverage to keep MS from yanking the carpet out from under them...
then stand for America on Linux? :)
Unless they royally screwed something up in the past few months, a show stopping XVideo bug with tdfx that was in 4.1.0 was fixed. I've been running CVS for months because of the bug. Basicly, if UYUV or YUY2 colorspace overlays were opened with the tdfx driver, the whole thing would crash out.... Shortly after then it was fixed in CVS, but it takes so long for them to release, I just had to use CVS. So if you use tdfx and certain media programs crash your X (particularly DivX videos are notable...), this is a *very* cool update...
That you can download Redhat for free :) On a related note, most companies buy *licenses* for OSes, when AOL gets interested, they buy the *OS*.
More seriously this seems plain wrong. Not too long ago I was AOL free. Then they bought my cable company and with it my internet connection and a good deal of the channels I like to watch. And now they may buy up the company that produces my distro. Well, if things go ok, then I could always switch to another distro, hopefully. Of course, with a player like AOL in the Linux distro market, I could see trouble waiting to happen with efforts not only to control RedHat distribution, but other distributions as well.. Looking to make a redhat-derived distribution? May not be as easy (I know, the GPL should legally prevent this, but big corps seem to be able to pour enough money at legal problems to make them go away.)
That quote alone deserves a +5 funny :) What kind of cave are these people living in to call CSS a good, working acheivement for these people?
There is an unfortunate trend in most open-source projects that really needs to slow down. Gnome 2.x will be API incompatible with 1.x, and they are already planning a 3.x that will break 2.x compatibility. Sure, this sort of change means the available APIs can be very nice and slick and not have to suffer the clunkiness of older API design concepts, but it also means that people, organizations, and companies have a harder time maintaining products through time. As much as Windows irks me, they did keep backward compatibility right, similar to the x86 family. Not only are the latest Windows releases API compatible, but also ABI compatible with previous versions dating back to win16 and DOS days. Sure, your API is messy just as x86 assembly is messy, but I think that a lot of open source projects are getting to the point where they should decide on an ABI/API that is "good enough" to keep supporting through future versions. Sure, additions can be made, but breaking exisiting applications in the name of progress isn't popular among businesses that don't want to spend extra development time and money just to keep up with extreme API changes...
Of course, a longer pipeline not only means less work per clock, it means that when a branch misprediction occurs, more calculations are wasted in performing the operations proceeding the branch, and that work all gets flush on a mis-prediction.
One point, even if they do produce reliable, secure code, doesn't mean they are no longer the evil empire, they are the evil empire with better stuff :) They are the evil empire because they want to control a lot more than they should, and while this is no different than most other businesses, they are much closer to success... But then again you probably already knew that, just didn't think about it... Of course, AOL-Time-Warner is at least as scary as MS, if not more so now, IMHO...
Yes, but that would be insufficient since cheaters often rename identifiers and scramble the code a bit, enough to fool diff, but certainly not enough to fool these systems.
Of course it would be completely useless as all of the cheating detection systems I've ever seen could care less about the symbol names, only about stuff like the structures of the data and execution traces...
You would be surprised how well this works in practice, even in intro classes. When I was a freshman taking intro to cs, they used one of these programs and got few false positives. If it matched exactly, down to the variable names, then it would be completely pointless. The one that my college was using back then matched regardless of variable/function names, or any source formatting. Essentially, it examined the overall algorithm and run-time execution paths to determine if there was likely cheating.
Besides, even if the system turns up a high match between two programs falsely, it is ultimately a human who gets to review the case and make the call, after (presumably) discussing the matter with the student before actually doing anything that would leave a mark on the record.
And as an answer to the knee-jerk reaction of "that's not how it works in the real world!" I tend to agree, but not completely. As an instructor of mine once said you have to learn to dribble before you can play with other people in a team in Basketball, and as such one needs to develop his or her own personal programming skills independently before he or she may work effectively in teams.
Of course, some could argue that learning in teams would be more effective and perhaps more useful, but the point is there needs to be a mix of team and independent projects. Without independent projects at all, it is difficult to be sure that everyone is competent to pull their own weight, and part of the role of Universities in the world of business is to certify that a graduate possesses a good skillset, and without both team and individual assignments, this is impossible.
Of course, as is the case with everything, this doesn't stop cheating. If one collaborates with someone completely unrelated to the class, it can't catch that, but then again, there aren't that many people inclined to work their butt off at no benefit to them just to help some other person get a good grade.... Of course, I have seen the case where a guy goes way out of his way to help a pretty girl, but that is another story entirely...
Ok, so you are saying seeing Wesley at the Helm of the enterprise caused you to skip class and work instead? Now either this is really stupid, and if true, well, I have no idea what to think of you... I would imagine that the scenario in TNG was more along the lines of how time worked in the Simpsons. Aside from the unavoidable aging of the real actors, it seems that while time passes and there is some cause and effect between episodes, the structure is in a sort of suspended animation and time doesn't really pass that much, or at least time doesn't factor into the writing that much.