Agreed. The book's premise sounds somewhat similar to a book that was published here in Finland, "Skandaali!: Historian parhaat lööpit" ("Scandal!: The greatest headlines of the history"), by Anu Lahtinen and Mika Lietzén - a historian and an illustrator, respectively. It had imaginary news paper front pages from 35,000 BCE (around which humans arrived to Europe) to circa 1800 CE (around which people started to actually publish scandal-pushing headlines routinely). It was both hilarious and educational: a historian's view on stuff that happened back in the day and shocked people, and fun parody front pages to go with them.
So if there was a book like this and it was interestingly done, sure, why not, I'd probably read it too.
One small beef though: Most steganography/watermarking I've seen focuses on the artist using the software to add a hidden mark in the image, and then verifying that the hidden mark also exists in an alleged rip-off.
It says nothing about entity doing metadata cataloguing automatically extracting the marks and putting the decoded marks in an easy-to-query database. You know, making the data searchable. Even if that's data that is supposed to be hidden, you know, to ward against this "watermark tampering" thing that's listed in Image Plagiarism for Dummies, page 3.
Now, what makes you think that steganography/watermarking vendors would willingly share the methods they use to hide the marks?
Further, the history has shown that both steganography and watermarking markets are full of products that are utter and pure snake oil. Telling apart the real thing and snake oil is sometimes difficult in computer security in general, and on this field in particular. The products that are being used might not lend themselves to be accurate detection to begin with...
Since the Q3 engine was open-sourced, do they have the right to make a new closed-source client? After viewing these videos, it appears it's quite far from the "new, enhanced quake 3" we were told about: except for the new maps and the chaingun, I cant see any of the new things that are already included in many FOSS ports: blend mapping, bloom, blurring, dynamic lighting,...
As others have said, id is the copyright holder of the original Q3A code, so they can do whatever the heck they want with it. However, the big thing to remember is that, by default, you have the copyright to your code: If you contribute to a Q3A-based OSS project, you retain the copyright, it doesn't get transferred to id unless there's a specific contract. Therefore, id can't use, without permission, the stuff that has appeared in other Q3A-based projects. They'd have to either negotiate a permission from the authors to include the code in a their closed tree, or reimplement the features themselves.
Therefore, as the engine appears to be almost untouched, what happens if someone makes a rip-off open-source client?
The only thing id can do to prevent that eventuality is to use EULAs or technical measures. After all, it's their servers.
Is this another one of those "LGPL-like" variants of the GPLv2?
Basically, as I understood it, Classpath exception is "Running in the JVM isn't considered linking as GPL defines the term". If you went by the strict letter of GPL, the GPL would require all classes running in the same VM to be under GPL-compatible license. It's necessary to do it this way, because in JVM there's little technical difference in linking a library and running a class, and running separate JVMs for GPL and non-GPL-compatible classes is just silly.
I've only pirated games these days if I absolutely want them but I absolutely can't get them from local retailers. And before anyone worries, I usually do that only for some really good reason. If the opportunity arises, I buy the game.
A recent example was Final Fantasy VI: I played the SNES ROM. None of the retailers here had the PS1 version (though they did carry FF7, 8 and 9). I bought the GBA version at the earliest opportunity soon after it was released here - and I've been quite happy, thank you for asking.
It's usually the older games that are almost slipping in the abandonware territory already anyway. If the publishers want to combat this, they should elevate the shovelware CD collections to a new era, or make the old games legit freeware. Perhaps make buying old games easier online (I can't do Steam - no credit card and my debit card can only be used nationally). Hey, I'd sure as heck buy a giant collection of DOS games on a DVD-ROM if the price was right... Not long ago I bought a collection of D&D RPGs for 40€ and I suppose everyone agrees it's a steal for 8 games and 5 expansion disks =)
Actually, the code displayed in the original Terminator movie was IBM 370 assembler language. Mainframe Arnold wouldn't settle for being a micro anything.
Actually, I remember it having both a listing in what definitely did look like 6502 assembly listing... and some code in another language, which might have been the IBM one. Terminator code definitely wasn't all 6502 code, just a jumble of various other listings. Haven't seen the film in a while so I can't say for sure...
I then tried making a webpage included the type attribute, specifiying "xml/xml+svg". The web browsers continued to display the XML text.
Which is pretty logical, considering the correct MIME type for.svg files is "image/svg+xml". "xml/" isn't (last I checked) a valid prefix at all, and XML-based formats have "+xml" in the end of the latter part, not the beginning!
The MIME types of various XML-based formats are a pretty complex issue; some ill-defined formats (*cough* some OPML hacks) may need to be served as deprecated "text/xml", some as "application/xml", and then there's various text|application|image/*+xml types.
PS, FYI, I ultimately got the SVG file to be displayed correctly by re-uploading it as an XML file. The server then sent "Content-type: xml/xml" and the web browsers figured out what to do with it.
Well, isn't that bad voodoo? One would assume that the correct behaviour when encountering "some random XML stuff" would be to display the file as XML, again, and not make weird assumptions...
I run Womencoder. It's nicer to look at, but verbose mode usually produces too much irrelevant nonsense. </snark>
Ah! Now I know why I'm having so much problems converting videos with mencoder. I used to create tons of videos that don't necessarily have the right quality settings and/or don't play correctly, but now it turns out I need to read the manual! *shivers* </snark>
Ah, the cleverness of the hack in question is not that they can make the coffee maker to produce coffee, no. The evil hax0rs really want the coffee.
Employee 1: "This has to be the most ridiculous work order I've ever received."
Employee 2: "What is it?"
E1: "At precisely 12:02, I'm supposed to take the cup from the coffee percolator and deliver it to this address a few blocks away."
E2: "What? Are you kidding?"
E1: "No, it's on our company letterhead. Signed by the CEO. 'Deliver this cup of coffee to our IT subcontractor. This may sound like an unusual order, but millions are at stake here.'"
E2: "Well, I wonder what those primadonnas come up with next time?"
Last I checked it wasn't possible to get it to work with recent versions of glibc.
Not long ago, folks here happened to point me toward loki_compat_libs. Lo! LD_PRELOADing ye olde libstdc++, smpeg and SDL seems to make the game work perfectly, at least for me. And there were many nervestaplings once more. =)
I would have nominated Sid Meier's Alpha Centauri but that one broke many a kernal ago on a glibc update. Too bad Loki is dead or they could have updated it.
Funny, I actually got SMAC to work on a reasonably new setup; the updater blew up (I had to patch the game manually by extracting the update and patching the files individually with xdelta), fullscreen mode doesn't work (weird video mode), and apparently I'd need to disable compositing to make it not crash when the actual game play begins, which I'm too lazy to do...
We needs a new build or at least a competent clone! SMAC rules!
I think there's a small problem of distribution. Linux-only games won't sell. However, Windows games do sell, and if there's Linux binaries available, all the better.
Of the games on the list, I have NWN, Quake 3, 4 and Doom 3... NWN, Doom 3 and Q4 on the virtue of buying the Windows version and downloading the free binary, Q3A because luckily there actually was a local book shop that had Linux games (I also bought Myth II from them, and ordered SMAC from another store). Loki was a great company, too bad they didn't quite have the distribution figured out to the same extent as other game companies.
Currently, I don't see many other viable modes of distribution for Linux games other than either a) Sell Windows games and let people download Linux binaries on their own or b) supply Linux binaries inconspicuously on the CD. Linux-only packages are murder.
...a very good reason to actually remember someone else's birthdays, no? The System Automatically Hates Your Guts if you forgot. =)
...Enter the number of presidents running for office ...Enter the number of presidents in office.
Great, more culture-dependant CAPTCHAs.
I don't have the exact quote at hand, but to paraphrase Markus Kajo: "If I wanted to interrogate and expose foreign spies, I wouldn't ask them questions like 'who was the 5th President of Finland'. Most of the Finns wouldn't know that either! I'd ask them to make an omelet - if they just make you one without complaints, then they're obviously spies, because they weren't told that in Finland, you have to always apologise for your own cooking: 'I'm sorry it's a bit burnt on the edges...'"
Ruby is weakly typed, and dynamically typed, which means, as a programmer, you have a huge amount of freedom in what you can feed into a variable. It also means that you can effectively give it any input maliciously, and it will try and do something with it instead of rejecting it.
BZZZZT-ish. You're on the right track, but the logical conclusion isn't exactly thrill-worthy.
Yes, in dynamic system, you can stuff an arbitrary value in an arbitrary variable, but that value has to come from somewhere. Surprise surprise, return values of methods that process user input can be alarmingly well understood.
For example, the spec says gets method in Kernel will return a String (or a nil in case of EOF), and it will most definitely not return an automagically parsed number or, say, a Date object... or EvilHackerSystemExploderObject! (Unless your platform is 0wned - but if an attacker can run arbitrary code, you have bigger problems than type safety...)
No matter what the language we're dealing with, the programmer has to understand exactly what the functions return. I've seen plenty of uncaught NullPointerExceptions in perfectly ordinary Java programs to be convinced that static typing won't save you from knowing thy damne API. =)
Secondly, which moron in Microsoft would allow 'root' level programs to run 'before' the user has logged in as root? Pretty dumb, it seems to me. Maybe they did it on purpose?
A bit of a chicken-and-an-egg problem here: How do you propose you authenticate users without a) running the authenticating program as root, having privileges to say "okay, you're user X, let me shift the control over to you", or b) being just as exploitable by giving limited user Y the privilege of saying "okay, you're user X, let me shift the control over to you"?
A better question would be to ask, "why is the login application executing random programs anyway?" or, like you said, "why isn't the login application making sure that, when it executes a random program, it actually executes the program it was supposed to execute?" but I suppose the answer to these questions is simple: "sometimes the flexibility is warranted" and "this is getting way too elaborate, giving minimal gains in actual real security" - in short, if you want to make sure utilman.exe isn't messed around with before the boot, the more feasible and elegant solution is to use full-drive encryption (which solves far more problems at one single swat), not mess around with micro-granular annoyances.
How can a community edited work be published under by-nc-ND?
With the permission from the community in question. You need to make distinction between creators of the work and the public that uses and distributes the work. One would assume that if they get contributors aboard, each of them will understand what they're going to do with the work, right?
Star Wreck: In the Pirkinning was released under BY-NC-ND, and was definitely a "community work" in every sense of the expression. It's also sold on DVD, for profit - by the creators. -NC just means you aren't allowed to make a copy and then sell it yourself.
Indeed! Our tests have shown that SSDS is very capable indeed, for various definitions of "capable", "very" and "indeed". SSDS excels in Obtuse Search Syntax, Not Parsing the Content, and Extending the Joke Way Beyond Snapping Point. But we all love it anyway over at thedailywtf!
RealPlayer - Avoiding RealPlayer like the plague it is (using "Amarok" for the same functionality, if not the same file format). Result? No privacy leaks, no ads, no reporting back to Real on what I listen to or where I visit on the web.
Java - Using Sun's Java without the Yahoo toolbar. Result? Java is reasonably well behaved. Looking forward to truly open-sourced Java in the near future.
Actually, the funny thing about these two pieces of software is that the Windows versions foist unbelievable amount of crap on you, but the Linux versions are actually pretty good.
Linux RealPlayer / HelixPlayer is pretty minimal, and has absolutely none of the crap you get in Windows. If we didn't already have the more featureful VLC Player, RP would probably be a contender, now I just use it to play RealMedia stuff (which isn't very often, surprise surprise). Likewise, Sun Java 1.6 is the best damn Java environment I've ever used and doesn't have any extra bundles of junk - it's even included in Debian repositories now. Yes, Sun Java 1.7 will probably rule.
(And while I use Amarok too, I use VLC for the tasks people would usually use RP for - there's a difference between the use cases of "just play something off the library" and "just play this random file I have here". No need to fluff last.fm profile with random garbage, for example. =)
So does this mean that if you are using magic quotes and you upgrade to PHP6, suddenly you will become vulnerable to SQL injection attack?
"The Management would like to announce that we're switching to slot-loading CD-ROM drives next week. We will be reserving more burn ointments in the first aid room for the next week or so and the janitor has been instructed to stock extra tissues in the bathrooms, but people who have been using CD-ROM drives as coffee cup holders should seriously stop using them as coffee cup holders ASAP."
Magic quotes did the wrong fix that incidentally happened to work for some people. The problem was that people had been concatenating (unprocessed) parameters to SQL queries; the right solution would have been to process the quoting in the place where it's supposed to be processed (query parametrisation, right before the query actually goes to the DB, automagically using the method that works appropriately for the DBMS in question), but instead, the developers just said "well, we're letting you continue your dangerous way of coding, here's a band-aid fix".
I've viewed magic quotes as a feature for legacy code that seriously needs to be fixed: "people used to code completely freaking headlessly back in the day because we didn't have real security back then and this was the ONLY way to do things - this feature is a temporary security feature so that they have time to port their utterly reeking PHP3-era string concatenation crap to use DB-specific quote calls or, far better yet, PDO and prepared statements." Using prepared statements makes the code look more manageable and more in line with the stuff you see in other programming languages, which have used prepared statements for a long time now - porting old code over is more than entirely justifiable.
I'd love to pitch in with the coding, but I sadly cannot afford the time and energy required to dig through OOo's extraordinarily convoluted API documentation to figure out how to update the source code myself; I started the process, but gave up in disgust at how the docs are organized.
Wow, you actually found documentation? I tried writing an OO.o macro once. I have almost gotten back my sanity now. =)
But anyway, there's one part where OO.o differs from Word: Documents are not coupled to the application. You don't have to use OO.o to process OpenDocument.
Theoretically, it'd not be that difficult to whip up an external application that does various word count methods - after all, there's several word count methods for English too! (Some divide character count by six, some pick a page from the middle of the manuscript, multiply lines by average line length, then multiply by number of pages in manuscript, etc, etc...)
I've written a word count tool for my own use for LaTeX text myself in 15 minutes... and there's a bunch of libraries for parsing OO.o. How hard can it be? =)
I don't think employee emails constitute IP, and I don't think the characters, places and ideas from Douglas Adams' books are at present considered unprofitable.
Another typical human trait: Getting caught in tiny little details like this and not thinking of the big picture at all. I rest my case. Why should we get terribly caught in little details about licensed properties when - you know - Infocom was best known for their original titles. Source code for the dozens of Infocom titles! Plans for other projects they had been working on! Imagine those possibilities!
As for employee e-mail, I don't think it should be disseminated at whim - but I believe it could be examined by a trusted researcher, with resulting published research focusing strictly on the functions of the company and the game development, not on the private matters of the people involved.
I'll use this in class to point out the importance of good backup strategies.
Yep, it's amazing that the stuff still survives... as compared to source material that has now been lost forever.
I wish Origin had had a Massive Unix Server for source control and whatnot. But they didn't have one.
And security: this data should not have left the company.
Agreed on a general principle - but if the company's IP has long since ceased to be profitable and its material is mostly just of great historical interest, the situation is quite different. It's a typical human reaction - It's easy to say "you can't have this", only thinking at the usual every-day rules, not thinking of the historical significance, condemning a lot of researchers, years hence, to look for scraps of information and hunt for hazy recollections... Yeah, it'd easy to be in Activision's pants and say "Yes, there is a chance this property is profitable and we'll get to making the Hitchhiker sequel eventually" without batting an eye, but let's face it, IF is dead as a commercial art form =)
My experience leads me to believe that almost nobody hates change more than many IT professionals.
IT professionals don't hate change. They hate useless change and unplanned change. And, of course, too frequent change. Whatever isn't broken shouldn't be changed for the sake of the change. If there are actual benefits to the change, it should be performed with care. You don't just change back and forth between different solutions because one of them works on Tuesdays and one works on Fridays - you make the thing work all the time.
And CVS to Subversion change is a very bad example because there's an automated tool (cvs2svn) that does the conversion, the Subversion workflow was specifically designed to mimic CVS workflow, and the "CVS experts" certainly know exactly how much CVS sucks and want the pain to end... they're changing in droves. =)
If you are an active EVE player, don't use the torrent links to download the source. CCP is monitoring the torrents and banning any accounts with matching IP addresses to any of the people using the torrent.
Uh, what? They might as well say "Well, we know vast majority of the people who download the source won't do a damn thing about it, let alone be able to find exploits/look at our sooper sekrit algorithms/whatever. We're just banning people because we're mean and arbitrary and have nothing better to do."
Why are they wasting time on doing things like this? If some dupe-exploitin', gold-auctionin' übermacroer is determined to use the source code for their nefarious purposes, surely spoofing IPs or opening new accounts will be the simplest of things to do, no?
Slashdot Mirror
Agreed. The book's premise sounds somewhat similar to a book that was published here in Finland, "Skandaali!: Historian parhaat lööpit" ("Scandal!: The greatest headlines of the history"), by Anu Lahtinen and Mika Lietzén - a historian and an illustrator, respectively. It had imaginary news paper front pages from 35,000 BCE (around which humans arrived to Europe) to circa 1800 CE (around which people started to actually publish scandal-pushing headlines routinely). It was both hilarious and educational: a historian's view on stuff that happened back in the day and shocked people, and fun parody front pages to go with them.
So if there was a book like this and it was interestingly done, sure, why not, I'd probably read it too.
One small beef though: Most steganography/watermarking I've seen focuses on the artist using the software to add a hidden mark in the image, and then verifying that the hidden mark also exists in an alleged rip-off.
It says nothing about entity doing metadata cataloguing automatically extracting the marks and putting the decoded marks in an easy-to-query database. You know, making the data searchable. Even if that's data that is supposed to be hidden, you know, to ward against this "watermark tampering" thing that's listed in Image Plagiarism for Dummies, page 3.
Now, what makes you think that steganography/watermarking vendors would willingly share the methods they use to hide the marks?
Further, the history has shown that both steganography and watermarking markets are full of products that are utter and pure snake oil. Telling apart the real thing and snake oil is sometimes difficult in computer security in general, and on this field in particular. The products that are being used might not lend themselves to be accurate detection to begin with...
Since the Q3 engine was open-sourced, do they have the right to make a new closed-source client? After viewing these videos, it appears it's quite far from the "new, enhanced quake 3" we were told about: except for the new maps and the chaingun, I cant see any of the new things that are already included in many FOSS ports: blend mapping, bloom, blurring, dynamic lighting,...
As others have said, id is the copyright holder of the original Q3A code, so they can do whatever the heck they want with it. However, the big thing to remember is that, by default, you have the copyright to your code: If you contribute to a Q3A-based OSS project, you retain the copyright, it doesn't get transferred to id unless there's a specific contract. Therefore, id can't use, without permission, the stuff that has appeared in other Q3A-based projects. They'd have to either negotiate a permission from the authors to include the code in a their closed tree, or reimplement the features themselves.
Therefore, as the engine appears to be almost untouched, what happens if someone makes a rip-off open-source client?
The only thing id can do to prevent that eventuality is to use EULAs or technical measures. After all, it's their servers.
Is this another one of those "LGPL-like" variants of the GPLv2?
Basically, as I understood it, Classpath exception is "Running in the JVM isn't considered linking as GPL defines the term". If you went by the strict letter of GPL, the GPL would require all classes running in the same VM to be under GPL-compatible license. It's necessary to do it this way, because in JVM there's little technical difference in linking a library and running a class, and running separate JVMs for GPL and non-GPL-compatible classes is just silly.
I've only pirated games these days if I absolutely want them but I absolutely can't get them from local retailers. And before anyone worries, I usually do that only for some really good reason. If the opportunity arises, I buy the game.
A recent example was Final Fantasy VI: I played the SNES ROM. None of the retailers here had the PS1 version (though they did carry FF7, 8 and 9). I bought the GBA version at the earliest opportunity soon after it was released here - and I've been quite happy, thank you for asking.
It's usually the older games that are almost slipping in the abandonware territory already anyway. If the publishers want to combat this, they should elevate the shovelware CD collections to a new era, or make the old games legit freeware. Perhaps make buying old games easier online (I can't do Steam - no credit card and my debit card can only be used nationally). Hey, I'd sure as heck buy a giant collection of DOS games on a DVD-ROM if the price was right... Not long ago I bought a collection of D&D RPGs for 40€ and I suppose everyone agrees it's a steal for 8 games and 5 expansion disks =)
Actually, the code displayed in the original Terminator movie was IBM 370 assembler language. Mainframe Arnold wouldn't settle for being a micro anything.
Actually, I remember it having both a listing in what definitely did look like 6502 assembly listing... and some code in another language, which might have been the IBM one. Terminator code definitely wasn't all 6502 code, just a jumble of various other listings. Haven't seen the film in a while so I can't say for sure...
I then tried making a webpage included the type attribute, specifiying "xml/xml+svg". The web browsers continued to display the XML text.
Which is pretty logical, considering the correct MIME type for .svg files is "image/svg+xml". "xml/" isn't (last I checked) a valid prefix at all, and XML-based formats have "+xml" in the end of the latter part, not the beginning!
The MIME types of various XML-based formats are a pretty complex issue; some ill-defined formats (*cough* some OPML hacks) may need to be served as deprecated "text/xml", some as "application/xml", and then there's various text|application|image/*+xml types.
PS, FYI, I ultimately got the SVG file to be displayed correctly by re-uploading it as an XML file. The server then sent "Content-type: xml/xml" and the web browsers figured out what to do with it.
Well, isn't that bad voodoo? One would assume that the correct behaviour when encountering "some random XML stuff" would be to display the file as XML, again, and not make weird assumptions...
I run Womencoder. It's nicer to look at, but verbose mode usually produces too much irrelevant nonsense. </snark>
Ah! Now I know why I'm having so much problems converting videos with mencoder. I used to create tons of videos that don't necessarily have the right quality settings and/or don't play correctly, but now it turns out I need to read the manual! *shivers* </snark>
Ah, the cleverness of the hack in question is not that they can make the coffee maker to produce coffee, no. The evil hax0rs really want the coffee.
Employee 1: "This has to be the most ridiculous work order I've ever received."
Employee 2: "What is it?"
E1: "At precisely 12:02, I'm supposed to take the cup from the coffee percolator and deliver it to this address a few blocks away."
E2: "What? Are you kidding?"
E1: "No, it's on our company letterhead. Signed by the CEO. 'Deliver this cup of coffee to our IT subcontractor. This may sound like an unusual order, but millions are at stake here.'"
E2: "Well, I wonder what those primadonnas come up with next time?"
Not long ago, folks here happened to point me toward loki_compat_libs. Lo! LD_PRELOADing ye olde libstdc++, smpeg and SDL seems to make the game work perfectly, at least for me. And there were many nervestaplings once more. =)
Funny, I actually got SMAC to work on a reasonably new setup; the updater blew up (I had to patch the game manually by extracting the update and patching the files individually with xdelta), fullscreen mode doesn't work (weird video mode), and apparently I'd need to disable compositing to make it not crash when the actual game play begins, which I'm too lazy to do...
We needs a new build or at least a competent clone! SMAC rules!
I think there's a small problem of distribution. Linux-only games won't sell. However, Windows games do sell, and if there's Linux binaries available, all the better.
Of the games on the list, I have NWN, Quake 3, 4 and Doom 3... NWN, Doom 3 and Q4 on the virtue of buying the Windows version and downloading the free binary, Q3A because luckily there actually was a local book shop that had Linux games (I also bought Myth II from them, and ordered SMAC from another store). Loki was a great company, too bad they didn't quite have the distribution figured out to the same extent as other game companies.
Currently, I don't see many other viable modes of distribution for Linux games other than either a) Sell Windows games and let people download Linux binaries on their own or b) supply Linux binaries inconspicuously on the CD. Linux-only packages are murder.
Otherwise sound suggestions, but...
...Enter the age of the person you called...a very good reason to actually remember someone else's birthdays, no? The System Automatically Hates Your Guts if you forgot. =)
Great, more culture-dependant CAPTCHAs.
I don't have the exact quote at hand, but to paraphrase Markus Kajo: "If I wanted to interrogate and expose foreign spies, I wouldn't ask them questions like 'who was the 5th President of Finland'. Most of the Finns wouldn't know that either! I'd ask them to make an omelet - if they just make you one without complaints, then they're obviously spies, because they weren't told that in Finland, you have to always apologise for your own cooking: 'I'm sorry it's a bit burnt on the edges...'"
BZZZZT-ish. You're on the right track, but the logical conclusion isn't exactly thrill-worthy.
Yes, in dynamic system, you can stuff an arbitrary value in an arbitrary variable, but that value has to come from somewhere. Surprise surprise, return values of methods that process user input can be alarmingly well understood.
For example, the spec says gets method in Kernel will return a String (or a nil in case of EOF), and it will most definitely not return an automagically parsed number or, say, a Date object... or EvilHackerSystemExploderObject! (Unless your platform is 0wned - but if an attacker can run arbitrary code, you have bigger problems than type safety...)
No matter what the language we're dealing with, the programmer has to understand exactly what the functions return. I've seen plenty of uncaught NullPointerExceptions in perfectly ordinary Java programs to be convinced that static typing won't save you from knowing thy damne API. =)
A bit of a chicken-and-an-egg problem here: How do you propose you authenticate users without a) running the authenticating program as root, having privileges to say "okay, you're user X, let me shift the control over to you", or b) being just as exploitable by giving limited user Y the privilege of saying "okay, you're user X, let me shift the control over to you"?
Linux isn't any better, you know...
# ps axu | grep getty /sbin/getty 38400 tty3 /sbin/getty 38400 tty4 /usr/sbin/gdm /usr/sbin/gdm
root 4825 [...]
root 4826 [...]
[...]
# ps axu | grep gdm
root 10691 [...]
root 23736 [...]
A better question would be to ask, "why is the login application executing random programs anyway?" or, like you said, "why isn't the login application making sure that, when it executes a random program, it actually executes the program it was supposed to execute?" but I suppose the answer to these questions is simple: "sometimes the flexibility is warranted" and "this is getting way too elaborate, giving minimal gains in actual real security" - in short, if you want to make sure utilman.exe isn't messed around with before the boot, the more feasible and elegant solution is to use full-drive encryption (which solves far more problems at one single swat), not mess around with micro-granular annoyances.
With the permission from the community in question. You need to make distinction between creators of the work and the public that uses and distributes the work. One would assume that if they get contributors aboard, each of them will understand what they're going to do with the work, right?
Star Wreck: In the Pirkinning was released under BY-NC-ND, and was definitely a "community work" in every sense of the expression. It's also sold on DVD, for profit - by the creators. -NC just means you aren't allowed to make a copy and then sell it yourself.
The finer points of the license only apply to people who aren't the copyright holders. Copyright holders can do whatever they want.
Indeed! Our tests have shown that SSDS is very capable indeed, for various definitions of "capable", "very" and "indeed". SSDS excels in Obtuse Search Syntax, Not Parsing the Content, and Extending the Joke Way Beyond Snapping Point. But we all love it anyway over at thedailywtf!
RealPlayer - Avoiding RealPlayer like the plague it is (using "Amarok" for the same functionality, if not the same file format). Result? No privacy leaks, no ads, no reporting back to Real on what I listen to or where I visit on the web.
Java - Using Sun's Java without the Yahoo toolbar. Result? Java is reasonably well behaved. Looking forward to truly open-sourced Java in the near future.
Actually, the funny thing about these two pieces of software is that the Windows versions foist unbelievable amount of crap on you, but the Linux versions are actually pretty good.
Linux RealPlayer / HelixPlayer is pretty minimal, and has absolutely none of the crap you get in Windows. If we didn't already have the more featureful VLC Player, RP would probably be a contender, now I just use it to play RealMedia stuff (which isn't very often, surprise surprise). Likewise, Sun Java 1.6 is the best damn Java environment I've ever used and doesn't have any extra bundles of junk - it's even included in Debian repositories now. Yes, Sun Java 1.7 will probably rule.
(And while I use Amarok too, I use VLC for the tasks people would usually use RP for - there's a difference between the use cases of "just play something off the library" and "just play this random file I have here". No need to fluff last.fm profile with random garbage, for example. =)
"The Management would like to announce that we're switching to slot-loading CD-ROM drives next week. We will be reserving more burn ointments in the first aid room for the next week or so and the janitor has been instructed to stock extra tissues in the bathrooms, but people who have been using CD-ROM drives as coffee cup holders should seriously stop using them as coffee cup holders ASAP."
Magic quotes did the wrong fix that incidentally happened to work for some people. The problem was that people had been concatenating (unprocessed) parameters to SQL queries; the right solution would have been to process the quoting in the place where it's supposed to be processed (query parametrisation, right before the query actually goes to the DB, automagically using the method that works appropriately for the DBMS in question), but instead, the developers just said "well, we're letting you continue your dangerous way of coding, here's a band-aid fix".
I've viewed magic quotes as a feature for legacy code that seriously needs to be fixed: "people used to code completely freaking headlessly back in the day because we didn't have real security back then and this was the ONLY way to do things - this feature is a temporary security feature so that they have time to port their utterly reeking PHP3-era string concatenation crap to use DB-specific quote calls or, far better yet, PDO and prepared statements." Using prepared statements makes the code look more manageable and more in line with the stuff you see in other programming languages, which have used prepared statements for a long time now - porting old code over is more than entirely justifiable.
I'd love to pitch in with the coding, but I sadly cannot afford the time and energy required to dig through OOo's extraordinarily convoluted API documentation to figure out how to update the source code myself; I started the process, but gave up in disgust at how the docs are organized.
Wow, you actually found documentation? I tried writing an OO.o macro once. I have almost gotten back my sanity now. =)
But anyway, there's one part where OO.o differs from Word: Documents are not coupled to the application. You don't have to use OO.o to process OpenDocument.
Theoretically, it'd not be that difficult to whip up an external application that does various word count methods - after all, there's several word count methods for English too! (Some divide character count by six, some pick a page from the middle of the manuscript, multiply lines by average line length, then multiply by number of pages in manuscript, etc, etc...)
I've written a word count tool for my own use for LaTeX text myself in 15 minutes... and there's a bunch of libraries for parsing OO.o. How hard can it be? =)
Another typical human trait: Getting caught in tiny little details like this and not thinking of the big picture at all. I rest my case. Why should we get terribly caught in little details about licensed properties when - you know - Infocom was best known for their original titles. Source code for the dozens of Infocom titles! Plans for other projects they had been working on! Imagine those possibilities!
As for employee e-mail, I don't think it should be disseminated at whim - but I believe it could be examined by a trusted researcher, with resulting published research focusing strictly on the functions of the company and the game development, not on the private matters of the people involved.
Yep, it's amazing that the stuff still survives... as compared to source material that has now been lost forever.
I wish Origin had had a Massive Unix Server for source control and whatnot. But they didn't have one.
And security: this data should not have left the company.Agreed on a general principle - but if the company's IP has long since ceased to be profitable and its material is mostly just of great historical interest, the situation is quite different. It's a typical human reaction - It's easy to say "you can't have this", only thinking at the usual every-day rules, not thinking of the historical significance, condemning a lot of researchers, years hence, to look for scraps of information and hunt for hazy recollections... Yeah, it'd easy to be in Activision's pants and say "Yes, there is a chance this property is profitable and we'll get to making the Hitchhiker sequel eventually" without batting an eye, but let's face it, IF is dead as a commercial art form =)
IT professionals don't hate change. They hate useless change and unplanned change. And, of course, too frequent change. Whatever isn't broken shouldn't be changed for the sake of the change. If there are actual benefits to the change, it should be performed with care. You don't just change back and forth between different solutions because one of them works on Tuesdays and one works on Fridays - you make the thing work all the time.
And CVS to Subversion change is a very bad example because there's an automated tool (cvs2svn) that does the conversion, the Subversion workflow was specifically designed to mimic CVS workflow, and the "CVS experts" certainly know exactly how much CVS sucks and want the pain to end... they're changing in droves. =)
Uh, what? They might as well say "Well, we know vast majority of the people who download the source won't do a damn thing about it, let alone be able to find exploits/look at our sooper sekrit algorithms/whatever. We're just banning people because we're mean and arbitrary and have nothing better to do."
Why are they wasting time on doing things like this? If some dupe-exploitin', gold-auctionin' übermacroer is determined to use the source code for their nefarious purposes, surely spoofing IPs or opening new accounts will be the simplest of things to do, no?