The trick is that when you receive polarized light, if you pick the wrong polarization there's a 50% chance that the light will spontaneously flip to that polarization. Thus, unless you know the correct polarization sequence (the key), as you receive the light, you will not be able to intercept the communications under even the best of circumstances.
FYI, for those not owning photon transmitters/receivers, it might be interesting to know of its vague relative, a software method of communicating confidentially over an insecure link, called
Chaffing and Winnowing. It, too, is based on mere plaintext embed into random noise with keys for the sender and receiver to recognize the right packets off the stream. Unlike in quantum transmission, the participants to the protocol won't notice someone sniffing but the changes for the sniffer to manage to pick up the right packets is near impossible in both cases.
But the Content Cartel is pushing harder and faster and making more and more intrusive policies. Some day -- perhaps soon -- they will step over the line and change something that people actually do care about.
I'm afraid you're an optimist. Considering how markets work in general, I expect them to go back one step after crossing the line and then maintain a steady balance around it. That's making it as intrusive as possible without losing more money than they gain with their intrusive actions in the first place.
You don't even realize you made a logical flaw. It should be: Open Source implies no profit. Piracy implies no profit. From here, it is a logically incorrect to state that Open Source implies Piracy. To do that, you would need to make an error of modulos ponens: no profit implies Piracy. But it does not go both ways. To imply is not to equal.
Poof. Read again and stay on topic. "Think like business people..." -- in all of a sudden the logic does indeed appear.
Calendar Cubes
I like this one. You need all the numbers from 0 through 9 plus 0 through 3. That's 14 faces. You will never need 00 though, so you can remove one of the 0s. Also, you will only ever need the 3 with 0 or 1, so you can remove it from one of the blocks. The solution: the numbers 1-6 on one block, and 7-9 and 0-2 on the other. Yeah it works.
If one has 1-6 and the other has 7-9/0-2, then how do you represent 7 as 07 (which was a requirement IIRC)?
The right answer seems to be {0,1,2,3,4,5} and {0,1,2,6,7,8} since you can turn the 6 to 9 and vice versa. Then you can represent %02d representation of [1,31].
When AOL move browsers, I'm wondering how many people will phone the support line and complain that their web-browser is broken because "the web site worked just fine on the old one".
Joe Sixpack will just consider such as the traditional "one company blaming another and vice versa" -situation. Similar to getting your car fixed, then it fails again and the repair shop and the spareparts shop fight each other. Joe Sixpack just wants the pages to work, he doesn't give a rat's ass about standards.
Unless you educate him.
Any chance of such enlightening taking place in the near future? I certainly hope so since that's all I can do. Goes for having people accept/reject Microsoft's plans for its evil empire in general, too.
It is also worth noting that MS does not see Palladium as Windows only. They are going to release the source, which is odd in itself. It leads me to believe in general that MS may being a rather okay-ish thing.
Not "Windows only" but more likely to be "Microsoft only". The "openness" you're referring to is a M$ language term and means "your possibility to embrace our Palladium/DRM sources to make your Foo appliance Palladium compliant". Linux is Palladium incompatible by definition. Microsoft wants all the hardware run their M$ Palladium code first, so that they get to decide what else can be run on that hardware. Not okay.
DOOM *did* have a Z-level, obviously. It is a common misconception that it didn't. There was a technical limit in the virtual representation of a level, but it would've been the same even if a game used three-dimensional coordinates for all vertices but for rendering or clipping reasons didn't allow two rooms above each other.
For the technical side, Doom used 2D vertices to create 2D polygons, called sectors, which in turn had the attributes of ceiling height and floor height. So your map would always be 2D but Doom could render the floors and ceilings of a sector to any height.
Also, there are well-known techniques to trick the Doom engine to have two stories present on a particular place of the map, or even three stories. Creating several bridges on top of and crossing each other is possible, too.
To me, the defining features that make Doom are:
Dozens of monsters swarming you all at once
True.
Monsters that can be tricked into killing each other
True.
Light and music providing atmosphere
Well, kind of. I'd like to change this point to "Level Design". Having created dozens of Doom levels myself, having seen too many levels by authors who want them just look cool, I can say that the three episodes of the original Doom I were really well-thought and _playable_ and still superior, even to any iD levels seen in games using a variant of the original Doom engine. Level design is damn difficult. Designing a good, playable level is near impossible if you're in a rush. I'd say that creating the levels may take more time and is definitely more important than the 3D-engine, when it comes to the game as a whole. Level design is also one of the things that are easy to suck at.:P
(Quake's (1) levels weren't exactly bad either, but the gameplay was boring especially because of the first point you made.)
The question at issue is the almighty Euro which is not as effectatious when it comes to bribing politicians. Unlike in the US European politicians do not collect funds directly for their personal campaigns.
Yeah, European politicians are genuinely stupid and will pass stupid directives even without bribes:-)
getting over my own selfish wish to have new toys to play with
You can just point your apt sources to testing/woody and get the toys already, if you're running Potato, still. There isn't anything in the final release that you couldn't already run on your desktop using the unreleased Woody. Some bugs will be gone when it's the time.
For servers, I can wait for months to get Woody polished to become Debian stable, anyway.
I think the most important thing that OSS Office suites need to focus on is compatibility with the majority of the office suite out there (in this case MS Office).
Yeah, and that in turn kills the innovation: you'll be busy deciphering the latest.doc/.xls formats and features which prevents you from doing things differently than in M$O, creating new features and eventually making your application better than M$Office. And your application will always remain a mere cheap copy of the original. Microsoft has really worked the situation out for themselves here -- I don't think OSS office suites will get out of the imitation phase you mentioned anytime soon and M$ is going to keep it that way as long as possible:-P
DE/WM: XFce
File Manager/Desktop icons: Rox filer/XFtree
Web Browser: Galeon, Opera or Dillo
Mail Client: Sylpheed or Evolution
Word Processor: AbiWord, Applix or WP8
Other Desktop apps: Gnumeric, JPilot
Diversity is good so here's my two cents (I can say that now even in Europe!:)) for a light-weight system, hope this helps someone:
Sawfish with a fast and simple theme. IMHO the Fish is the ultimate window manager, there's virtuall anything you couldn't configure and I love REP too;
/usr/bin/panel from Gnome, running the top menubar for nice access to applications, settings and a nice placeholder for minimized windows etc. The Gnome panel is really the best panel/dock utility I've seen, you can drag'n drop application to/from it and it has a variety of applets and you can make the panel of whatever kind you like and put it just about anywhere;
ROX-Filer pinboard as the desktop, this is the filemanager I've actually found to be faster and more practical than the _shell_ in some cases, and as a die-hard shell user since 80's already, that's a damn lot!
Nothing else, my friend. I've configured Sawfish to have my desktop 95% keyboard-operable, too, sometimes you don't want to touch the mouse.
Yeah, for applications: I'd use Galeon for webbrowsing as soon as they stabilize at Mozilla 1.0; currently I'm running Mozilla 0.9.9, and since it's always running it doesn't start up slow:) Mailclient shall be any of those text-based ones, mutt or pine. There isn't one good graphical mailclient, or perhaps YAM on the Amiga. Then, there's Gnus for reading mail, my favorite. Emacs (not XEmacs!) is one previously bloated application that actually runs damn fast on even the modest hardware of today.
He is right, at least in part. Look at MS, they have tones of cash (too much really). Which open source firm is even profitable? Anyone besides RH? GPL does bestow freedom *but* it does make it hard to charge money for your work. And yes, money is needed to make more software.
Where do these categorial assumptions come from? That must be like this and this must be like that? Open source gets written as long as there's need for it and the work put in by a developer pays off enough for himself to keep him doing that. Period. Commercial software gets written as long as they get enough money to fund writing it and make some (lot of) profit. Period. A simplified example: Linux was written because Windows and stinky commercial OSes sucked so badly. Windows sells because not everyone trusts Linux or some academic open source nerds.
If either way goes below zero, that is, less being got back than it is put in, that one is going to diminish. The cruelty of that has scared M$ so badly that they're really going for a firm stance in the politics and law-making, to ensure their monopoly, as they're not certain that they can beat the technical superiority of the open source world. Us open source developers have much less to fear, there's nothing stopping us to write code by ourselves, to ourselves. Although, I do guess that Microsoft would probably want to see something stopping us. Practically, however, we're not dependent of Microsoft dying away.
Re:*** Help on upgrading a remote server?
on
OpenSSH Local Root Hole
·
· Score: 2, Informative
2) Install the new ssh version. Your old version is in memory, so replacing the binary won't have any adverse effect on your connection.
Ahem. Wrong. Linux is nice, it will keep the old
version of the binary accessible for the running image as long as there are any, but e.g. SunOS doesn't do that. Modifying the binary will cause wrong code to be read from the disk whenever the OS reads the binary file again. This will happen
for example when the code has been paged out from
the main memory after which the program becomes active again and the OS loads the code of the process from the original binary. Try this:
cp/bin/cat foo ;./foo
Hit ctrl-z to suspend the copy of cat, truncate
the file: echo > foo and type fg to resume the copy of cat -> boom, segfault most likely unless the machine is very idle and not having paged out the code section of "foo" out.
Re:THE BIG FREAKING POINT.
on
SSSCA Hearing
·
· Score: 1
Horror stories of content being tied to particular hardware abound. What happens when the hardware breaks? ...
I think, sadly, it's a given that we'll have hardware copy protection. Given public key cryptography, and an escrow mechanism for user-specific secret private keys within the equipment you own, it is technologically feasable.
One thing in which I can see the government intervention as a good thing is that a government bill could mandate a key-escrow for the copyrighted content, releasing the material to the public as soon as the copyright expires. (It is a another question why we have copyrights of effectively a hundred years.) If the corps can decide, they'll certainly reserve the right to make all the content vanish and turn unusable, if ever needed.
Re:They support MacOS X style app wrappers!
on
ROX Desktop Update
·
· Score: 1
Since ROX-filer is just a file manager and doesn't have to set system-wide things like file assocations, it doesn't suffer from these problems AFAIK.
It'd be really cool, if ROX would optionally use Gnome's mimetype mappings as a fallback. Now I have to set up some bindings for ROX, using the Run Action dialog. And if I change something in Gnome, I'll have to change it in ROX too, to keep my system consistent.
What about if the email is on the company's or university's Unix box, where you ssh to run pine on a server on which you can't mount filesystems to any directories? And you still have to keep the mail in one place in order to access it from anywhere. A mail client that'd crypt its archive mboxen would be nice, not that I knew of any:(
If you're using a personal computer then of course you can use whatever encrypting filesystem/loopback hack you want to. But that's a big "if".
You've done an outstanding job of making it difficult, if not impossible for the people who are running slashdot "light" to mark a person a friend or foe. Could we have a bit more description of these features please?:)
Actually how do you do it the hard, difficult way? I haven't found the new feature in this "Light" version at all yet! Please implement it here too, it's a good idea if usable:(
Package management helps with this, yes. It doesn't fix the fundamental problem.
A few points for your interest. They mostly advocate packing GUI programs into a single directory. For command-line program it doesn't really matter where the binaries are but also in their case, documentation and datafiles should be in their own directory.
Should all GUI-programs unpack into one directory and be runnable from there, any non-admin user could easily install software for himself. Just grab the rpm, install it to ~/MySoftware/FooEditor or something and off you go. This is want Windows people want to do if they need to.;
The program directories could maintain a standard structure inside themselves: FooEditor/lib, FooEditor/doc, etc. to keep it sensible for the developers. But from outside the program's custom directory structure, it'd just look like on simple directory. Most notably, when you'd open a program directory, you'd see the icon for the binary, perhaps an icon for documentation and nothing more. Command-line programs could stuff their data files into their own directory and install a symlink to/usr/bin for example;
Since all programs would still come from packages, it wouldn't be easy to add each program's library directory to ld.so.conf or the directory where the binary is to PATH. Remember that we typically already maintain hierarchial menu entries for KDE/Gnome programs. And the program itself could refer to./icons/fooeditor-splash.png too, for hardly any other program would have to access another program's splash image or any other file of similar essence;
We wouldn't need the damn KDE/Gnome menus, if people could just open/usr/applications/ in their file manager and see which applications are there. Click on the directory, click on the icon of the executable and off you go! Even a regular Joe can maintain and organize a bunch of applications if they're just there and nowhere else;
We could still keep a directory of so-called system commands. Like C: in Amiga which had this mostly right from the beginning. You would install command-line-only programs in C: (say,/bin or/usr/bin) and have GUI applications in one directory/binary-exe each and organize the directories to your likings, like in a Applications/ folder. Let the user create a MiscApps/ folder for simple binaries that don't have any related files with them. As for Amiga, note that many programs _did_ install their stuff to Amiga's system directories but not nearly as annoyingly as Linux applications do;
Finally, I'd like to say that since we have hierarchial directories and we tend to organize things in groups and subgroups (and subsubgroups) it'd be only natural to have a different kind of system tree layout. When you want to mess with program X's example files you might want to take a look at program X's documentation too, not program Y's example files.
I've been running ext3 fine for a few weeks now
on my home box and my linux workstation at work. On Monday I decided to update our cvs server to
kernel 2.2.20 (from.19) and ext3 and the next morning it
was down big time. Reading logs, I could see that
something had gone wrong during the big backup
cronjob after 6am. It creates a 150-meg tmp tarball of our cvs repository for replication and it had only managed to do the first 4 megabytes. I also had a few "hda: lost interrupt" entries in the syslog, right during the time the backup process had halted. The disk was sloppy and not responding much, so it might be some h/w failure as well. I booted, the ext3 replayed the journal and everything seemed fine until I found some weird files with mysterious access bits set in some directories. I couldn't delete or move them. Also some files had disappeared and some others corrupted, AFAIK. I took the system down to runlevel one, remounted partitions read-only and run fsck.ext2 on them. It reported hundreds if not thousands blocks belonging to more than one inode.
This may just be some weird hardware failure
but it just sounds too coincidental. The box has been rock stable for at least a year in its current h/w setup. I've been testing 2.2.20's fine
on many machines before, both with ext3 and ext2.
Now that I restored the old system from backups
it's running on 2.2.19+ext2 again quite happily.
I'd like to know if anyone else has had problems that may be related to ext3? I'm still
running it on my personal boxen but it seems that our servers won't be seeing this new filesystem at least until it appears on Debian Potato, included in the standard 2.2.x kernel release. If ever.
I guess they don't want people actually doing useful things like online banking and such with the web, huh? You really can't do any type of semi-complex form-driven web database without using cookies.
Go learn your tools. There's absolutely no need for cookies. Everything non-persistent cookies can do can be done with query part of the URL or using hidden input elements in forms. Using right tools or toolkits this is completely transparent to you. (And persistent cookies are only evil - any reasonable service like online banking has to identify you anyway each time you log on to the system.)
I have written several large-scale server-side web applications without using cookies, utilizing a database as the data source as well as in storing non-public session data (the less you expose to the user the more vulnerable you are and cookies make it too tempting) in there as well. Guess what: they're all fully usable with Lynx/Links and/or any browser with cookies turned off. No tradeoffs!
Like someone posted into some other discussion here a few days ago, making exploits public probably reduces the need for potential wannabes or semi-blackhats to compete in the field. What's cool in that if you can do the same as 10000 other similar people, as everything is written already. All you need is gcc -o nukem2 nukem.c.
Closing exploits, or further, even all security hole announcements, could rise a hell, engaging all competent-enough wannabes writing exploits to compete with eachother. Once again there would be a social gain by doing the best exploit in the shortest time.
Yet there are still enough script kiddyzzz to cause harm if companies don't deliver patches and if admins don't install them, thus, getting things get fixed. Would Microsoft ever raise an eyebrow to any security hole if there were no public means to exploit them? Only then, outlawed blackhats would overflow buffers and assuming that they were pros, no one wouldn't probably notice anything until one morning something completely different had happened during the night...
When will they start an obfuscated perl contest? Or would that be too easy?;)
Yes, that'd be to easy. Just any perl code would do. We could have a contest of the most readable, self-documenting and clearest perl code, though. But, then again, that might be too hard.
Mac-on-Linux is akin to VMware - it runs Mac code natively on PPC processors by virtualizing the underlying hardware. It is amazingly powerful
I really wish I had some nice PPC-Mac hardware here now. This reminds me of ShapeShifter on the Amiga. It was a hardware layer emulator that run native 68k-Mac programs natively on my Motorola 68060@60MHz. In that setup, boosted with my S3 powered CyberVision3D board, MacOS (8.x something at the time, IIRC) run fast as hell. I could play DukeNukem on my Amiga.. err, on my Mac:)
Actually it was faster than some clumsy PPC-Macs at the university's computer lab. ShapeShifter booted in 10-15 seconds and you could mount a Mac partition over to Amiga-side for easy file transfer (you could use hdimages or a separate partition for Mac). And I could actually use my virtual Mac for some things my Amiga didn't grok, like converting between certain proprietary movie formats.
With VMWare I'm unfortunately tied to x86 operating systems and as I already run the most viable choice (Linux:-o, IMHO) there's not much use for it.. Macs are good, and they're even better if you don't depend on them wholly.
Slashdot Mirror
FYI, for those not owning photon transmitters/receivers, it might be interesting to know of its vague relative, a software method of communicating confidentially over an insecure link, called Chaffing and Winnowing. It, too, is based on mere plaintext embed into random noise with keys for the sender and receiver to recognize the right packets off the stream. Unlike in quantum transmission, the participants to the protocol won't notice someone sniffing but the changes for the sniffer to manage to pick up the right packets is near impossible in both cases.
I'm afraid you're an optimist. Considering how markets work in general, I expect them to go back one step after crossing the line and then maintain a steady balance around it. That's making it as intrusive as possible without losing more money than they gain with their intrusive actions in the first place.
Poof. Read again and stay on topic. "Think like business people..." -- in all of a sudden the logic does indeed appear.
If one has 1-6 and the other has 7-9/0-2, then how do you represent 7 as 07 (which was a requirement IIRC)?
The right answer seems to be {0,1,2,3,4,5} and {0,1,2,6,7,8} since you can turn the 6 to 9 and vice versa. Then you can represent %02d representation of [1,31].
Joe Sixpack will just consider such as the traditional "one company blaming another and vice versa" -situation. Similar to getting your car fixed, then it fails again and the repair shop and the spareparts shop fight each other. Joe Sixpack just wants the pages to work, he doesn't give a rat's ass about standards.
Unless you educate him.
Any chance of such enlightening taking place in the near future? I certainly hope so since that's all I can do. Goes for having people accept/reject Microsoft's plans for its evil empire in general, too.
Not "Windows only" but more likely to be "Microsoft only". The "openness" you're referring to is a M$ language term and means "your possibility to embrace our Palladium/DRM sources to make your Foo appliance Palladium compliant". Linux is Palladium incompatible by definition. Microsoft wants all the hardware run their M$ Palladium code first, so that they get to decide what else can be run on that hardware. Not okay.
For the technical side, Doom used 2D vertices to create 2D polygons, called sectors, which in turn had the attributes of ceiling height and floor height. So your map would always be 2D but Doom could render the floors and ceilings of a sector to any height.
Also, there are well-known techniques to trick the Doom engine to have two stories present on a particular place of the map, or even three stories. Creating several bridges on top of and crossing each other is possible, too.
Dozens of monsters swarming you all at once
True.
Monsters that can be tricked into killing each otherTrue.
Light and music providing atmosphereWell, kind of. I'd like to change this point to "Level Design". Having created dozens of Doom levels myself, having seen too many levels by authors who want them just look cool, I can say that the three episodes of the original Doom I were really well-thought and _playable_ and still superior, even to any iD levels seen in games using a variant of the original Doom engine. Level design is damn difficult. Designing a good, playable level is near impossible if you're in a rush. I'd say that creating the levels may take more time and is definitely more important than the 3D-engine, when it comes to the game as a whole. Level design is also one of the things that are easy to suck at. :P
(Quake's (1) levels weren't exactly bad either, but the gameplay was boring especially because of the first point you made.)
Yeah, European politicians are genuinely stupid and will pass stupid directives even without bribes :-)
- A pissed European.
You can just point your apt sources to testing/woody and get the toys already, if you're running Potato, still. There isn't anything in the final release that you couldn't already run on your desktop using the unreleased Woody. Some bugs will be gone when it's the time.
For servers, I can wait for months to get Woody polished to become Debian stable, anyway.
Yeah, and that in turn kills the innovation: you'll be busy deciphering the latest .doc/.xls formats and features which prevents you from doing things differently than in M$O, creating new features and eventually making your application better than M$Office. And your application will always remain a mere cheap copy of the original. Microsoft has really worked the situation out for themselves here -- I don't think OSS office suites will get out of the imitation phase you mentioned anytime soon and M$ is going to keep it that way as long as possible :-P
Where do these categorial assumptions come from? That must be like this and this must be like that? Open source gets written as long as there's need for it and the work put in by a developer pays off enough for himself to keep him doing that. Period. Commercial software gets written as long as they get enough money to fund writing it and make some (lot of) profit. Period. A simplified example: Linux was written because Windows and stinky commercial OSes sucked so badly. Windows sells because not everyone trusts Linux or some academic open source nerds.
If either way goes below zero, that is, less being got back than it is put in, that one is going to diminish. The cruelty of that has scared M$ so badly that they're really going for a firm stance in the politics and law-making, to ensure their monopoly, as they're not certain that they can beat the technical superiority of the open source world. Us open source developers have much less to fear, there's nothing stopping us to write code by ourselves, to ourselves. Although, I do guess that Microsoft would probably want to see something stopping us. Practically, however, we're not dependent of Microsoft dying away.
Ahem. Wrong. Linux is nice, it will keep the old version of the binary accessible for the running image as long as there are any, but e.g. SunOS doesn't do that. Modifying the binary will cause wrong code to be read from the disk whenever the OS reads the binary file again. This will happen for example when the code has been paged out from the main memory after which the program becomes active again and the OS loads the code of the process from the original binary. Try this:
cp /bin/cat foo ; ./foo
Hit ctrl-z to suspend the copy of cat, truncate the file:
echo > foo
and type
fg
to resume the copy of cat -> boom, segfault most likely unless the machine is very idle and not having paged out the code section of "foo" out.
One thing in which I can see the government intervention as a good thing is that a government bill could mandate a key-escrow for the copyrighted content, releasing the material to the public as soon as the copyright expires. (It is a another question why we have copyrights of effectively a hundred years.) If the corps can decide, they'll certainly reserve the right to make all the content vanish and turn unusable, if ever needed.
It'd be really cool, if ROX would optionally use Gnome's mimetype mappings as a fallback. Now I have to set up some bindings for ROX, using the Run Action dialog. And if I change something in Gnome, I'll have to change it in ROX too, to keep my system consistent.
What about if the email is on the company's or university's Unix box, where you ssh to run pine on a server on which you can't mount filesystems to any directories? And you still have to keep the mail in one place in order to access it from anywhere. A mail client that'd crypt its archive mboxen would be nice, not that I knew of any :(
If you're using a personal computer then of course you can use whatever encrypting filesystem/loopback hack you want to. But that's a big "if".
Actually how do you do it the hard, difficult way? I haven't found the new feature in this "Light" version at all yet! Please implement it here too, it's a good idea if usable :(
Package management helps with this, yes. It doesn't fix the fundamental problem.
A few points for your interest. They mostly advocate packing GUI programs into a single directory. For command-line program it doesn't really matter where the binaries are but also in their case, documentation and datafiles should be in their own directory.
Finally, I'd like to say that since we have hierarchial directories and we tend to organize things in groups and subgroups (and subsubgroups) it'd be only natural to have a different kind of system tree layout. When you want to mess with program X's example files you might want to take a look at program X's documentation too, not program Y's example files.
I've been running ext3 fine for a few weeks now on my home box and my linux workstation at work. On Monday I decided to update our cvs server to kernel 2.2.20 (from .19) and ext3 and the next morning it
was down big time. Reading logs, I could see that
something had gone wrong during the big backup
cronjob after 6am. It creates a 150-meg tmp tarball of our cvs repository for replication and it had only managed to do the first 4 megabytes. I also had a few "hda: lost interrupt" entries in the syslog, right during the time the backup process had halted. The disk was sloppy and not responding much, so it might be some h/w failure as well. I booted, the ext3 replayed the journal and everything seemed fine until I found some weird files with mysterious access bits set in some directories. I couldn't delete or move them. Also some files had disappeared and some others corrupted, AFAIK. I took the system down to runlevel one, remounted partitions read-only and run fsck.ext2 on them. It reported hundreds if not thousands blocks belonging to more than one inode.
This may just be some weird hardware failure but it just sounds too coincidental. The box has been rock stable for at least a year in its current h/w setup. I've been testing 2.2.20's fine on many machines before, both with ext3 and ext2. Now that I restored the old system from backups it's running on 2.2.19+ext2 again quite happily.
I'd like to know if anyone else has had problems that may be related to ext3? I'm still running it on my personal boxen but it seems that our servers won't be seeing this new filesystem at least until it appears on Debian Potato, included in the standard 2.2.x kernel release. If ever.
Go learn your tools. There's absolutely no need for cookies. Everything non-persistent cookies can do can be done with query part of the URL or using hidden input elements in forms. Using right tools or toolkits this is completely transparent to you. (And persistent cookies are only evil - any reasonable service like online banking has to identify you anyway each time you log on to the system.)
I have written several large-scale server-side web applications without using cookies, utilizing a database as the data source as well as in storing non-public session data (the less you expose to the user the more vulnerable you are and cookies make it too tempting) in there as well. Guess what: they're all fully usable with Lynx/Links and/or any browser with cookies turned off. No tradeoffs!
Like someone posted into some other discussion here a few days ago, making exploits public probably reduces the need for potential wannabes or semi-blackhats to compete in the field. What's cool in that if you can do the same as 10000 other similar people, as everything is written already. All you need is gcc -o nukem2 nukem.c.
Closing exploits, or further, even all security hole announcements, could rise a hell, engaging all competent-enough wannabes writing exploits to compete with eachother. Once again there would be a social gain by doing the best exploit in the shortest time.
Yet there are still enough script kiddyzzz to cause harm if companies don't deliver patches and if admins don't install them, thus, getting things get fixed. Would Microsoft ever raise an eyebrow to any security hole if there were no public means to exploit them? Only then, outlawed blackhats would overflow buffers and assuming that they were pros, no one wouldn't probably notice anything until one morning something completely different had happened during the night...
Yes, that'd be to easy. Just any perl code would do. We could have a contest of the most readable, self-documenting and clearest perl code, though. But, then again, that might be too hard.
I really wish I had some nice PPC-Mac hardware here now. This reminds me of ShapeShifter on the Amiga. It was a hardware layer emulator that run native 68k-Mac programs natively on my Motorola 68060@60MHz. In that setup, boosted with my S3 powered CyberVision3D board, MacOS (8.x something at the time, IIRC) run fast as hell. I could play DukeNukem on my Amiga.. err, on my Mac :)
Actually it was faster than some clumsy PPC-Macs at the university's computer lab. ShapeShifter booted in 10-15 seconds and you could mount a Mac partition over to Amiga-side for easy file transfer (you could use hdimages or a separate partition for Mac). And I could actually use my virtual Mac for some things my Amiga didn't grok, like converting between certain proprietary movie formats.
With VMWare I'm unfortunately tied to x86 operating systems and as I already run the most viable choice (Linux :-o, IMHO) there's not much use for it.. Macs are good, and they're even better if you don't depend on them wholly.