If your e-mail is in a binary DB, you're pretty much reliant on the developer of the DB format to let you export it. Outlook Express, in particular, is very reluctant to let you bulk export e-mail - it'll export.eml files, which are the e-mail in plain text just like OE received it, but only one at a time via right-click, Save As, which is a pain for large folders (at least in the version I used to use, 5.5, it might have got better since).
Yes, it's possible to scan through binary DBs with 'less' if they contain the plain text somewhere, and I have been known to do this with my old OE.dbx files, but it's a bit ugly (half a paragraph of mail, 20 bytes or so of random binary, the other half of the paragraph).
With a maildir or mbox format (I now use MH, which has a modified maildir as its native format) you can just grep through the files if you want to extract information from them and your e-mail client isn't working/installed/whatever (or you've switched to a different one).
Nope, the Aladdin license isn't open source
on
Debian And WineX
·
· Score: 1
"If you read the entire Open Source initiative statement, you'll understand that Open Source is just a fancy name for proprietary licenses. Yea, there are some guidlines that must be met but they are a mile wide, so when someone says they are "Open Source", you really have to read their license, because it could be just about anything."
If it was open source, it could go in debian/main (after all, the Open Source Definition is basically a clarified version of the Debian Free Software Guidelines). The e-mail stated that it was going to go in debian/non-free (the archive for Debianized proprietary software, including Aladdin Ghostscript, which is under the same license).
I agree that the GPL and LGPL have their advantages, because they're free and open enough to be Free and Open, and restrictive enough to force derived stuff to be equally open.
Things like the BSD/MIT/X11/Wine license (all similarly worded) and the Zlib license are free and open source, but anyone modifying them can make their modified version proprietary. For instance, the BSD TCP/IP stack is still free, but the modified copy of the BSD TCP/IP stack in Windows isn't. Nothing Transgaming can do can stop the old X11-licensed versions of Wine being X11-licensed.
I've read the Open Source Definition and consider it to be pretty good at encapsulating what free and open software should be. It allows something as restrictive as the GPL, but doesn't require it. For some applications a less restrictive license is needed - even the Free Software Foundation license some software under the less restrictive LGPL, and put "special exception" clauses in other licenses.
One of the best examples is probably libpng - as the reference implementation of Portable Network Graphics, it's important that proprietary software vendors::coughMicrosoftcough:: can incorporate it in popular software::coughIEcough:: to ensure that support for PNGs is as wide as possible.
> > Umm, call me crazy but I think that one-time-pads are a form of secret-key symmetric cipher.
> You're right of course, I've gotten in the habit of regarding one-time pads as being in a class of their own. Something about their being the only kind of crypto that will survive quantum computing.
Alice takes some plain text and a key (which happens to be as long as the plain text and taken from the next however many bytes of her one-time pad), feeds the key and the text to some agreed algorithm (which happens to be XOR), and sends the resulting ciphertext to Bob. Bob takes the same key Alice used (which happens to be the same number of bytes from a matching one-time pad) and Alice's ciphertext, feeds the key and the ciphertext to some other agreed algorithm (which happens to be XOR), and gets Alice's plain text out.
Sounds suspiciously symmetric to me; you just happen to be using the next however many digits of your one-time pad rather than picking a key yourself.
-=-=-=-=-=-
In OpenPGP, the hypothetical cryptoanalyst trying to read your message does know which algorithm you used. How? Because you told them in the header.
If the message doesn't, in some way, include the algorithm, your recipient will have to specify which algorithm you used.
Now: Click on e-mail, enter passphrase, wait, read decrypted message
Your idea: Click on e-mail, get a window asking you for the algorithm, select 3DES with some key followed by ROT13 followed by XOR with some key followed by cyclic shift left by 47 bits followed by ElGamal followed by XOR with DeCSS source code followed by RSA, enter 3DES, XOR, ElGamal and RSA keys, wait quite a while, read decrypted message. I think collecting the encrypted mail and feeding it to GnuPG/Ciphersabre/<your one-time-pad program here> manually is probably easier.
Not happy with that sort of usability? OK, how about entering a key, and waiting for your computer to run through all the available algorithms trying to decrypt the message with that algorithm/key pair? I don't want to have to (partially) brute-force crack my own mail:-)
Taking your idea to its logical conclusion, I can construct an unbreakable encrypted message using a simple algorithm involving "dd if=/dev/random" (or rand() for entropy-impaired OSs). It's a pity the recipient can't decrypt it either.
It's not as if you're necessarily gaining anything - chaining together multiple encryption steps doesn't necessarily make anything more secure (triple ROT-13 is only as secure as ROT-13, quadruple ROT-13 is less secure:-)
Come to think of it, how are you going to get people using your arbitrarily complex encryption if they know "the enemy" can decrypt their messages? You seem to be relying on weight of data to make it unlikely that "the enemy" decrypt your particular message, but if your scheme isn't popular, it'll be quite likely. Even if it is popular, from how you seem to want it to work, anyone who's specifically out to get you can get at your particular messages pretty easily; so in fact, your idea would only work against an organisation that wanted to spy on everyone::cough.govcough::, and would be pretty useless against someone who knew who you were and that you were their target.
I've heard kitchen worktops (or "counters", for USAians) are considerably less clean than the average toilet, although I'm not sure whose definition of "clean" that is. Number of bacteria, IIRC.
It makes sense actually; is your kitchen worktop as smooth/difficult for stuff to get caught in as flat porcelain, does it have anywhere near as much water going past it as a toilet, and when did you last put bleach on it?:-)
They refused to give out usernames and passwords until we'd handed in a signed "I will not abuse these computers" form (signed by student if 18+ and able to sign legally binding documents, parent otherwise). Unfortunately, the usernames were (first initial)(last name) (e.g. jsmith) and the passwords were generated in a deterministic way from (IIRC) username + year of entry.
One of my friends only got round to handing the form in 6 months later, when the IT department noticed he'd never done so despite the fact that he'd logged in with his "secret" password and changed it rather quickly, then checked his mail daily:-)
Another dumb IT department, at my previous school, handed out numeric (4-digit) passwords, which we couldn't change (we were locked out of the relevant Control Panel applet - this was on Win95 + MS Notworking). Someone happened to notice that they seemed to go up in alphabetical order, and put 2 and 2 together - it turned out they were our pupil numbers, as printed next to our names on the register. Since in my class the pupils did the register more often than the teacher (he taught Art, what can I say), that wasn't a great plan.
Oops, forgot to turn HTML off; please ignore my other post.
A typical (say) MS license can be summarized as follows:
- We assert our ownership of this software under copyright law, which places restrictions on what you can do with it. - In addition to the restrictions this places on you, you may not do...,... or... - If you do not accept this license, you may not use this software. [Er... excuse me? what gives you the right to say that?]
So, if you accept the license, you lose rights. (Assuming it's even enforceable; I've been told they're not, at least here in the UK, but IANAL). OTOH, if the whole license is void, the terms you can use the software under suddenly get less restrictive (i.e. they become sensible).
The GPL is more like this:
- We assert our ownership of this software under copyright law, which places restrictions on what you can do with it. - If you accept the GPL, we'll waive some of those restrictions, so you can distribute copies of the software and derivative works; in exchange, you agree not to do...,... or.... - On the other hand, if you reject the GPL, it's as though we never placed it under the GPL, so the restrictions placed on you by copyright still hold. You can still *use* it if you want, we're not stopping you, but copying it is now illegal. Have a nice day.
So if the GPL is somehow void, the terms you can use the software under suddenly become *more* restrictive. As a result, I suspect the FSF and others producing GPLed software have considerably more of a legal leg to stand on.
A typical (say) MS license can be summarized as follows:
- We assert our ownership of this software under copyright law, which places restrictions on what you can do with it.
- In addition to the restrictions this places on you, you may not do...,... or...
- If you do not accept this license, you may not use this software. [Er... excuse me? what gives you the right to say that?]
So, if you accept the license, you lose rights. (Assuming it's even enforceable; I've been told they're not, at least here in the UK, but IANAL). OTOH, if the whole license is void, the terms you can use the software under suddenly get less restrictive (i.e. they become sensible).
The GPL is more like this:
- We assert our ownership of this software under copyright law, which places restrictions on what you can do with it.
- If you accept the GPL, we'll waive some of those restrictions, so you can distribute copies of the software and derivative works; in exchange, you agree not to do...,... or....
- On the other hand, if you reject the GPL, it's as though we never placed it under the GPL, so the restrictions placed on you by copyright still hold. You can still *use* it if you want, we're not stopping you, but copying it is now illegal. Have a nice day.
So if the GPL is somehow void, the terms you can use the software under suddenly become *more* restrictive. As a result, I suspect the FSF and others producing GPLed software have considerably more of a legal leg to stand on.
Wonder if they could work out some sort of check when you request a file that would compare a MD5 of their files or something
I seem to remember AOL did this briefly with their IM program to prevent/discourage another app (things like Trillian, Gaim, and Jabber, although I'm not sure which of those existed at the time) using their network; they requested the checksum of random byte ranges from the executable at random times. Shortly afterwards, the clone program's installation instructions included "Place a copy of the Windows AIM executable in this directory, so we can do checksums on it." This didn't last long.
There's really not a lot you can do to prevent unauthorised clients connecting to a public network if the people modifying the client have sufficiently low-level access (observe the problems game developers have trying to prevent modified binaries from joining their servers) - any checksum-type solution doesn't necessarily work, because how do you make sure it's the connected executable whose checksum you're getting?
"spyware-ridden"...
"sans spyware"
Isn't that just a little repetitively redundant?
No, they're opposites.
dictionary.com says:
ridden Pronunciation Key (rdn)
...
adj.
Dominated, harassed, or obsessed by. Often used in combination: disease-ridden; grief-ridden. Source: The American Heritage® Dictionary of the English Language, Fourth Edition
A note for people trying JK2+vanilla Wine on 1GHz+
on
WineX 2.0
·
· Score: 2, Informative
Kraf, thanks for the xgamma tip; I knew there must be a way to adjust gamma somewhere:-)
There seems to be a problem with JK2's CPU detection code on 1GHz+ CPUs under vanilla WINE (the multiplayer executable gets to "Detected AMD CPU with 3DNow!" then crashes with a divide-by-zero).
To fix it, get the vanilla WINE source (for Debian users like me: the result of "apt-get source wine" works nicely), open up win32/newfns.c, replace all occurences of
#if defined(__i386__) && defined(__GNUC__)
with
#if 0
and recompile (Debian users: cd to wine-yyyymmdd and run "dpkg-buildpackage -us -uc" to make new.debs).
If you don't like having to find and mount the CD, the "DUCK" no-CD crack from gamecopyworld doesn't work reliably in multiplayer, whether you use Linux or Windows; the "BH" no-cd crack (the one containing Start-MP.exe) does. Please do actually buy the game though... writing a game this good should be rewarded with actual sales:-)
I had no texture problems in High (not Very High) texture quality on a Geforce2 Pro with the latest nvidia drivers (version 1.0-2802).
And of course slightly later in life when they're using Windows (or indeed Windows-styled Unix apps) rather than just a web browser, they'll have to re-learn that you right-click to do just about anything;-)
I buy CDs. I have a sizeable pile of CDs behind my computer as I type this. I listen to CDs, when I want to listen to a whole CD end-to-end. The other 95% of the time, I listen to Ogg Vorbis versions of said CDs, and MP3s of (mostly unsigned) bands from mp3.com, because it's kinda hard to fit a 48-hour random playlist in a 3-CD changer, and impossible to set up a weighted random playlist (on the other hand, a slightly modified version of mserv, playing through the same mini hi-fi speakers, does this perfectly - I'll clean up my mserv patch for release sometime, but it basically just makes mserv play files with any of a configurable list of extensions rather than hard-coding.mp3 as the only option).
What I don't want to do is buy and listen to a crippled "CD" which I can only listen to as a single CD, and only if I don't use a computer or a decent CD-player to do so (and since my not-particularly-expensive CD player manages to play cheap unbranded CD-RWs, when audio CD players aren't meant to be able to cope with anything except CD-Rs and factory-made CDs, I'm not confident that it'd play deliberately-defective CDs very well). All my music's available to me as MP3 or Ogg Vorbis; 3 CDs at a time are available to me as CDs, and only if I want to ignore mp3.com. Put like that, it's pretty simple.
IE Favourites are actually pretty simple (each folder in the menu is a folder on disk, each favourite is a plain-text.url file structured like a very simple INI file), and Netscape 6 automatically imports IE's Favourites as a submenu of Bookmarks. Someone at Microsoft is probably kicking themselves (or being kicked) for not putting them in an obscure binary Registry key, compressed with a proprietary format and possibly encrypted:-)
Scripting languages embedded in C or C++ game engines, like Unrealscript in Epic's Unreal series, seem to provide a good compromise - many of the advantages of Java, but without the performance problems. (but then, I make Unreal Tournament mods, so perhaps I'm biased...)
During the early development of UnrealScript, several major different programming paradigms were explored and discarded before arriving at the current incarnation. First, I researched using the Sun and Microsoft Java VM's for Windows as the basis of Unreal's scripting language. It turned out that Java offered no programming benefits over C/C++ in the Unreal context, added frustraging restrictions due to the lack of needed language features (such as operator overloading), and turned out to be unfathomably slow due to both the overhead of the VM task switch and the inefficiencies of the Java garbage collector in the case of a large object graph. Second, I based an early implementation of UnrealScript on a Visual Basic variant, which worked fine, but was less friendly to programmers accustomed to C/C++. The final decision to base UnrealScript on a C++/Java variant was based on the desire to map game-specific concepts onto the language definition itself, and the need for speed and familiarity. This turned out to be a good decision, as it has greatly simplified many aspects of the Unreal codebase.
Game content and even third-party mods designed for Windows work perfectly on the Linux and MacOS ports of UT:
UnrealScript is bytecode based: UnrealScript code is compiled into a series of bytecodes similar to p-code or the Java bytecodes. This makes UnrealScript platform-neutral; this porting the client and server components of Unreal to other platforms, i.e. the Macintosh or Unix, is straightforward, and all versions can interoperate easily by executing the same scripts.
Why performance isn't always vital (my emphasis):
UnrealScript is a slow language compared to C/C++. A typical C++ program runs at about 50 million base language instructions per second, while UnrealScript runs at about 2.5 million - a 20X performance hit. The programming philosophy behind all of our own script writing is this: Write scripts that are almost always idle. In other words, use UnrealScript only to handle the "interesting" events that you want to customize, not the rote tasks, like basic movement, which Unreal's physics code can handle for you. For example, when writing a projectile script, you typically write a HitWall(), Bounce(), and Touch() function describing what to do when key events happen. Thus 95% of the time, your projectile script isn't executing any code, and is just waiting for the physics code to notify it of an event. This is inherently very efficient. In our typical level,
even though UnrealScript is comparably much slower than C++, UnrealScript execution time averages 5-10% of CPU time.
And where does the "Approved Content" come from?
on
SSSCA Hearing
·
· Score: 1
I'm sure the musicians on RIAA labels had to record demo tapes before they'd even be considered. If I was a musician trying to get signed by a record label, I wouldn't send them the only copy of my demo tape (or demo CD or whatever) - I'd copy it.
I'm sure writers had to submit drafts. For that matter, they must have handed in plenty of essays at school while they were learning to write. Many people type essays, because there are these wonderful things called computers which check your spelling and let you correct mistakes.
I'm sure most filmmakers started off as independents or amateurs.
I write programs, and I certainly learned to code (on a BBC Micro) by starting from others' programs; computer magazines published complete source code for smallish but non-trivial programs, specifically for this purpose. Many still do (look at the Hands On columns in Personal Computer World; unless they've changed a lot since I last bought a copy, the column authors publish source code to their Delphi and VB programs occasionally).
The "content providers" whose copyright this is meant to enforce have to ask themselves: if people can't record or copy "content", where does your new talent come from? If you can't copy anything, you're quite close to being unable to produce anything yourself. Yes, the media companies are OK now. They have artists who can already produce "content". But in however many years' time, how will they find the next Britney Spears if she's unable to record music?
It's difficult to make money out of providing content if you don't actually have any.
I could rant about how the whole point of any general-purpose stored-program computer, from a mainframe with the power of an abacus up to to the latest PC or Mac, is that it can carry out any sequence of instructions, on any data, and this would completely defeat the object of computers; but I hope I don't need to.
For historical reasons,/etc is configuration; I can see why that's weird (what sort of a name for system configuration is 'etcetera'?) but changing it would require changing *every* Unix application that has configuration, which distro packagers wouldn't be too happy about. (As it is, the Debian packagers have just about finished moving all documentation in all official packages from/usr/doc to/usr/share/doc to comply with the Filesystem Hierarchy Standard...)
Anyway, the Filesystem Hierarchy Standard (which is also part of LSB) puts config files in/etc, and only in/etc. That's also where Debian packages put all system (i.e. non-user) config files - I don't know whether that's Debian being FHS-compliant, or if it was already part of Debian policy. I've heard SuSE is the nearest to a LSB distribution so far, so they probably do that too.
Things in/usr shouldn't change except on upgrades and such; it's meant to be possible to have/usr mounted read-only and still reconfigure things.
/usr/share is reserved for data that could (at least in theory) be shared between computers with the same or different hardware: help files (/usr/share/doc), graphics, sounds and so on for programs that need resource files and don't have them embedded in the executable, that sort of thing. Putting configuration here would (again in theory) force all the computers using this shared directory to use the same configuration, which often isn't suitable.
As for/usr/local, that's reserved for you, the local sysadmin. If it's in/usr/local on a FHS-compatible system, either it should be something you put there yourself, or part of something you compiled from source (i.e. no RPMs or DEBs or whatever involved), or possibly an empty placeholder directory (the package for the perl interpreter is allowed to create/usr/local/lib/perl, for instance). If the packaging system put anything other than an empty directory there, that package isn't FHS compliant; complain to the packager about that.
Dotfiles are also a bit of a mistake-kept-for-historical-reasons, although there is at least a tendency towards dot directories (.gnome and so on). I suppose it would have been better if all the configuration went in ~/.config/ or ~/.etc/ or ~/etc/ from the start, but as with/etc, that would require everything to agree on a change, which is unlikely.
Nobody's said that, but that's not the point. Suppose you bought a central heating system from MicroPlumbing which came with a warranty/maintenance agreement, and before they'd install it, you had to sign a contract which included "you hereby grant permission for a MicroPlumbing plumber to enter your house at any time and install new pipes". Would you be happy with saying "no, they can't do that anyway, I always lock my front door and none of my windows open"?
Most of the issue isn't even what Microsoft will do - it's what they could do. To continue the parent post's analogy, the makers of the distro would assure you that they'd only use their root access to install patches, but you'd still object because their license would still allow them to, say, read your personal documents or install a back-door in GnuPG (or if it was specific about only installing patches, they'd still have the technological, if not legal, means to read/alter your documents).
Rather like the DMCA, really - the copyright conglomerates assure you they'll only enforce it when it's appropriate, but...
Great, call it an incentive to make the EULA more reasonable. Would anyone buy Windows if its box was twice the normal size and completely covered in legalese?:-)
And it all ends up in MS' marketing strategy - "if you sell ALL of your computers with Windows, we'll give you a BIG rebate!"
I thought it was even worse than that - more along the lines of "if you sell any computer with some OS that's not Windows, we won't sell you Windows at all"?
If it was some other company doing this (something the size of Adobe, say, for the sake of argument), that would be bad, but at least people would have the opportunity to "vote with their wallets" and go elsewhere for their software. Since Microsoft basically has a monopoly on desktop OSs, office software and miscellaneous other things, there isn't really that opportunity (I help my more hackerish friends install Linux, but much as I hate to say it, I don't think pushing non-hackerish people into leaving Windows is necessarily justified yet).
Personally I'm OK at the moment with Linux for most stuff and Win98 first edition for games, but I'm not sure what I'll do when stuff stops supporting Win9x (I don't mean Microsoft "support", I mean apps/games which will only run on an NT-based Windows, so I've probably got a few years yet). I'd better hope WINE are still making progress, I suppose.
Not going to happen... if they can send you a (insert your format here) over the net, it's a stream of bytes. If it's a stream of bytes, you can copy it (although it might be possible to use the same sort of methods as CSS or WMA, to obfuscate it enough that it doesn't seem copiable).
Yeah, I could do with a toughened PDA too. I use a 2.5 year old Psion 3c, which has been dropped, left in a bag or coat pocket, etc. a few times too many... luckily the outer casing on Psions is slightly rubberized, which must decrease the impacts quite a bit:-)
So far it's had the connection to the screen replaced, then had the right side of the hinge replaced (both under warranty), and now the warranty's run out and the left hinge is starting to go. Those complicated 3-way Psion hinges (the screen, keyboard/base and battery compartment are all separate and hinged together) are wonderfully clever, but rather too flimsy for my liking... anyone know if the Revo's any better? Or if there's a similarly small palmtop that's actually designed to take a few impacts?
Indeed, that sort of thing is probably why this happened:
The German Federal Ministry of Economics and Technology granted funds for the further development of GnuPG. See our press notice for details. --the Gnu Privacy Guard website
Slashdot Mirror
If your e-mail is in a binary DB, you're pretty much reliant on the developer of the DB format to let you export it. Outlook Express, in particular, is very reluctant to let you bulk export e-mail - it'll export .eml files, which are the e-mail in plain text just like OE received it, but only one at a time via right-click, Save As, which is a pain for large folders (at least in the version I used to use, 5.5, it might have got better since).
.dbx files, but it's a bit ugly (half a paragraph of mail, 20 bytes or so of random binary, the other half of the paragraph).
Yes, it's possible to scan through binary DBs with 'less' if they contain the plain text somewhere, and I have been known to do this with my old OE
With a maildir or mbox format (I now use MH, which has a modified maildir as its native format) you can just grep through the files if you want to extract information from them and your e-mail client isn't working/installed/whatever (or you've switched to a different one).
If it was open source, it could go in debian/main (after all, the Open Source Definition is basically a clarified version of the Debian Free Software Guidelines). The e-mail stated that it was going to go in debian/non-free (the archive for Debianized proprietary software, including Aladdin Ghostscript, which is under the same license).
I agree that the GPL and LGPL have their advantages, because they're free and open enough to be Free and Open, and restrictive enough to force derived stuff to be equally open.
Things like the BSD/MIT/X11/Wine license (all similarly worded) and the Zlib license are free and open source, but anyone modifying them can make their modified version proprietary. For instance, the BSD TCP/IP stack is still free, but the modified copy of the BSD TCP/IP stack in Windows isn't. Nothing Transgaming can do can stop the old X11-licensed versions of Wine being X11-licensed.
I've read the Open Source Definition and consider it to be pretty good at encapsulating what free and open software should be. It allows something as restrictive as the GPL, but doesn't require it. For some applications a less restrictive license is needed - even the Free Software Foundation license some software under the less restrictive LGPL, and put "special exception" clauses in other licenses.
One of the best examples is probably libpng - as the reference implementation of Portable Network Graphics, it's important that proprietary software vendors
> > Umm, call me crazy but I think that one-time-pads are a form of secret-key symmetric cipher.
> You're right of course, I've gotten in the habit of regarding one-time pads as being in a class of their own. Something about their being the only kind of crypto that will survive quantum computing.
Alice takes some plain text and a key (which happens to be as long as the plain text and taken from the next however many bytes of her one-time pad), feeds the key and the text to some agreed algorithm (which happens to be XOR), and sends the resulting ciphertext to Bob.
Bob takes the same key Alice used (which happens to be the same number of bytes from a matching one-time pad) and Alice's ciphertext, feeds the key and the ciphertext to some other agreed algorithm (which happens to be XOR), and gets Alice's plain text out.
Sounds suspiciously symmetric to me; you just happen to be using the next however many digits of your one-time pad rather than picking a key yourself.
-=-=-=-=-=-
In OpenPGP, the hypothetical cryptoanalyst trying to read your message does know which algorithm you used. How? Because you told them in the header.
If the message doesn't, in some way, include the algorithm, your recipient will have to specify which algorithm you used.
Now: Click on e-mail, enter passphrase, wait, read decrypted message
Your idea: Click on e-mail, get a window asking you for the algorithm, select 3DES with some key followed by ROT13 followed by XOR with some key followed by cyclic shift left by 47 bits followed by ElGamal followed by XOR with DeCSS source code followed by RSA, enter 3DES, XOR, ElGamal and RSA keys, wait quite a while, read decrypted message. I think collecting the encrypted mail and feeding it to GnuPG/Ciphersabre/<your one-time-pad program here> manually is probably easier.
Not happy with that sort of usability? OK, how about entering a key, and waiting for your computer to run through all the available algorithms trying to decrypt the message with that algorithm/key pair? I don't want to have to (partially) brute-force crack my own mail :-)
Taking your idea to its logical conclusion, I can construct an unbreakable encrypted message using a simple algorithm involving "dd if=/dev/random" (or rand() for entropy-impaired OSs). It's a pity the recipient can't decrypt it either.
It's not as if you're necessarily gaining anything - chaining together multiple encryption steps doesn't necessarily make anything more secure (triple ROT-13 is only as secure as ROT-13, quadruple ROT-13 is less secure :-)
Come to think of it, how are you going to get people using your arbitrarily complex encryption if they know "the enemy" can decrypt their messages? You seem to be relying on weight of data to make it unlikely that "the enemy" decrypt your particular message, but if your scheme isn't popular, it'll be quite likely. Even if it is popular, from how you seem to want it to work, anyone who's specifically out to get you can get at your particular messages pretty easily; so in fact, your idea would only work against an organisation that wanted to spy on everyone ::cough.govcough::, and would be pretty useless against someone who knew who you were and that you were their target.
I've heard kitchen worktops (or "counters", for USAians) are considerably less clean than the average toilet, although I'm not sure whose definition of "clean" that is. Number of bacteria, IIRC.
:-)
It makes sense actually; is your kitchen worktop as smooth/difficult for stuff to get caught in as flat porcelain, does it have anywhere near as much water going past it as a toilet, and when did you last put bleach on it?
They refused to give out usernames and passwords until we'd handed in a signed "I will not abuse these computers" form (signed by student if 18+ and able to sign legally binding documents, parent otherwise). Unfortunately, the usernames were (first initial)(last name) (e.g. jsmith) and the passwords were generated in a deterministic way from (IIRC) username + year of entry.
:-)
One of my friends only got round to handing the form in 6 months later, when the IT department noticed he'd never done so despite the fact that he'd logged in with his "secret" password and changed it rather quickly, then checked his mail daily
Another dumb IT department, at my previous school, handed out numeric (4-digit) passwords, which we couldn't change (we were locked out of the relevant Control Panel applet - this was on Win95 + MS Notworking). Someone happened to notice that they seemed to go up in alphabetical order, and put 2 and 2 together - it turned out they were our pupil numbers, as printed next to our names on the register. Since in my class the pupils did the register more often than the teacher (he taught Art, what can I say), that wasn't a great plan.
Oops, forgot to turn HTML off; please ignore my other post.
..., ... or ...
..., ... or ....
A typical (say) MS license can be summarized as follows:
- We assert our ownership of this software under copyright law, which places restrictions on what you can do with it.
- In addition to the restrictions this places on you, you may not do
- If you do not accept this license, you may not use this software. [Er... excuse me? what gives you the right to say that?]
So, if you accept the license, you lose rights. (Assuming it's even enforceable; I've been told they're not, at least here in the UK, but IANAL). OTOH, if the whole license is void, the terms you can use the software under suddenly get less restrictive (i.e. they become sensible).
The GPL is more like this:
- We assert our ownership of this software under copyright law, which places restrictions on what you can do with it.
- If you accept the GPL, we'll waive some of those restrictions, so you can distribute copies of the software and derivative works; in exchange, you agree not to do
- On the other hand, if you reject the GPL, it's as though we never placed it under the GPL, so the restrictions placed on you by copyright still hold. You can still *use* it if you want, we're not stopping you, but copying it is now illegal. Have a nice day.
So if the GPL is somehow void, the terms you can use the software under suddenly become *more* restrictive. As a result, I suspect the FSF and others producing GPLed software have considerably more of a legal leg to stand on.
A typical (say) MS license can be summarized as follows: - We assert our ownership of this software under copyright law, which places restrictions on what you can do with it. - In addition to the restrictions this places on you, you may not do ..., ... or ...
- If you do not accept this license, you may not use this software. [Er... excuse me? what gives you the right to say that?]
So, if you accept the license, you lose rights. (Assuming it's even enforceable; I've been told they're not, at least here in the UK, but IANAL). OTOH, if the whole license is void, the terms you can use the software under suddenly get less restrictive (i.e. they become sensible).
The GPL is more like this:
- We assert our ownership of this software under copyright law, which places restrictions on what you can do with it.
- If you accept the GPL, we'll waive some of those restrictions, so you can distribute copies of the software and derivative works; in exchange, you agree not to do ..., ... or ....
- On the other hand, if you reject the GPL, it's as though we never placed it under the GPL, so the restrictions placed on you by copyright still hold. You can still *use* it if you want, we're not stopping you, but copying it is now illegal. Have a nice day.
So if the GPL is somehow void, the terms you can use the software under suddenly become *more* restrictive. As a result, I suspect the FSF and others producing GPLed software have considerably more of a legal leg to stand on.
Wonder if they could work out some sort of check when you request a file that would compare a MD5 of their files or something
I seem to remember AOL did this briefly with their IM program to prevent/discourage another app (things like Trillian, Gaim, and Jabber, although I'm not sure which of those existed at the time) using their network; they requested the checksum of random byte ranges from the executable at random times. Shortly afterwards, the clone program's installation instructions included "Place a copy of the Windows AIM executable in this directory, so we can do checksums on it." This didn't last long.
There's really not a lot you can do to prevent unauthorised clients connecting to a public network if the people modifying the client have sufficiently low-level access (observe the problems game developers have trying to prevent modified binaries from joining their servers) - any checksum-type solution doesn't necessarily work, because how do you make sure it's the connected executable whose checksum you're getting?
No, they're opposites.
dictionary.com says:
Kraf, thanks for the xgamma tip; I knew there must be a way to adjust gamma somewhere :-)
There seems to be a problem with JK2's CPU detection code on 1GHz+ CPUs under vanilla WINE (the multiplayer executable gets to "Detected AMD CPU with 3DNow!" then crashes with a divide-by-zero).
To fix it, get the vanilla WINE source (for Debian users like me: the result of "apt-get source wine" works nicely), open up win32/newfns.c, replace all occurences of
#if defined(__i386__) && defined(__GNUC__)
with
#if 0
and recompile (Debian users: cd to wine-yyyymmdd and run "dpkg-buildpackage -us -uc" to make new .debs).
If you don't like having to find and mount the CD, the "DUCK" no-CD crack from gamecopyworld doesn't work reliably in multiplayer, whether you use Linux or Windows; the "BH" no-cd crack (the one containing Start-MP.exe) does. Please do actually buy the game though... writing a game this good should be rewarded with actual sales :-)
I had no texture problems in High (not Very High) texture quality on a Geforce2 Pro with the latest nvidia drivers (version 1.0-2802).
And of course slightly later in life when they're using Windows (or indeed Windows-styled Unix apps) rather than just a web browser, they'll have to re-learn that you right-click to do just about anything ;-)
Even if you buy CDs, some of this is true...
I buy CDs. I have a sizeable pile of CDs behind my computer as I type this. I listen to CDs, when I want to listen to a whole CD end-to-end. The other 95% of the time, I listen to Ogg Vorbis versions of said CDs, and MP3s of (mostly unsigned) bands from mp3.com, because it's kinda hard to fit a 48-hour random playlist in a 3-CD changer, and impossible to set up a weighted random playlist (on the other hand, a slightly modified version of mserv, playing through the same mini hi-fi speakers, does this perfectly - I'll clean up my mserv patch for release sometime, but it basically just makes mserv play files with any of a configurable list of extensions rather than hard-coding .mp3 as the only option).
What I don't want to do is buy and listen to a crippled "CD" which I can only listen to as a single CD, and only if I don't use a computer or a decent CD-player to do so (and since my not-particularly-expensive CD player manages to play cheap unbranded CD-RWs, when audio CD players aren't meant to be able to cope with anything except CD-Rs and factory-made CDs, I'm not confident that it'd play deliberately-defective CDs very well). All my music's available to me as MP3 or Ogg Vorbis; 3 CDs at a time are available to me as CDs, and only if I want to ignore mp3.com. Put like that, it's pretty simple.
IE Favourites are actually pretty simple (each folder in the menu is a folder on disk, each favourite is a plain-text .url file structured like a very simple INI file), and Netscape 6 automatically imports IE's Favourites as a submenu of Bookmarks. Someone at Microsoft is probably kicking themselves (or being kicked) for not putting them in an obscure binary Registry key, compressed with a proprietary format and possibly encrypted :-)
This sounds a lot like twoftpd, which seems like a great idea.
Scripting languages embedded in C or C++ game engines, like Unrealscript in Epic's Unreal series, seem to provide a good compromise - many of the advantages of Java, but without the performance problems. (but then, I make Unreal Tournament mods, so perhaps I'm biased...)
Epic Games' Unrealscript reference has some background on this. Some of the interesting bits:Why they didn't use Java:
Game content and even third-party mods designed for Windows work perfectly on the Linux and MacOS ports of UT:
Why performance isn't always vital (my emphasis):
I'm sure the musicians on RIAA labels had to record demo tapes before they'd even be considered. If I was a musician trying to get signed by a record label, I wouldn't send them the only copy of my demo tape (or demo CD or whatever) - I'd copy it.
I'm sure writers had to submit drafts. For that matter, they must have handed in plenty of essays at school while they were learning to write. Many people type essays, because there are these wonderful things called computers which check your spelling and let you correct mistakes.
I'm sure most filmmakers started off as independents or amateurs.
I write programs, and I certainly learned to code (on a BBC Micro) by starting from others' programs; computer magazines published complete source code for smallish but non-trivial programs, specifically for this purpose. Many still do (look at the Hands On columns in Personal Computer World; unless they've changed a lot since I last bought a copy, the column authors publish source code to their Delphi and VB programs occasionally).
The "content providers" whose copyright this is meant to enforce have to ask themselves: if people can't record or copy "content", where does your new talent come from? If you can't copy anything, you're quite close to being unable to produce anything yourself. Yes, the media companies are OK now. They have artists who can already produce "content". But in however many years' time, how will they find the next Britney Spears if she's unable to record music?
It's difficult to make money out of providing content if you don't actually have any.
I could rant about how the whole point of any general-purpose stored-program computer, from a mainframe with the power of an abacus up to to the latest PC or Mac, is that it can carry out any sequence of instructions, on any data, and this would completely defeat the object of computers; but I hope I don't need to.
For historical reasons, /etc is configuration; I can see why that's weird (what sort of a name for system configuration is 'etcetera'?) but changing it would require changing *every* Unix application that has configuration, which distro packagers wouldn't be too happy about. (As it is, the Debian packagers have just about finished moving all documentation in all official packages from /usr/doc to /usr/share/doc to comply with the Filesystem Hierarchy Standard...)
/etc, and only in /etc. That's also where Debian packages put all system (i.e. non-user) config files - I don't know whether that's Debian being FHS-compliant, or if it was already part of Debian policy. I've heard SuSE is the nearest to a LSB distribution so far, so they probably do that too.
/usr shouldn't change except on upgrades and such; it's meant to be possible to have /usr mounted read-only and still reconfigure things.
/usr/local, that's reserved for you, the local sysadmin. If it's in /usr/local on a FHS-compatible system, either it should be something you put there yourself, or part of something you compiled from source (i.e. no RPMs or DEBs or whatever involved), or possibly an empty placeholder directory (the package for the perl interpreter is allowed to create /usr/local/lib/perl, for instance). If the packaging system put anything other than an empty directory there, that package isn't FHS compliant; complain to the packager about that.
/etc, that would require everything to agree on a change, which is unlikely.
Anyway, the Filesystem Hierarchy Standard (which is also part of LSB) puts config files in
Things in
/usr/share is reserved for data that could (at least in theory) be shared between computers with the same or different hardware: help files (/usr/share/doc), graphics, sounds and so on for programs that need resource files and don't have them embedded in the executable, that sort of thing. Putting configuration here would (again in theory) force all the computers using this shared directory to use the same configuration, which often isn't suitable.
As for
Dotfiles are also a bit of a mistake-kept-for-historical-reasons, although there is at least a tendency towards dot directories (.gnome and so on). I suppose it would have been better if all the configuration went in ~/.config/ or ~/.etc/ or ~/etc/ from the start, but as with
Heh. Was it uce@doj.gov or something that the US authorities set up as a sort of national abuse@domain equivalent?
Nobody's said that, but that's not the point. Suppose you bought a central heating system from MicroPlumbing which came with a warranty/maintenance agreement, and before they'd install it, you had to sign a contract which included "you hereby grant permission for a MicroPlumbing plumber to enter your house at any time and install new pipes". Would you be happy with saying "no, they can't do that anyway, I always lock my front door and none of my windows open"?
Most of the issue isn't even what Microsoft will do - it's what they could do. To continue the parent post's analogy, the makers of the distro would assure you that they'd only use their root access to install patches, but you'd still object because their license would still allow them to, say, read your personal documents or install a back-door in GnuPG (or if it was specific about only installing patches, they'd still have the technological, if not legal, means to read/alter your documents).
Rather like the DMCA, really - the copyright conglomerates assure you they'll only enforce it when it's appropriate, but...
#include <rants/common/dcma.h>
Great, call it an incentive to make the EULA more reasonable. Would anyone buy Windows if its box was twice the normal size and completely covered in legalese? :-)
(depressingly, the answer is probably 'yes'...)
I thought it was even worse than that - more along the lines of "if you sell any computer with some OS that's not Windows, we won't sell you Windows at all"?
If it was some other company doing this (something the size of Adobe, say, for the sake of argument), that would be bad, but at least people would have the opportunity to "vote with their wallets" and go elsewhere for their software. Since Microsoft basically has a monopoly on desktop OSs, office software and miscellaneous other things, there isn't really that opportunity (I help my more hackerish friends install Linux, but much as I hate to say it, I don't think pushing non-hackerish people into leaving Windows is necessarily justified yet).
Personally I'm OK at the moment with Linux for most stuff and Win98 first edition for games, but I'm not sure what I'll do when stuff stops supporting Win9x (I don't mean Microsoft "support", I mean apps/games which will only run on an NT-based Windows, so I've probably got a few years yet). I'd better hope WINE are still making progress, I suppose.
Not going to happen... if they can send you a (insert your format here) over the net, it's a stream of bytes. If it's a stream of bytes, you can copy it (although it might be possible to use the same sort of methods as CSS or WMA, to obfuscate it enough that it doesn't seem copiable).
Yeah, I could do with a toughened PDA too. I use a 2.5 year old Psion 3c, which has been dropped, left in a bag or coat pocket, etc. a few times too many... luckily the outer casing on Psions is slightly rubberized, which must decrease the impacts quite a bit :-)
So far it's had the connection to the screen replaced, then had the right side of the hinge replaced (both under warranty), and now the warranty's run out and the left hinge is starting to go. Those complicated 3-way Psion hinges (the screen, keyboard/base and battery compartment are all separate and hinged together) are wonderfully clever, but rather too flimsy for my liking... anyone know if the Revo's any better? Or if there's a similarly small palmtop that's actually designed to take a few impacts?
Indeed, that sort of thing is probably why this happened: