Yes, but the poster was refering to the GUI on the Connect app, not e-ink technology; you know, the Sony "iTunes" for books...
Why does it look familiar? BTW, if it's an itunes reference (thus making me look dumber than I am, due to my clarification above), then I should note that I've never actually seen itunes. I just know what it's supposed to do.
Right. Evince. Like *that* doesn't leak memory like a sieve, on top of the huge amount it uses anyway. Poppler is getting better, but it's not quite there yet. Xpdf may be fugly as hell (it's a motif/lesstif app), but there really isn't any replacement for it yet.
Anyway's, I agree that PDF files are the way to go for presentation distributing. I personally like DVI for that purpose better, but most windoze users wouldn't know what to do with a DVI file, and AFAIK, Evince (& perhaps okular?) is the only pre-installed gui viewer that will display them, and most non-academics I know have never heard of xdvi (and TeX only because of LyX).
(to the parent) Agreed, reproducability is key. Not only for your customers, but just for releases in general (your QA guys love you if you can deliver builds to them and actually know which build you gave them by the time they're done testing it). Also, having stuff wrapped in deb (or, I suppose rpm) packages is really nice too, as it makes field-upgrades a snap (even on embedded appliances, provided you have a deliver mechanism), and again, your QA guys will love you if they don't have to wait for a whole new build to test out a fix; just pass them a handful of debs that you rolled on your own dev machine (source deltas checked in, of course).
(to the OP) Just make sure all of your build constituents are under version control (subversion is *fine*, really... you probably want to stay away from CVS, they are different, trust me). That should include all source files, all config files, all make files, all make automation scripts, and even any notes you kept while setting the damn thing up. The worst problem I've seen in source control/build automation is magic files that do magic things (not so much fun when hardware fails). Even if it requires some manual process to deploy some of the build scripts from the source tree to a build slave, at least there is a central point from which to collaboratively edit them.
FAI is bad news, big time. It's complicated and frustrating. If you want to customise and deploy Debian on servers, then it's probably what you want, however. FAI is really good for a server or desktop deployment environment, like, for example, if you had a standard corporate server platform, or standard corporate desktop. You use your FAI rig to clone out machines, and when you upgrade certain debs, you just remotely command your already deployed machines to 'apt-get upgrade' (or better yet, feed 'apt-get install' a programmatically-tailored & delivered list of packages). You can use 'apt-get dist-upgrade' too, but you'd really need a deep understanding of the dependency tree and you'd need to make a new 'distro' release so that apt knows what it's upgrading too (not to mention field-updating the sources.list). It's a non-trivial problem, but the tools will do it, and once it's set up, you have a single point of maintainance and control for the machines you're managing.
For the poster's particular appliance, something like FAI or "kickstart" may not be what you need. In my last position (also embedded Debian, custom kernel, custom glibc, etc) installation wasn't simply slipping a FAI cd into the cdrom drive (there *was* no cdrom drive... embedded appliance, remember?). We actually had a flash device and had our own flash burn tool. In addition, our device had custom FPGA bits (on Xilinx chips), so we actually built the tools themselves out of source control, as well as the FPGA bits, and then used the tools to write the filesystem to the flash via the bootloader we wrote into the FPGA code.
We built our install tree using debootstrap and a custom package list (which I think FAI would have used anyway, IIRC), and then trucked the debootstrap'ed directory tree on to the flash using a binary of the tool that was built. So, our build actually consisted of more than just the flash filesystem, it was a snapshot of all the associated tools as well. I definitely suggest investing in both source control and a RAID machine big enough to store snapshots (svn branching and tagging is the de facto way to associate a particular build with it's source files, frozen in time). That way (and I promise this will happen) when you are nearing a release, and the feature list just grew, and you can't quite get there by your delivery date, you can backport your last few weeks of bugfixes to the release branch (which you've already tagged), from which you can produce a release build.
Certainly store any release snapshots, but I'd suggest also keeping any snapshots you pass on to your QA department. If you don't have a QA dept., then you should choose an approximate time interval and keep the b
Camphor and eicosapentaenic acid... check out that article linked by the parent. Fake snake oil contained red peppers, hence capsaicin, and could have worked similarly via a different mechanism.
Dude, that's not what the OSI does. I think that the OSI's credibility isn't what is at stake here; rather, it's purpose, mission, and to some extent, it's public appearance. The OSI's web site (while puzzling and frustrating to navigate) makes that particular information no big secret (spend 20-30m over lunch reading their policy docs... doesn't take that long, as their charter is pretty short and simple). They have the OSI certification and mark program, a 'non-proliferation treaty' (joke), and an awards program. Essentially, other than straight advocacy on the website, that is all the scope they claim to cover.
I kind of wish that their bylaws, and any amendments to them as time goes on, were posted. They are a 503(c), after all, and "open", in general, should indicate transparency. Either I can't find them on the site, or they aren't there (though I admit their absence probably more of an oversight, or perhaps the lack of desire on the part of the site maintainer to type & format pages of legalese).
If you want an opinion without input from microsoft, submit the license for review to RMS. He already posted an analysis of their "shared source" license (the one for the c-sharp cli code, etc). Of course, you'll get an answer orthogonally related to the GPL, but GPL-compatibilty (in my opinion) is the best (and most useful) basic rubric for openness, since "open" is a subset of "free".
If RMS is good at anything (besides writing code and stirring up controversy) it's reviewing licenses with the good folks at the FSF.
For what it's worth, a cursory reading of the license leads me to believe that this microsoft community license is an open source licence. Specifically, it seems to fall under the category of "free" but "GPL-incompatible", because of the patent clauses (which may not be inherently a bad idea, but may, nonetheless, be incompatible with the GNU GPL:).
Actually... look at section 3(D): "If you begin patent litigation against Microsoft over patents that you think may apply to the software (including a cross-claim or counterclaim in a lawsuit), your license to the software ends automatically." I'm pretty sure that's a deal-breaker, putting it in the non-free waters (possibly for similar reasons as the sgi free software license).
Well, there it is. From an armchair paralegal. BTW, this post is licensed under the GPL2.0, just in case it's wrong...
It's not too bad (at least on a 4g). My problems lie more along the lines of stability. It does lock up occasionally and need to be rebooted (then I just load up my playlist again, and on I go). That's annoying. It stayed alive through a five hour flight with a clip-on pair of bigger-than-stupid-white-aspirins headphones at high volume (to drown out airplane noise). I suspect that battery life is somewhere between a half and a third of normal battery life.
Important thing to remember, too, is that I got my 4g second hand (it was free!! with a busted hard drive... I replaced it with the 15G drive from my Sharp laptop), and I have no idea how diminished its battery life was before I got it.
Anywho, it also doesn't play my maximum quality (q10) OGG files very well (skips out a bunch) because the Rockbox guys haven't worked out the best way to utilize the second cpu core. Up to about q8 it's fine, though. I can play my OGG's, carry around my files, and not need mac os, windows, or itunes. I probably won't dump it until I get an iAudio X5L (or the 60GB... haven't chosen).
On the good side, you can sometimes trick it in to playing while it's charging by USB... I don't know if that's documented or not.
oops, just read on http://savestargatesg-1.com/ not to write "Stargate" anything on the envelope. That way they have to actually open it to know what it's about.
I wonder. Are they actually so detached from their audience as to toss fan letters that refer to undesired subject matter on the envelope? I hope not. I hope they listen.
Oh, and send letters to Showtime too, urging them to take the series on.
Thank you for the (albeit tiny) hint of hope. Despite it's ups and downs, SG1 consistently had the best writing, characterization, and cinematics of its genre (albeit, also tiny). I hope that the effect of the letter writing campaign is not diluted by less effective calls to action (emails, the poll, etc.).
For those who missed it above, here is SG1-Solutions commentary with the network exec's mailing addresses:
So, fans... listen up! Go sign the petition. Then send a few letters (actual paper letters, with stamps). Say something like "Please bring back the show, make an excellent miniseries, or even an awesome feature film, and I promise to buy the DVD's!!!".
It would probably help to write "ATTN: Save Stargate SG-1" or some such on the outside of the envelope itself (like on the line after the recipient's name). That way, if they are just counting letters without opening them, the letter count will grow more quickly.
Then print up about fifty copies and get your buddies' names on them. Ask them to mail them ("Pretty please!!! It's only fifty cents!!").
Then go to a bar and bitch about the Sci-Fi channel over scotch (everyone will stare, I promise... but it might be cathartic).
The real question is how the hell I'm gonna break the news to my wife...
Excellent point. Running win32 library code is difficult enough without worrying about architectural concerns. Modifying endianness on the fly? This kind of stuff is done, but it's really tough. If you really want to know how hard it is just ask the developers on the mplayer team that actually built the part of the i/o plugins that imports win32 codecs... I'm sure they have stories to tell.
Not to mention that Real Networks would be stupid to not realize that the same code they open has, at least, the possibility of being ported away from x86. Or to a BSD on x86. Or to BSD on a non-x86 (older mac, sparc station, IBM Risc/6000, etc). Or (and this, to me is the most important) to a non-x86 embedded platform, such as linux + qtopia on ARM like the Sharp Zauruses had. Actually, linux on ARM was also used for the nokia 770 (which I believe had some of Real's software), and Sony's new mylo.
So, there are lots of reasons why open will be good. If anything, I'd really appreciate not having gxine or mplayer hang or crap out on poorly encoded or corrupted wmv files... Not that Helix has the best reputation for stability, but we can keep hoping. One thing I know for sure; more open won't make more suck.
Yeah, but don't forget potential shareholders. No, I'm not talking about the unwashed masses, but the *other* employees whose options are unexercised. Profit-taking measures like the ones we're talking about will dilute a share value past everyone else's strike price in a hurry.
The staff, I would say, stand to lose as much as (or, proportionally more than) the investment pool. Make no mistake, it's not like my options would be back-dated with the CFO's...
Sorry for the vitriolic return, but this guy needs to go work for startup tech companies for a six or seven (as an *engineer*, not on product managment). Survey a few who've hopped from one shining star to another, just to see the star fall, and the options agreement screw the folks who build the products that make these companies fly (for the year or two they exist until the Bad Things start happening). If you've ever worked in the roller-coaster startup industry, you know what I mean by the Bad Things. Like when the investors and your C*O's start getting into political warfare, and the layoffs start, or the Wierd Policies begin. Then, when new rounds of funding come in, and everyone's options are diluted, the engineering staff is always assured that theirs will be "evened out" or they'll be "squared up".
Bullshit.
What we see again and again is execs doing what they can to take care of number one. The company I'm with now is the first one in my life that I've worked at where I feel like I'm being told the (basic) truth, and some of the principles have a personal stake (read, $$$) in the future of the company. Even then, the value of our options is essentially fictional until we Go To Market with our product, or we are Acquired.
This crap is rampant... no doubt CEO's are crying about it, and it's just like BusinessWeek to fly that flag.
Well, that depends on the breed. See, donkeys lack fertility, hence they cannot reproduce. However, there is no reason that this should dampen their desire to enact the motions. Now, if the donkeys in question are not attempting to breed with the other farm animals (say, the hogs, or possibly the sheep) then their love of sex would not be deviant.
No, that's different. Read the ATI section of the DRI website. Specs for cards up to the Radeon 9200 are available to individual developers, pending an NDA. That is *not* an open API. I don't know what technology is included in the developer resources, but if it's protected by NDA, I would have to assume some part of it are considered by ATI to be trade secrets.
Check out Mike Harris' take on the NDA/DRI driver development issue. I know, this doesn't reference ATI specifically, but the ATI section of the FDO wiki does, unequivocally, state that the important reference materials are locked up. Anyway, from Mike's treatment of the subject, it is clear that not just anybody gets to see the guts. I'm assuming that the NDA-restricted information excludes actual licensed IP (SGI's and S3's).
Yeah, the S3TC situation is crap. In that case, the text compression format is well known and documented. We're just not allowed to implement it because the right to use it would have to be licensed directly from S3 (or whomever it is that owns them now). It is a problem.
They should release it for non-commercial use, at least.
Who knows where that licensing authority is now... could be the guys that bought SONICblue, could be VIA, etc. S3 kinda exploded, and the pieces flew out pretty far. I wouldn't be surprised it ATI and nVidia picked up bits, too.
"As a result, the lines are starting to blur... between service companies and software companies."
It seems to me that the F/OSS phenomenon is largely responsible for this shift. Think back to Cygnus, ISC, and other companies like them. For that matter, the early Red Hat years seem to fit that description, as well. Value-added service on top of a GPL'd stack is far from uncommon, these days, and often makes for a rather reasonable business strategy.
Couple that with IBM's grand (and expensive) ongoing experiment with gnu/linux, and this sort of observation is hardly surprising. It will be interesting to see what tech from these recent acquisitions make their way out into the F/OSS community at large.
Eh? FUD? I never claimed that any of the games I mentioned (including Q4 and UT'04) were the discontinued ones. No, I'm talking like all the awesome Sid Meier games that Loki ported, for example (well, *I* liked them). Remember Descent? IIRC, Descent 4 played natively on gnu/linux. That series was discontinued! Remember Tribes 2? Tribes: Vengeance *can't* be ported because of the physics engine they chose to use. I played America's Army for a while, and icculus has to let go of that one because the U.S. army is discontinuing the gnu/linux version (I thought it was pretty cool, others may not). Of course I love free games, but to me, the richness and depth of a game that has had thousands of hours of work put into it with professional animators, tileset artists, professional voice-actors etc., is worth paying for. Neverwinter Nights is a great example of that.
Anyway, my point is that as far as gnu/linux gaming goes, I'm not terribly difficult to please... for example, NWN is a fantastic game and I still play it, even though the aurora toolset was not ported natively by BioWare, and even though we had to install from a windows install initially (then, from a humongous download of the client resources, and then *finally* from zip archives in the platinum edition, or the nice Tuxgames installer with HotU, IIRC), and even though we had to wait a really long time for those bastards at radgametools to give us a bink video player so we could patch in the cut-scenes (which you can do with a community-written perl script! It's awesome, they play right between the chapter transitions like they are supposed to). As long as the game plays natively, and is complete (meaning that you can install it, expect patch releases fairly closely to Win32/Mac patches, and can play *all* the features & levels), then I'm reasonably happy.
I don't want to install cedega. I don't want a transgaming subscription. I don't want emulation or API-reimplementation or play within a virtual machine. And dang it, I want to buy a box with a penguin printed on it somewhere, *not* the windows version (with gnu/linux client binaries bundled). I want my purchase to be counted as it is. Tuxgames has been pretty good to me so far, but they can only distribute what is produced.
I'm sorry if what I said sounded like FUD, but in comparison to the Loki days, we certainly don't get a wide variety of the latest and most popular releases. Perhaps that is not such a bad thing, considering the steady flow of crap being pushed into the market, but Loki really picked some gems. Those were, without exception, the golden days of gnu/linux gaming.
That's a stupid excuse, though. They could always isolate the SGI-laden parts, LGPL the rest, and let the community at least have a fighting chance at replacing what's behind the proprietary API's. I'm not claiming that our homebrew routines would *ever* be better, but I suppose it is within the realm of possibility. Oh, and when I say "always", I do really mean *always*... at any point, even right this minute, they could do so.
The non-licensed parts of the code don't have to compile to be released. Besides, when bugs are traced back into the dark proprietary code, that would also make ATI the good guys and SGI the bad guys. ATI could claim that the licensed part is really fast and awesome and sweet, but proprietary, and that the community is welcome to try and replace it with something fast and awesome and sweet, but open. Or even something slow and crappy, but rock-solid stable, that plays nice with Xorg and the kernel.
I suppose they might have licensed other companies code and signed away their right to ever release any code they ever write that uses the licensed bits. That would be a collosal blunder, but would partially account for silence on the subject.
I'm fairly certain that the real reason lies not the code ATI has licensed, but the code/tech they've worked hard on and feel they need to keep secret or else lose their edge against nVidia. Of course, it seems that same statement could be made, swapping the names of the two companies, and still be true. In fact, the "trade secret" and "intellectual property" argument is almost certainly the biggest reason for closed-source driver code. Besides, how can a company who is losing money afford to give anything away for free? At least it always seems like the investors and board of directors of tech companies seem to believe that they are perpetually bleeding cash, even when they file record profits with the SEC.
Anyway, that's quite enough ranting and unsubstantiated libel for one post.
I personally try very hard to only run GPL'ed, natively-compiled applications, and to contribute back to as many as I have to skills to help. This, I think, is part of being a good neighbor.
However, in the interest of helping a new convert stay on the side of the light, if you ever miss the popular windows games, you should consider Cedega from TransGaming. Several guys here in my office run it on their Gentoo or Debian boxes (so it'll probably work on Ubuntu also), and play World of Warcraft and Battlefield 2, etc. It's good to have a beefy machine, but it's more important to have a nice graphics adaptor (my buddies here have NVidia cards).
Anyway, I hate to sound like an advertisement for them, since I think that projects like Cedega and NDIS are generally bad for FOSS in the long run. After seeing how happy some of my friends are to be able to play certain games on their GNU/Linux laptops, some over (mostly) functioning wireless LAN connections via NDIS wrapper, I have to admit that they are generally good for GNU/Linux in the short term.
Also, keep in mind that if (when) you have money to buy your shiny new Mac OS box, you can also put Ubuntu on there as well, and switch handily between them (simultaneously, I believe). That will give you an easy migration path from your old box without having to abandon any of your new L33t Ubuntu skills.
Yeah! And Neverwinter Nights! And Return to Castle Wolfenstein! And Tribes 2! And UT! And Quake! And Frozen Bubble! Too bad so many of the professionally produced ones are unavailable or discontinued now... for a time, it was good.
Slashdot Mirror
oKular *is* the new Kpdf. It also uses poppler, and hence brings nothing new to the table, other than being a Qt-based app instead of a GTK-based app.
Yes, but the poster was refering to the GUI on the Connect app, not e-ink technology; you know, the Sony "iTunes" for books...
Why does it look familiar? BTW, if it's an itunes reference (thus making me look dumber than I am, due to my clarification above), then I should note that I've never actually seen itunes. I just know what it's supposed to do.
Right. Evince. Like *that* doesn't leak memory like a sieve, on top of the huge amount it uses anyway. Poppler is getting better, but it's not quite there yet. Xpdf may be fugly as hell (it's a motif/lesstif app), but there really isn't any replacement for it yet.
Anyway's, I agree that PDF files are the way to go for presentation distributing. I personally like DVI for that purpose better, but most windoze users wouldn't know what to do with a DVI file, and AFAIK, Evince (& perhaps okular?) is the only pre-installed gui viewer that will display them, and most non-academics I know have never heard of xdvi (and TeX only because of LyX).
(to the parent)
Agreed, reproducability is key. Not only for your customers, but just for releases in general (your QA guys love you if you can deliver builds to them and actually know which build you gave them by the time they're done testing it). Also, having stuff wrapped in deb (or, I suppose rpm) packages is really nice too, as it makes field-upgrades a snap (even on embedded appliances, provided you have a deliver mechanism), and again, your QA guys will love you if they don't have to wait for a whole new build to test out a fix; just pass them a handful of debs that you rolled on your own dev machine (source deltas checked in, of course).
(to the OP)
Just make sure all of your build constituents are under version control (subversion is *fine*, really... you probably want to stay away from CVS, they are different, trust me). That should include all source files, all config files, all make files, all make automation scripts, and even any notes you kept while setting the damn thing up. The worst problem I've seen in source control/build automation is magic files that do magic things (not so much fun when hardware fails). Even if it requires some manual process to deploy some of the build scripts from the source tree to a build slave, at least there is a central point from which to collaboratively edit them.
FAI is bad news, big time. It's complicated and frustrating. If you want to customise and deploy Debian on servers, then it's probably what you want, however. FAI is really good for a server or desktop deployment environment, like, for example, if you had a standard corporate server platform, or standard corporate desktop. You use your FAI rig to clone out machines, and when you upgrade certain debs, you just remotely command your already deployed machines to 'apt-get upgrade' (or better yet, feed 'apt-get install' a programmatically-tailored & delivered list of packages). You can use 'apt-get dist-upgrade' too, but you'd really need a deep understanding of the dependency tree and you'd need to make a new 'distro' release so that apt knows what it's upgrading too (not to mention field-updating the sources.list). It's a non-trivial problem, but the tools will do it, and once it's set up, you have a single point of maintainance and control for the machines you're managing.
For the poster's particular appliance, something like FAI or "kickstart" may not be what you need. In my last position (also embedded Debian, custom kernel, custom glibc, etc) installation wasn't simply slipping a FAI cd into the cdrom drive (there *was* no cdrom drive... embedded appliance, remember?). We actually had a flash device and had our own flash burn tool. In addition, our device had custom FPGA bits (on Xilinx chips), so we actually built the tools themselves out of source control, as well as the FPGA bits, and then used the tools to write the filesystem to the flash via the bootloader we wrote into the FPGA code.
We built our install tree using debootstrap and a custom package list (which I think FAI would have used anyway, IIRC), and then trucked the debootstrap'ed directory tree on to the flash using a binary of the tool that was built. So, our build actually consisted of more than just the flash filesystem, it was a snapshot of all the associated tools as well. I definitely suggest investing in both source control and a RAID machine big enough to store snapshots (svn branching and tagging is the de facto way to associate a particular build with it's source files, frozen in time). That way (and I promise this will happen) when you are nearing a release, and the feature list just grew, and you can't quite get there by your delivery date, you can backport your last few weeks of bugfixes to the release branch (which you've already tagged), from which you can produce a release build.
Certainly store any release snapshots, but I'd suggest also keeping any snapshots you pass on to your QA department. If you don't have a QA dept., then you should choose an approximate time interval and keep the b
Camphor and eicosapentaenic acid... check out that article linked by the parent. Fake snake oil contained red peppers, hence capsaicin, and could have worked similarly via a different mechanism.
Dude, that's not what the OSI does. I think that the OSI's credibility isn't what is at stake here; rather, it's purpose, mission, and to some extent, it's public appearance. The OSI's web site (while puzzling and frustrating to navigate) makes that particular information no big secret (spend 20-30m over lunch reading their policy docs... doesn't take that long, as their charter is pretty short and simple). They have the OSI certification and mark program, a 'non-proliferation treaty' (joke), and an awards program. Essentially, other than straight advocacy on the website, that is all the scope they claim to cover.
:).
I kind of wish that their bylaws, and any amendments to them as time goes on, were posted. They are a 503(c), after all, and "open", in general, should indicate transparency. Either I can't find them on the site, or they aren't there (though I admit their absence probably more of an oversight, or perhaps the lack of desire on the part of the site maintainer to type & format pages of legalese).
If you want an opinion without input from microsoft, submit the license for review to RMS. He already posted an analysis of their "shared source" license (the one for the c-sharp cli code, etc). Of course, you'll get an answer orthogonally related to the GPL, but GPL-compatibilty (in my opinion) is the best (and most useful) basic rubric for openness, since "open" is a subset of "free".
If RMS is good at anything (besides writing code and stirring up controversy) it's reviewing licenses with the good folks at the FSF.
For what it's worth, a cursory reading of the license leads me to believe that this microsoft community license is an open source licence. Specifically, it seems to fall under the category of "free" but "GPL-incompatible", because of the patent clauses (which may not be inherently a bad idea, but may, nonetheless, be incompatible with the GNU GPL
Actually... look at section 3(D): "If you begin patent litigation against Microsoft over patents that you think may apply to the software (including a cross-claim or counterclaim in a lawsuit), your license to the software ends automatically." I'm pretty sure that's a deal-breaker, putting it in the non-free waters (possibly for similar reasons as the sgi free software license).
Well, there it is. From an armchair paralegal. BTW, this post is licensed under the GPL2.0, just in case it's wrong...
It's not too bad (at least on a 4g). My problems lie more along the lines of stability. It does lock up occasionally and need to be rebooted (then I just load up my playlist again, and on I go). That's annoying. It stayed alive through a five hour flight with a clip-on pair of bigger-than-stupid-white-aspirins headphones at high volume (to drown out airplane noise). I suspect that battery life is somewhere between a half and a third of normal battery life.
Important thing to remember, too, is that I got my 4g second hand (it was free!! with a busted hard drive... I replaced it with the 15G drive from my Sharp laptop), and I have no idea how diminished its battery life was before I got it.
Anywho, it also doesn't play my maximum quality (q10) OGG files very well (skips out a bunch) because the Rockbox guys haven't worked out the best way to utilize the second cpu core. Up to about q8 it's fine, though. I can play my OGG's, carry around my files, and not need mac os, windows, or itunes. I probably won't dump it until I get an iAudio X5L (or the 60GB... haven't chosen).
On the good side, you can sometimes trick it in to playing while it's charging by USB... I don't know if that's documented or not.
That would be a *click* wheel, and I hate the damn thing. Give me a jog dial and some buttons any day.
oops, just read on http://savestargatesg-1.com/ not to write "Stargate" anything on the envelope. That way they have to actually open it to know what it's about.
I wonder. Are they actually so detached from their audience as to toss fan letters that refer to undesired subject matter on the envelope? I hope not. I hope they listen.
Oh, and send letters to Showtime too, urging them to take the series on.
Thank you for the (albeit tiny) hint of hope. Despite it's ups and downs, SG1 consistently had the best writing, characterization, and cinematics of its genre (albeit, also tiny). I hope that the effect of the letter writing campaign is not diluted by less effective calls to action (emails, the poll, etc.).
For those who missed it above, here is SG1-Solutions commentary with the network exec's mailing addresses:
http://stargate-sg1-solutions.com/blog/?p=650
So, fans... listen up! Go sign the petition. Then send a few letters (actual paper letters, with stamps). Say something like "Please bring back the show, make an excellent miniseries, or even an awesome feature film, and I promise to buy the DVD's!!!".
It would probably help to write "ATTN: Save Stargate SG-1" or some such on the outside of the envelope itself (like on the line after the recipient's name). That way, if they are just counting letters without opening them, the letter count will grow more quickly.
Then print up about fifty copies and get your buddies' names on them. Ask them to mail them ("Pretty please!!! It's only fifty cents!!").
Then go to a bar and bitch about the Sci-Fi channel over scotch (everyone will stare, I promise... but it might be cathartic).
The real question is how the hell I'm gonna break the news to my wife...
Excellent point. Running win32 library code is difficult enough without worrying about architectural concerns. Modifying endianness on the fly? This kind of stuff is done, but it's really tough. If you really want to know how hard it is just ask the developers on the mplayer team that actually built the part of the i/o plugins that imports win32 codecs... I'm sure they have stories to tell.
Not to mention that Real Networks would be stupid to not realize that the same code they open has, at least, the possibility of being ported away from x86. Or to a BSD on x86. Or to BSD on a non-x86 (older mac, sparc station, IBM Risc/6000, etc). Or (and this, to me is the most important) to a non-x86 embedded platform, such as linux + qtopia on ARM like the Sharp Zauruses had. Actually, linux on ARM was also used for the nokia 770 (which I believe had some of Real's software), and Sony's new mylo.
So, there are lots of reasons why open will be good. If anything, I'd really appreciate not having gxine or mplayer hang or crap out on poorly encoded or corrupted wmv files... Not that Helix has the best reputation for stability, but we can keep hoping. One thing I know for sure; more open won't make more suck.
Yes! And that makes it the most useful tool for building your own trusted bios, then kernel, then OS, then assembler, then compiler...
Yeah, but don't forget potential shareholders. No, I'm not talking about the unwashed masses, but the *other* employees whose options are unexercised. Profit-taking measures like the ones we're talking about will dilute a share value past everyone else's strike price in a hurry.
The staff, I would say, stand to lose as much as (or, proportionally more than) the investment pool. Make no mistake, it's not like my options would be back-dated with the CFO's...
Sorry for the vitriolic return, but this guy needs to go work for startup tech companies for a six or seven (as an *engineer*, not on product managment). Survey a few who've hopped from one shining star to another, just to see the star fall, and the options agreement screw the folks who build the products that make these companies fly (for the year or two they exist until the Bad Things start happening). If you've ever worked in the roller-coaster startup industry, you know what I mean by the Bad Things. Like when the investors and your C*O's start getting into political warfare, and the layoffs start, or the Wierd Policies begin. Then, when new rounds of funding come in, and everyone's options are diluted, the engineering staff is always assured that theirs will be "evened out" or they'll be "squared up".
Bullshit.
What we see again and again is execs doing what they can to take care of number one. The company I'm with now is the first one in my life that I've worked at where I feel like I'm being told the (basic) truth, and some of the principles have a personal stake (read, $$$) in the future of the company. Even then, the value of our options is essentially fictional until we Go To Market with our product, or we are Acquired.
This crap is rampant... no doubt CEO's are crying about it, and it's just like BusinessWeek to fly that flag.
Well, that depends on the breed. See, donkeys lack fertility, hence they cannot reproduce. However, there is no reason that this should dampen their desire to enact the motions. Now, if the donkeys in question are not attempting to breed with the other farm animals (say, the hogs, or possibly the sheep) then their love of sex would not be deviant.
Wasn't it obvious?
No, that's different. Read the ATI section of the DRI website. Specs for cards up to the Radeon 9200 are available to individual developers, pending an NDA. That is *not* an open API. I don't know what technology is included in the developer resources, but if it's protected by NDA, I would have to assume some part of it are considered by ATI to be trade secrets.
Check out Mike Harris' take on the NDA/DRI driver development issue. I know, this doesn't reference ATI specifically, but the ATI section of the FDO wiki does, unequivocally, state that the important reference materials are locked up. Anyway, from Mike's treatment of the subject, it is clear that not just anybody gets to see the guts. I'm assuming that the NDA-restricted information excludes actual licensed IP (SGI's and S3's).
Yeah, the S3TC situation is crap. In that case, the text compression format is well known and documented. We're just not allowed to implement it because the right to use it would have to be licensed directly from S3 (or whomever it is that owns them now). It is a problem.
They should release it for non-commercial use, at least.
Who knows where that licensing authority is now... could be the guys that bought SONICblue, could be VIA, etc. S3 kinda exploded, and the pieces flew out pretty far. I wouldn't be surprised it ATI and nVidia picked up bits, too.
It seems to me that the F/OSS phenomenon is largely responsible for this shift. Think back to Cygnus, ISC, and other companies like them. For that matter, the early Red Hat years seem to fit that description, as well. Value-added service on top of a GPL'd stack is far from uncommon, these days, and often makes for a rather reasonable business strategy.
Couple that with IBM's grand (and expensive) ongoing experiment with gnu/linux, and this sort of observation is hardly surprising. It will be interesting to see what tech from these recent acquisitions make their way out into the F/OSS community at large.
Eh? FUD? I never claimed that any of the games I mentioned (including Q4 and UT'04) were the discontinued ones. No, I'm talking like all the awesome Sid Meier games that Loki ported, for example (well, *I* liked them). Remember Descent? IIRC, Descent 4 played natively on gnu/linux. That series was discontinued! Remember Tribes 2? Tribes: Vengeance *can't* be ported because of the physics engine they chose to use. I played America's Army for a while, and icculus has to let go of that one because the U.S. army is discontinuing the gnu/linux version (I thought it was pretty cool, others may not). Of course I love free games, but to me, the richness and depth of a game that has had thousands of hours of work put into it with professional animators, tileset artists, professional voice-actors etc., is worth paying for. Neverwinter Nights is a great example of that.
Anyway, my point is that as far as gnu/linux gaming goes, I'm not terribly difficult to please... for example, NWN is a fantastic game and I still play it, even though the aurora toolset was not ported natively by BioWare, and even though we had to install from a windows install initially (then, from a humongous download of the client resources, and then *finally* from zip archives in the platinum edition, or the nice Tuxgames installer with HotU, IIRC), and even though we had to wait a really long time for those bastards at radgametools to give us a bink video player so we could patch in the cut-scenes (which you can do with a community-written perl script! It's awesome, they play right between the chapter transitions like they are supposed to). As long as the game plays natively, and is complete (meaning that you can install it, expect patch releases fairly closely to Win32/Mac patches, and can play *all* the features & levels), then I'm reasonably happy.
I don't want to install cedega. I don't want a transgaming subscription. I don't want emulation or API-reimplementation or play within a virtual machine. And dang it, I want to buy a box with a penguin printed on it somewhere, *not* the windows version (with gnu/linux client binaries bundled). I want my purchase to be counted as it is. Tuxgames has been pretty good to me so far, but they can only distribute what is produced.
I'm sorry if what I said sounded like FUD, but in comparison to the Loki days, we certainly don't get a wide variety of the latest and most popular releases. Perhaps that is not such a bad thing, considering the steady flow of crap being pushed into the market, but Loki really picked some gems. Those were, without exception, the golden days of gnu/linux gaming.
That's a stupid excuse, though. They could always isolate the SGI-laden parts, LGPL the rest, and let the community at least have a fighting chance at replacing what's behind the proprietary API's. I'm not claiming that our homebrew routines would *ever* be better, but I suppose it is within the realm of possibility. Oh, and when I say "always", I do really mean *always*... at any point, even right this minute, they could do so.
The non-licensed parts of the code don't have to compile to be released. Besides, when bugs are traced back into the dark proprietary code, that would also make ATI the good guys and SGI the bad guys. ATI could claim that the licensed part is really fast and awesome and sweet, but proprietary, and that the community is welcome to try and replace it with something fast and awesome and
sweet, but open. Or even something slow and crappy, but rock-solid stable, that plays nice with Xorg and the kernel.
I suppose they might have licensed other companies code and signed away their right to ever release any code they ever write that uses the licensed bits. That would be a collosal blunder, but would partially account for silence on the subject.
I'm fairly certain that the real reason lies not the code ATI has licensed, but the code/tech they've worked hard on and feel they need to keep secret or else lose their edge against nVidia. Of course, it seems that same statement could be made, swapping the names of the two companies, and still be true. In fact, the "trade secret" and "intellectual property" argument is almost certainly the biggest reason for closed-source driver code. Besides, how can a company who is losing money afford to give anything away for free? At least it always seems like the investors and board of directors of tech companies seem to believe that they are perpetually bleeding cash, even when they file record profits with the SEC.
Anyway, that's quite enough ranting and unsubstantiated libel for one post.
Easy! Fairbanks, Alaska is north of North Pole, Alaska... and a much cooler town, btw. Duhh!!
I personally try very hard to only run GPL'ed, natively-compiled applications, and to contribute back to as many as I have to skills to help. This, I think, is part of being a good neighbor.
However, in the interest of helping a new convert stay on the side of the light, if you ever miss the popular windows games, you should consider Cedega from TransGaming. Several guys here in my office run it on their Gentoo or Debian boxes (so it'll probably work on Ubuntu also), and play World of Warcraft and Battlefield 2, etc. It's good to have a beefy machine, but it's more important to have a nice graphics adaptor (my buddies here have NVidia cards).
Anyway, I hate to sound like an advertisement for them, since I think that projects like Cedega and NDIS are generally bad for FOSS in the long run. After seeing how happy some of my friends are to be able to play certain games on their GNU/Linux laptops, some over (mostly) functioning wireless LAN connections via NDIS wrapper, I have to admit that they are generally good for GNU/Linux in the short term.
Also, keep in mind that if (when) you have money to buy your shiny new Mac OS box, you can also put Ubuntu on there as well, and switch handily between them (simultaneously, I believe). That will give you an easy migration path from your old box without having to abandon any of your new L33t Ubuntu skills.
Not buggy any more, still fugly oldness though. I do run WindowMaker with some personalizations, though, and get some of that OpenStep goodness.
Yeah! And Neverwinter Nights! And Return to Castle Wolfenstein! And Tribes 2! And UT! And Quake! And Frozen Bubble! Too bad so many of the professionally produced ones are unavailable or discontinued now... for a time, it was good.
Hey, if space coke worked for Cheech & Chong, why not?
Nope, looks like they are checking the referrer, and offering the print version to not-Slashdot.
c leid=847
Copy-paste the parent's URL, which is
http://www.hothardware.com/printarticle.aspx?arti
(don't mod me up, and for God's sake, don't mod me down either! karma bonus relinquished as ritual sacrifice for good will...)