In terms of technology, obviously there is VideoLAN client combined with any one of the embedded (or secondary file) subtitle formats. The real issue is transcription for the subtitles. Transana is a project that can be used to help transcribe audio and video, but there is still the issue with needing people to actually do the transcription.
I knew a girl that had younger siblings whose favorite passtime was dumping juice into the keyboard. Or at least that is what she claimed. She would take the juicy keyboard, hose it down in the shower, then let it dry in front of a fan overnight.
From what I understand, she did it more than a dozen times by the time I heard about it. If it works, it works.
Having written MPI and Linda work-alike libraries, developed parallel and distributed systems, and being a heavy user of threads and remote procedure calls (via xml-rpc), I will say that the general issue that all of these different systems try to handle is one of API. How does one have data X handled by function Y in thread/process Z. In the realm of threading, we use queues with locks. MPI/PVM/Linda/XML-RPC all use sockets to pass data between processes, and all but Linda requires that you specify the destination process explicitly.
One interesting recent development is the processing package for Python: http://www.python.org/pypi/processing/ . The idea is that you create processes like you would threads, then use shared queues, key-value mappings, etc., to pass data between the processes like you would threads. By sticking with generalizations that are seen to be 'easy' to understand and use (primarily queues), they bypass the majority of the difficulty people have when using threads and processes. Of course it doesn't hurt that the data transfer is pretty fast.
The only limiting factors with the particular implementation is that it relies on fork in *nix, and the transfer of code as data in Windows (which isn't generally possible for all languages, especially with the NX processor extension). If Windows had a usable fork, and if there was a 'fork across machines' (think mosix), many of these discussions would result in "just program it like you had a thread and use shared queues and the processing package for your language".
Some movie theaters have considered shielding theaters from any/all cell phone signals (not actively jamming, just lining them with shielding). If I remember correctly, it had questionable legality because doctors who are on call typically pack cell phones or pagers. If jamming phones (in the case of on-call doctors) is questionably legal in a movie theater, I can't imagine it *not* being of questionable legality to do the same in a stadium.
If there was a hospital nearby, and it was affected by the jamming, I can't see how that *wouldn't* be illegal, regardless of the above.
Official versions of VNC from AT&T and later RealVNC had similar password limitations, though I can't remember if it was 7 or 8 characters. All I know is that it gave me a good reason to switch to UltraVNC, which used the native login API on whatever OS it was running.
However, while earlier versions used only web browser User-Agent checks, recent CCA Server software uses TCP/IP fingerprinting techniques to be more or less impervious to simple browser-based bypasses; though any emulated OSes that can gain network access are sufficient, or the software that I pointed out (which changes Windows TCP/IP settings, uses OpenSSL, and spoofs a browser).
I've talked about much of this before on my own web page, as my university (UC Irvine) has installed the Cisco product, I (and others) have spoken out against it, and have been accused of policy violations under similar "rules". Of course three graduate students in three different computer science disciplines (different department chairs) have a better chance against a (clueless) administrator than the undergrad listed in this story. Joe Feise talks about this: http://www.feise.com/~jfeise/blogs/ As do I on my blog: http://chouyu-31.livejournal.com/243263.html and on a web page devoted to this kind of bullshit: https://nerp.net/~jcarlson/cca_.html
If the kid would have gone to a UC, he would be able to submit a public records act request for records of every email sent between those that were working on his case. He could verify his suspicions that the people who ultimately decided were overly influenced by the admin, etc. Of course, had they spoken with him before throwing the book at him, they may have been able to get their desired result (the student not using or distributing the software) without needing to suspend him and put his university funding in jeopardy.
The software he was using merely allowed him to access the network and internet from his own computer. If his computer became compromised, it would be his computer that was compromised, not the entire network. This is about client-level security and verifying that (Windows) clients are patched, have virus scanners, etc.
Also note that there exists a piece of open-source software that offers the same access that the the student wrote, has already been reported to Cisco, and is available as a binary for Windows computers: http://kevin.sourceforge.net/
With simple recipes available that offer an implementation of DNS: http://aspn.activestate.com/ASPN/Cookbook/Python/R ecipe/491264 one could easily plug it into any one of a number of databases. Add a very simple HTTP front end for updating name/IP information in the database, and you are done.
It's not about ideal, it's about getting your job done. Whether or not you can convince the higher ups that you need a Unix machine to do your Unix administration job is your own business, but I'd wager may be an exercise in futility. Me, I'd just install my favorite flavor of *nix, install Windows on VMWare (or VirtualBox or Bochs or Plex86), and get on with doing my job. I've personally found Windows to emulate pretty well (at least win2k or XP without Luna).
Do whatever is standard for your organization when you decide not to hire someone. Doing anything else, from throwing their resume in the trash the next day to telling them that they should brush up on skill X, could be seen as litigation fodder.
Also, don't post on slashdot about it, he may be incompetent, but he may still read slashdot.
Same publisher for both Kotors (according to wikipedia), but I couldn't tell you why Lucasarts pushed them that much. I believe they were originally supposed to have another 5+ months (for an 18+ month dev cycle), but maybe the idea of releasing KOTOR 2 6 months prior to the release of Revenge of the Sith, as more or less a free advertising campaign for the movie was too lucrative to pass up.
As for NWN and NWN 2, Bioware had Infogrames to deal with, which later bought out Hasbro interactive (they own Atari and WoTC). They used their Atari branch and management (likely for the name recognition and that they had worked with WoTC before), but by the time Obsidian got the contract for NWN 2, Atari was having some financial difficulties (could still be); which certainly didn't get any better over the course of NWN 2 development. I would also guess that they wanted NWN 2 to come out ASAP because NWN 1 was looking a bit long in the tooth.
Bioware had at least 3 1/2 years for KOTOR 1, including pre-production (http://www.bioware.com/bioware_info/press_release s/SWProject/SWProject.htm and was released November 2003). Obsidian had about 13 months for KOTOR 2, including preproduction (http://en.wikipedia.org/wiki/KOTOR_2).
Bioware had 5 years for NWN, including preproduction (http://www.gamasutra.com/features/20021204/greig_ 02.htm). Obsidian had a little over 2 years for NWN2, including preproduction.
Go ahead, please tell me how Bioware did such a better job making games with 2-3 times as much time.
Zelda has been using the same playing style since the first game. You can't be serious. Zelda 1 and Zelda 2 were significantly different, so different that the experience-based Zelda 2 does not seem to have been revisited since. Zelda 3 harked back to Zelda 1, and those who liked #1 but didn't like #2 enjoyed #3. When Zelda hit 3D with Ocarina, Majora's Mask, etc., the format switched again.
According to my count, thats at least 3 distinct "playing styles" (unless you count Majora's Mask replaying another, or even Twilight Princess' Wiimote interface different).
Obsidian had 13 months to develop KOTOR2, which is 5 months shy of what Lucasarts has just said they like to give people, and from what I understand, significantly shorter than what they were originally told would be available. Also, patches aren't developed out of the goodness of developers' hearts, the money to develop the patches has to come from somewhere (publishers), and if they (publishers) refuse to pay (not uncommon), patches won't be made.
I would also mention that KOTOR2 (among other games) that are released for both console and PC are in a strange situation where one can be patched (to fix bugs, add content, etc.) where the other one may not be practical to do so, and things like "consistency of play" may be more important than a "perfect" game.
Due to a crashed browser and little patience from me, this post is far shorter than it was, but I'll sum it up with: XRC. Specifically the XML-based GUI markup that can handle widget layout in wxWidgets (wxPython, wxRuby, wxPerl, etc.).
There already exists applications that distribute updated/dynamic layouts, behavior (in Python), and state, all from a database, all using XML-RPC. I haven't messed around with XML-RPC in other languages, but if you haven't used XML-RPC in Python, you are missing something. It's a bit slower than some other TCP/IP-enabled RPC mechanisms, but in Python it's a breeze to set up. See http://aspn.activestate.com/ASPN/Cookbook/Python/R ecipe/81549 for an example recipe that offers both client and servers, with comments including a threaded and forking server.
Is it the future? Maybe. I like using it today. Makes my time more productive.
There are three parts to developing a GUI application; widget layout, widget behavior, and state persistence (view, controller, model if you want to think of it like that). Right now, people are dealing with HTML (or XHTML or XML), Javascript, and XML for those things.
What's better? Some people have come to like the flavor of XRC from the wx world, wxPython coming with a fairly decent GUI designer called XRCed that produces XRC as output. That handles widget layout. From there, you can use basically whatever language you want to handle behavior, and one can stick with XML or a database as persistent state.
There are already applications being used and developed right now using Python and wxPython that distribute XRC GUI components, Python behavior, with data all from a live database, transferred over XML-RPC. I haven't spent much time digging into the AJAX stuff, but from what I have seen, even pure wxPython is far nicer to read and write. With XRC handling layout and Python handling behavior, it would be difficult to find a significantly better "dynamic application platform".
Toss in the fact that you can actually embed XRC into HTML when using the wx browser, and one can write rich applications right into web pages, or even full on applications by themselves.
"Even if the original developer stopped working on it, somebody should have been able to pick it up and maintain it easily, and the fact that this didn't happen is proof again that python is barring its own progress."
No, it didn't get picked up and maintained because no one cared enough about the application to pick it up and maintain it. By your argument, no programming languages are possible "to maintain forward" because there are good applications written in all languages that get dropped because the main developer(s) moved on. In this particular case (PySol), if you read the web page, the author was in the middle of a GUI toolkit change (to wxPython), and was stopped mid conversion to deal with other things.
Now, as someone who uses Python on a daily basis, I've found that the vast majority of code I wrote for 1.5.2 (way back in 1999) still works today with Python 2.5. The few things that don't run unchanged generally require only minor modifications. Those that do require nontrivial modifications generally relied on underlying implementation assumptions that were not outlined in the language reference, and it was my own damn fault for relying on the functionality.
Slashdot Mirror
In terms of technology, obviously there is VideoLAN client combined with any one of the embedded (or secondary file) subtitle formats. The real issue is transcription for the subtitles. Transana is a project that can be used to help transcribe audio and video, but there is still the issue with needing people to actually do the transcription.
Yeah, I just haven't ever had the problem. I'm apparently not clumsy enough.
I knew a girl that had younger siblings whose favorite passtime was dumping juice into the keyboard. Or at least that is what she claimed. She would take the juicy keyboard, hose it down in the shower, then let it dry in front of a fan overnight.
From what I understand, she did it more than a dozen times by the time I heard about it. If it works, it works.
Having written MPI and Linda work-alike libraries, developed parallel and distributed systems, and being a heavy user of threads and remote procedure calls (via xml-rpc), I will say that the general issue that all of these different systems try to handle is one of API. How does one have data X handled by function Y in thread/process Z. In the realm of threading, we use queues with locks. MPI/PVM/Linda/XML-RPC all use sockets to pass data between processes, and all but Linda requires that you specify the destination process explicitly.
One interesting recent development is the processing package for Python: http://www.python.org/pypi/processing/ . The idea is that you create processes like you would threads, then use shared queues, key-value mappings, etc., to pass data between the processes like you would threads. By sticking with generalizations that are seen to be 'easy' to understand and use (primarily queues), they bypass the majority of the difficulty people have when using threads and processes. Of course it doesn't hurt that the data transfer is pretty fast.
The only limiting factors with the particular implementation is that it relies on fork in *nix, and the transfer of code as data in Windows (which isn't generally possible for all languages, especially with the NX processor extension). If Windows had a usable fork, and if there was a 'fork across machines' (think mosix), many of these discussions would result in "just program it like you had a thread and use shared queues and the processing package for your language".
Some movie theaters have considered shielding theaters from any/all cell phone signals (not actively jamming, just lining them with shielding). If I remember correctly, it had questionable legality because doctors who are on call typically pack cell phones or pagers. If jamming phones (in the case of on-call doctors) is questionably legal in a movie theater, I can't imagine it *not* being of questionable legality to do the same in a stadium.
If there was a hospital nearby, and it was affected by the jamming, I can't see how that *wouldn't* be illegal, regardless of the above.
Official versions of VNC from AT&T and later RealVNC had similar password limitations, though I can't remember if it was 7 or 8 characters. All I know is that it gave me a good reason to switch to UltraVNC, which used the native login API on whatever OS it was running.
You are pretty much right.
However, while earlier versions used only web browser User-Agent checks, recent CCA Server software uses TCP/IP fingerprinting techniques to be more or less impervious to simple browser-based bypasses; though any emulated OSes that can gain network access are sufficient, or the software that I pointed out (which changes Windows TCP/IP settings, uses OpenSSL, and spoofs a browser).
I've talked about much of this before on my own web page, as my university (UC Irvine) has installed the Cisco product, I (and others) have spoken out against it, and have been accused of policy violations under similar "rules". Of course three graduate students in three different computer science disciplines (different department chairs) have a better chance against a (clueless) administrator than the undergrad listed in this story. Joe Feise talks about this: http://www.feise.com/~jfeise/blogs/ As do I on my blog: http://chouyu-31.livejournal.com/243263.html and on a web page devoted to this kind of bullshit: https://nerp.net/~jcarlson/cca_.html
If the kid would have gone to a UC, he would be able to submit a public records act request for records of every email sent between those that were working on his case. He could verify his suspicions that the people who ultimately decided were overly influenced by the admin, etc. Of course, had they spoken with him before throwing the book at him, they may have been able to get their desired result (the student not using or distributing the software) without needing to suspend him and put his university funding in jeopardy.
http://kevin.sourceforge.net/
The software he was using merely allowed him to access the network and internet from his own computer. If his computer became compromised, it would be his computer that was compromised, not the entire network. This is about client-level security and verifying that (Windows) clients are patched, have virus scanners, etc.
Also note that there exists a piece of open-source software that offers the same access that the the student wrote, has already been reported to Cisco, and is available as a binary for Windows computers: http://kevin.sourceforge.net/
With simple recipes available that offer an implementation of DNS: http://aspn.activestate.com/ASPN/Cookbook/Python/R ecipe/491264 one could easily plug it into any one of a number of databases. Add a very simple HTTP front end for updating name/IP information in the database, and you are done.
"it is a proven statistic that the vast majority of children playing violent video games or watching violent movies act out scenes from within them"
Care to cite the studies that corroborate your claim?
It's not about ideal, it's about getting your job done. Whether or not you can convince the higher ups that you need a Unix machine to do your Unix administration job is your own business, but I'd wager may be an exercise in futility. Me, I'd just install my favorite flavor of *nix, install Windows on VMWare (or VirtualBox or Bochs or Plex86), and get on with doing my job. I've personally found Windows to emulate pretty well (at least win2k or XP without Luna).
Do whatever is standard for your organization when you decide not to hire someone. Doing anything else, from throwing their resume in the trash the next day to telling them that they should brush up on skill X, could be seen as litigation fodder.
Also, don't post on slashdot about it, he may be incompetent, but he may still read slashdot.
Same publisher for both Kotors (according to wikipedia), but I couldn't tell you why Lucasarts pushed them that much. I believe they were originally supposed to have another 5+ months (for an 18+ month dev cycle), but maybe the idea of releasing KOTOR 2 6 months prior to the release of Revenge of the Sith, as more or less a free advertising campaign for the movie was too lucrative to pass up.
As for NWN and NWN 2, Bioware had Infogrames to deal with, which later bought out Hasbro interactive (they own Atari and WoTC). They used their Atari branch and management (likely for the name recognition and that they had worked with WoTC before), but by the time Obsidian got the contract for NWN 2, Atari was having some financial difficulties (could still be); which certainly didn't get any better over the course of NWN 2 development. I would also guess that they wanted NWN 2 to come out ASAP because NWN 1 was looking a bit long in the tooth.
Define "us".
Bioware had at least 3 1/2 years for KOTOR 1, including pre-production (http://www.bioware.com/bioware_info/press_release s/SWProject/SWProject.htm and was released November 2003).
_ 02.htm).
Obsidian had about 13 months for KOTOR 2, including preproduction (http://en.wikipedia.org/wiki/KOTOR_2).
Bioware had 5 years for NWN, including preproduction (http://www.gamasutra.com/features/20021204/greig
Obsidian had a little over 2 years for NWN2, including preproduction.
Go ahead, please tell me how Bioware did such a better job making games with 2-3 times as much time.
According to my count, thats at least 3 distinct "playing styles" (unless you count Majora's Mask replaying another, or even Twilight Princess' Wiimote interface different).
Make that "approximately 13 months". Want a reference? Gamespot has a "Developer Interview".
Obsidian had 13 months to develop KOTOR2, which is 5 months shy of what Lucasarts has just said they like to give people, and from what I understand, significantly shorter than what they were originally told would be available. Also, patches aren't developed out of the goodness of developers' hearts, the money to develop the patches has to come from somewhere (publishers), and if they (publishers) refuse to pay (not uncommon), patches won't be made.
I would also mention that KOTOR2 (among other games) that are released for both console and PC are in a strange situation where one can be patched (to fix bugs, add content, etc.) where the other one may not be practical to do so, and things like "consistency of play" may be more important than a "perfect" game.
Due to a crashed browser and little patience from me, this post is far shorter than it was, but I'll sum it up with: XRC. Specifically the XML-based GUI markup that can handle widget layout in wxWidgets (wxPython, wxRuby, wxPerl, etc.).
R ecipe/81549 for an example recipe that offers both client and servers, with comments including a threaded and forking server.
There already exists applications that distribute updated/dynamic layouts, behavior (in Python), and state, all from a database, all using XML-RPC. I haven't messed around with XML-RPC in other languages, but if you haven't used XML-RPC in Python, you are missing something. It's a bit slower than some other TCP/IP-enabled RPC mechanisms, but in Python it's a breeze to set up. See http://aspn.activestate.com/ASPN/Cookbook/Python/
Is it the future? Maybe. I like using it today. Makes my time more productive.
There are three parts to developing a GUI application; widget layout, widget behavior, and state persistence (view, controller, model if you want to think of it like that). Right now, people are dealing with HTML (or XHTML or XML), Javascript, and XML for those things.
What's better? Some people have come to like the flavor of XRC from the wx world, wxPython coming with a fairly decent GUI designer called XRCed that produces XRC as output. That handles widget layout. From there, you can use basically whatever language you want to handle behavior, and one can stick with XML or a database as persistent state.
There are already applications being used and developed right now using Python and wxPython that distribute XRC GUI components, Python behavior, with data all from a live database, transferred over XML-RPC. I haven't spent much time digging into the AJAX stuff, but from what I have seen, even pure wxPython is far nicer to read and write. With XRC handling layout and Python handling behavior, it would be difficult to find a significantly better "dynamic application platform".
Toss in the fact that you can actually embed XRC into HTML when using the wx browser, and one can write rich applications right into web pages, or even full on applications by themselves.
"Even if the original developer stopped working on it, somebody should have been able to pick it up and maintain it easily, and the fact that this didn't happen is proof again that python is barring its own progress."
No, it didn't get picked up and maintained because no one cared enough about the application to pick it up and maintain it. By your argument, no programming languages are possible "to maintain forward" because there are good applications written in all languages that get dropped because the main developer(s) moved on. In this particular case (PySol), if you read the web page, the author was in the middle of a GUI toolkit change (to wxPython), and was stopped mid conversion to deal with other things.
Now, as someone who uses Python on a daily basis, I've found that the vast majority of code I wrote for 1.5.2 (way back in 1999) still works today with Python 2.5. The few things that don't run unchanged generally require only minor modifications. Those that do require nontrivial modifications generally relied on underlying implementation assumptions that were not outlined in the language reference, and it was my own damn fault for relying on the functionality.
Wow, eighteenth century. That may be the winner.
And even Andy Kaufman wasn't original! Awesome. Now, can we just get past this whole lawsuit thing?
He has stated on various occasions that he is mocking the United States.