I'm not sure where he got the 20% figure. The only benchmarks I've seen but native-compiled O'Caml between C and C++ in terms of speed. 20% is a huge hit, I agree. It depends a lot on what the benchmarks are. O'Caml can use 31-bit integers much faster than 32-bit or 64-bit integers. This is for Zinc (O'Caml VM) bytecode. The native compiler may be able to make 32-bit ints just as fast as 31-bit ints. O'Caml memory management is lightyears ahead of ay JVM I'm aware of, but I don't recall how to turn off garbage collection or if it's even possible. I agree that you need to be very careful about using anything but Fortran/C (C++ may be pushing it) in a high-load enterprise server b/c a few percent may make the difference between a practicall down server and a merely laggy server.
Your argument about automatic checks holds no water. If you are worried about the compiler screwing up the checks, then add your own manual bounds checks in the code. Nobody makes compilers that try and be so smart as to detect and remove unnecessary manual bounds checks. You can use your own bounds checks and have the automatic ones as a safety net.
Quite honestly, I'd love to see a version of libc without %e doing anything in format strings, as this would eliminate format string vulnerabilities. Are there compilers out there that will refuse to compile single-arguement printf()s or automagically replace printf(str) with printf("%s", str)? Someone was on crack when they decided they wanted printf to be able to modify its arguments. While I'm griping about libc, who the hell came up with the strncpy syntax? This is a huge source of "off by one" errors. On little-endian systems with a downwad-growing stack (*cough* x86 *cough*) that one null byte overflow is epecially likey to be exploitable.
The first two TM chips had incompatible instruction sets. They want to be able to change everything around underneath without breaking anything. Think of the code morphing engine as an optimizing microcode engine that's too big to fit into hardware. You aren't allowed to compile things to P4 microcode in your userspace binaries and you won't be allowed to compile things to Astro native instructions for userspace binaries. It's a black box and that's the way TM wants it. If you did compile to native Astro instructions, you'd want to be careful to format them such that they were still optimizable at runtime.
The hardware and code morphing software were designed for eachother, and the x86 ISA doesn't enforce bounds checking or an object model, so the overhead shoould be much lower than a JVM. I'm not so sure you get much of a performace increase by using Astro native code.
For the record, I think anyone that molests, exploits, or otherwise harms children should be locked up for a very very long time in addition to mandatory extnsive mental health treatment. I think the FBI should also increase efforts to hunt down producers of kiddie porn.
I also believe racial discrimination is wrong.
Would I post links to kiddie porn or neonazi sites? No. Do I believe it's wrong to post links to such sites? No.
There's a lot of sick stuff out there. Save your strength for getting at the root of the problems. To me, it seems that posting kiddie porn is disgusting, but it's more of a record of a past crime. I certainly feel that its production is far worse than its distribution. If you wipe out production, the existing stuff doesn't go away, but the crime of distribution is a lesser crime. The argument could be made that distributing kiddie porn is a thought crime.
What about 17-year-olds in porn produced in countries where 17, not 18 is the legal limit? What about showing penetration in countries where it's illegal to show penetration? (Someone told me that in Japan they can't show penetration but 17-year-olds in porn is legal. That would mean that Japan and the US can each legally produce porn that's illegal in the other country.) What about 18-year old girls pretending to be underage in porn? It's all a big mess. Take budgets away from futile internet censorship attepts and use the money to more effectively go after child exploiters/molesters/pornographers. If busting distribution rings helps you go after the producers, then more power to you. However, don't think that erasing sicko's hard drive is helping some poor kid get out of an exploitive situation.
The Freenet web client contains a link to The Freedom Engine, which puts up links to anything submitted to be linked to without judgement.
"We support free speach." sounds a lot better than "We support free speach, except when it comes to pedophiles. Oh, and Neo-Nazis. No mp3s either, since most of those are illegally posted. Oh, and we also don't put up links to sites that think women should be allowed outside without their faces hidden because that might also offend some people in certain cultures." If you only support free speach on your own terms, you don't support free speach. Stop kidding yourself.
Ah yes, the equivalency of workers myth. I can design good secure network protocols and code up crypto algorithms. If I wrote educational software for your kids in thier spare time, they'd be looking at ascii art images of data flow diagrams. Do you really want your kids using educational software that I write? I suppose I could write up an ascii art app of a puppet teaching kids to count, but that would only teach your kids to hate counting. On the other hand, crypto is great, but if your 4-year old can perform differential cryptanalysis on STEA, then your kid gets classified as a weapon of mass destruction and put in a bunker in Oklahoma with VX warheads, and I don't want that kind of bad karma. I can write good crypto education software for your 4-year old or I can write crappy story reading software for your 5-year old or I can write a 2048/256-bit encrypted asynchronous message passing P2P freamework. Nobody wants me writing educational software. Besides, it's my free time. I don't complain about your Bedoin chant porn habbit, so why do you complain about the software I write in my spare time?
Besides, if I wrote crypto education software for children, the Chinese would just say "screw CPUs, in 10 years we can have a beowurf cruster of crypto cracking kids". They draft 2 million 5-year olds and in 10 years they have more crypto theorems than they know what to do with. Falungong and the democracy movement can't keep any communications secret and the world is a worse place.
You know what? By your logic, everyone in the world should drop what they're doing and go work on a cure for cancer. Let's see. I've got some Windex. I'll start out testing Windex on oncomice! No? What's wrong? I'm an MIT student and most people think I'm pretty smart, but very few people want me doing cancer/ebola/HIV/SARS research.
What about those guys that keep writing yet another Sawfish theme? Do you think they should be helping Apache run faster instead? I don't think so. They have graphics talent and enjoy the work. To get them to work where they have little talent or interest would make crappy sftware and sad programmers. I say even if not one person uses their next Sawfish theme, they've still made the world a better place by making themselves happy with honest endevours.
Freenet uses a random flat distribution of port numbers above 1024. You can manually set the port number if you want, but it's set to a random value at install time. Have fun blocking the unprivledged ports, ALL of them. BTW, it is possible to create a protocol for which ALL of the data looks like random noise. The timings and sizes of the packets will still work against you, but that can also be minimized.
Or, you could use SSL/TLS, IPSec, and/or IPv6 encryption and hide your higher-level protocol headers. You'd still have to be careful about traffic analysis, but ISPs can't start breaking SSL connections mid-trasfer based on statistical analysis of the datastream b/c of computational and memory costs, as well as costomers getting pissed of that their online shopping experience has gone to hell.
If you didn't mind patching your kernel or running freenet as root, you could also run it on port 443 (https). The current implementation does not use SSL, but an emergency switch could be made.
More strictly speaking, the document also gets cached on all of the nodes on the return search path. If you're the secret police of Farkistan trying to find who has embarassing videos of human rights violations, you end up spreading those embarassing videos all over the net. "Of course it's on my hard drive, you put it there by the shear act of looking for it, genius."
Unencrypted dmg files should be mountable via the loopback device under Linux. If you're really really lucky, all of the encryption details are identical to loop-AES, but I doubt it.
The Linux encrypted loopback device (loop-AES) is great. You can use a regular file or a raw block device/partition to store the data.
I really wish there was a cross-platform standard for volume encryption. My understanding is that with AES-256, loop-AES takes my passphrase and generates two 256-bit keys with SHA-512. The block number is encrypted using the first key to generate the initialization vector for the block, then the initialization vector and the secon key are used with AES in CBC mode to encrypt the 512-byte block. Any block device that uses blocks that are a multiple of 512 bytes can be used with loop-AES. I could be wrong on the details, but the documentation mentions SHA-512 and CBC mode, rather than SHA-256. How do Macintosh encrypted drive images work? What about OpenBSD encrypted partitions?
I got tired of small errors in my passphrase preventing me from mounting/home, so I backed everything up and wiped the encypted partitions clean. I base64-encoded some data from/dev/random and piped it through gpg and into a file in/root. On startup, I log in as root and gpg -d hda2.keyfile | mount -p 0/dev/hda2. If I screw up the passphrase, gpg catches it and prompts me again instead of mount trying to work with a garbled decryption. This also allows me to change the passphrase without changing the device encryption keys. I've heard of people writing setuid scripts to do similar things where the actual volume encryption keys were innacessable to the unprvledged users that were mounting the encrypted devices.
One not of caution: dd if/dev/zero of=/dev/loop0 bs=512 several times with different random encryption keys is a good way to blank a partition, but it really stress tests an old drive. I've had a drive fail while being overwritten with encrypted zeros. Cheap OEM IDE drives aren't designed to have their write bandwidth maxed out for extended periods after several years of use.
Built in Zip encryption is very very flawed. GPG/PGP encrypted zip files are fine, OTOH. Just so people know, Zip encryption is much much weaker than DES or 40-bit RC4.
DES and RC4 are just about as different as two symeteric ciphers can be. If you were referring to DES, you left out one of the most important aspects, the non-linear substitutions (via the sboxes). DES's simple permutation key schedule is a weakness. (Key complementation properties, weak and semiweak keys, etc.) The initial and final permutations make no difference to its security in ECB or CBC modes. The expansion permutation is really the only permutation that does much for security.
I can code RC4 up from memory. It's a simple algorithym and the keystream output is independent of the plaintext. DES on the other hand has several tables and permutations to memorize if you want to code it from memory. I'm not aware of anyone ever coding up DES from memory. DES is a block cipher, and is not a stream cipher in it's bare form.
Symmetric keys use XORs are permutations to encrypt and are generally faster.
Somebody set us up the cipher?... parse error, brain dumping core.
Maybe you read a bit on RC4 and picked out a few key words. The RC4 stream cipher is dirt simple, blazingly fast, and consists of only addition, XOR, and swapping of single bytes within a 256-byte buffer. Unfortunately, it has some serious caveats, such as discarding the first 256 bytes of keystream and taking care to never repeat keys.
Stream ciphers are most commonly produced by taking the output of a keyed pseudorandom function (which may also take previous plaintext/ciphertext as input, most notably a black cipher in CFB mode), known as the keystream, and XORing it with the plaintext to geerate the ciphertext.
Germany has sensible crypto laws and a government some what clueful on OSS and monopolistic abuses. They also have some interesting microkernel reserch going on over there. I was just starting to think it would be a good place to go to grad school. If this passes I'm back to the old drawing board.
"Better" in terms of speed, which is what is under discussion here.
Thanks for the clarification. As I mentioned, that's what it seemed like you were saying. However, your post basically said "Subject: not slow. Squeek's VM is better AND there's a JIT available." This could be translated to "Subject: not slow. Squeek's VM is better AND faster." Where "better" is undefined.
Both features and speed are being discussed in the article (which I assume is what you meant by "here").
Perl has no bytecode engine. Based on that, I'm assuming the author of the parent content hasn't really done any reasearch. 'Nuff said.
The perl bytecode engine is not exposed to the ouside world. However, perl code is compiled to bytecode intrernally each time a script is executed.
Perl 6 will expose its bytecode engine (Parrot) to the outside world.
I'm too lazy to make these HTML,but here are a few I found on Google in 2 minutes.
http://hotwired.lycos.com/packet/garfinkel/97/01/i ndex2a.html
http://dev.perl.org/perl6/pdd/pdd01_overview.html
About a month ago a friend was explaining a 3d file browser for Win XP to me. (I forget the name of the program.) I started asking questions, and it turns out that it's really a 1-D file browser with cool 3d visuals. It's harder to mouse though stuff compared to the standard XP GUI, and the keyboard commands move you in either direction in its 1d internal representation. The only cool thing was that all images and movies had previews instead of icons. It was really cool to see some fnd of color-coded 2d FFT image as the preview of each mp3. However, it was slow as hell, and like I said, it really encouraged 1d navigation rather than 2d navigation like I normally use (3d if you count vrtual desktops).
It wouldn't be too difficult to write an "OS" that represented objects in an n-torus, projected onto 2-space (this 3d "OS" ends up projecting everything onto 2-space in order to display on your monitor). However, this wouldn't be superior to the current 2d systems for most people. The current 2d systems are pretty fast for navigation and are visually simple. 3d isn't inherently faster. Sure, you can get higher visual density, but how does it affect navicability and eye strain? Current systems of virtual desktops and layered windows provide users with "2.5 dimensional" navigation, and this seems pretty optimal. It's the same way you desk is organized, with a large stackable 2d surface with auxilary stackable 2d surfaces (drawers = virtual desktops) . Why isn't you desk a stack of clear plastic cubes? Wouldn't a 3d desk be better than current 2.5d desks? I don't see a compelling reason why this would be the case. Maybe 3d really is a panacea, and up until now 3d file browsers have just been poor implementations of an amazing idea. However, my experience so far has reminded me of WinAmp visualizations and other eye candy for 1d file browsers.
Re:not slow
on
Opencroquet
·
· Score: 4, Insightful
Squeak's byte code engine is better than Perl's or Python's, and there is a JIT available (although it's nowhere near as good as Sun's JIT for Java).
Better in what way? I'm not trying to be argumentative. For all I know, the Squeak VM allows a 486 DX2 at 66 MHz to pump out 3 teraflops on.2 watts and has been shown to cure cancer in lab rats.
"Better" really doesn't say much. You might as well have made up a word or posted in Linear B.
Are you talking about inherent superiority of the VM spec? Is the design simpler? Is the set of opcodes smaller or more orthogonal without sacrificing speed or functionality? Has it supported non-blocking I/O, continuances, higher order functions, and generics/templates from day 1? (Can you tell I'm a Java programmer that hated not getting java.nio.* until Java 1.4? Now for generics and continuances...) Did Dijkstra, Turing, Ken Thompson, Xavier Leroy, Ross Andersen and Linus spend a year in seclusion atop Mount Araraat inside Noah's Ark designing a VM spec that was pretty-printed by the hand of God Almighty on the one remaining wall of Solomon's temple? Is the set of opcodes inherently faster or does it result in more compact binaries? Is the set of opcodes well chosen to be easily implemented on most architectures? Is the size of an int clearly defined in the spec (as I remember, both Perl and Python say "at least 32 bits", which is a horrible spec if you want your code to run the same across architectures)? Does the set of opcodes lend itself to rapid compilation of efficient bytecode from many source language families? Are the bytecode operations and file formats well suited to JITs? Does the VM design not force a single object model on the code? Does the opcode format offer security benefits such as efficient real-time security checks on untrusted code? Are there other ways in which the design is "cleaner", "leaner", or "more efficient".
Are you refering to the design of the curent VM implementation rather than the spec itself? Is the current VM better documented in both English and Tamil? How about clean interfaces or easy extensibility of the VM?
Are you talking about the implementation of the current bytecode engine? Is the source code for the VM well commented in Englsih and Thai? Is the entire VM and libraary set implememted in 5,000 lines of Objective C? Is the current VM available in C, Java, Scheme, Haskel, and Intercal implementations?
I suspect you mostly meant "the current canonical implementation is very fast". The speed of the current VM is much less important than inherent design limitations. If the current VM is 50% as fast as the fastest Perl VM, but is expected to be 25% faster than the fastest JVM in a year, that's much preferable to a 10% speed lead on Perl right now. If you change your VM spec too much or too often, people start jumping ship, but you could completely gut your VM every 2 years and very few people would take notice. You're stuck with your design.
I'd love to hear an analysis of the Squeak VM. I hear about so many well designed VMs that get little mind share while the unwashed masses rave about CLR/Mono without giving good details about why the CLR is inherently cross-language and high performance.
Now then, I would think that a pretty big portion of being considered The Man(tm) in you field is to be able to predict with at least some degree of accuracy where the world is headed. Anyone remember what kind of box they had in '97?
266 MHz PII, 64 MB, 4.3 GB, Matrox Millenium II 4 MB, SoundBlaster awe64. I would guess a 200 MIPS SPARC would perform about that well. He had the performance estimate about right, he just didn't properly anticipate chip designers being able to squeeze so much longevity out of the hard-to-decode x86 instruction set and assumed they'd go the easier route of discarding the thing.
My 266 MHz PII now has 288 MB of RAM and a total of about 30 GB of HD. As long as you're running Linux with a good amount of RAM, a PII 266 only shows its age in games and some compilation. Most of the stuff I do is I/O bound in one way or another. I would have upgraded, but I'm deterined to make my next system a 64-bit machine. I'm not sure if I'm going to go x86-64 or POWER4/G5.
I dual boot 2.2 and 2.4 kernels. My Fuji FinePix digital camera and IBM USB keyboard appear to not interface with kernels in the 2.2 series. (I'm the only person I know to run dual keyboards.) However, I bought a VMWare 2.x license and don't want to shell out $300 for the latest VMWare version until there's a version that supports the Linux 2.6 kernels. I've so far resisted the temptation to grab a VMWare keygen or cracked version.
Yup, the Infinate Corridor is open 24/7, but at least every couple of minutes you have some weary student or custodial staff member in some part of the corridor.
There's a small computer lab just of the infinate that has an electronic (not Simplex) pushbutton lock. It has a large floor-to-cieling set of windows and is affectionately called the "fishbowl" due to your abilty to observe the students in the lab from the Infinate Corridor. My guess is that they'll either make a sturdy display case or put it inside the fish bowl, facing outwards. MIT students also have better things to do that mindlessly destroy MIT property. Occasionally they accidently ruin some alarm sensor they were trying to bypass, but vandalism is pretty rare and theft is somewhat rare.
Breaking and entering with intent to create something creaive and easily removable is about the most the average MIT student is willing to risk getting kicked out of MIT for.
It isn't a root kit, but it has many vendor-supplied "value-added" root kits. Remember the "Netscape engineers are weenies" backdoor fiasco? These are features that cannot be disabled, which many MicroSoft haters call by the derogatory name "bugs". They fail to realze the importance of being able to log in to your machine when you spill your coffee on your desk and ruin that post-it-note on the bottom of your keybaord. The *nix world has many fewer password/administrative account recovery tools for use when you get locked out. This is another example of why MS products havea lower TCO.
Slashdot Mirror
Your argument about automatic checks holds no water. If you are worried about the compiler screwing up the checks, then add your own manual bounds checks in the code. Nobody makes compilers that try and be so smart as to detect and remove unnecessary manual bounds checks. You can use your own bounds checks and have the automatic ones as a safety net.
Quite honestly, I'd love to see a version of libc without %e doing anything in format strings, as this would eliminate format string vulnerabilities. Are there compilers out there that will refuse to compile single-arguement printf()s or automagically replace printf(str) with printf("%s", str)? Someone was on crack when they decided they wanted printf to be able to modify its arguments. While I'm griping about libc, who the hell came up with the strncpy syntax? This is a huge source of "off by one" errors. On little-endian systems with a downwad-growing stack (*cough* x86 *cough*) that one null byte overflow is epecially likey to be exploitable.
Thanks for the tip and the complement. I've tweaked the sig a bit now.
The hardware and code morphing software were designed for eachother, and the x86 ISA doesn't enforce bounds checking or an object model, so the overhead shoould be much lower than a JVM. I'm not so sure you get much of a performace increase by using Astro native code.
I also believe racial discrimination is wrong.
Would I post links to kiddie porn or neonazi sites? No. Do I believe it's wrong to post links to such sites? No.
There's a lot of sick stuff out there. Save your strength for getting at the root of the problems. To me, it seems that posting kiddie porn is disgusting, but it's more of a record of a past crime. I certainly feel that its production is far worse than its distribution. If you wipe out production, the existing stuff doesn't go away, but the crime of distribution is a lesser crime. The argument could be made that distributing kiddie porn is a thought crime.
What about 17-year-olds in porn produced in countries where 17, not 18 is the legal limit? What about showing penetration in countries where it's illegal to show penetration? (Someone told me that in Japan they can't show penetration but 17-year-olds in porn is legal. That would mean that Japan and the US can each legally produce porn that's illegal in the other country.) What about 18-year old girls pretending to be underage in porn? It's all a big mess. Take budgets away from futile internet censorship attepts and use the money to more effectively go after child exploiters/molesters/pornographers. If busting distribution rings helps you go after the producers, then more power to you. However, don't think that erasing sicko's hard drive is helping some poor kid get out of an exploitive situation.
"We support free speach." sounds a lot better than "We support free speach, except when it comes to pedophiles. Oh, and Neo-Nazis. No mp3s either, since most of those are illegally posted. Oh, and we also don't put up links to sites that think women should be allowed outside without their faces hidden because that might also offend some people in certain cultures." If you only support free speach on your own terms, you don't support free speach. Stop kidding yourself.
Besides, if I wrote crypto education software for children, the Chinese would just say "screw CPUs, in 10 years we can have a beowurf cruster of crypto cracking kids". They draft 2 million 5-year olds and in 10 years they have more crypto theorems than they know what to do with. Falungong and the democracy movement can't keep any communications secret and the world is a worse place.
You know what? By your logic, everyone in the world should drop what they're doing and go work on a cure for cancer. Let's see. I've got some Windex. I'll start out testing Windex on oncomice! No? What's wrong? I'm an MIT student and most people think I'm pretty smart, but very few people want me doing cancer/ebola/HIV/SARS research.
What about those guys that keep writing yet another Sawfish theme? Do you think they should be helping Apache run faster instead? I don't think so. They have graphics talent and enjoy the work. To get them to work where they have little talent or interest would make crappy sftware and sad programmers. I say even if not one person uses their next Sawfish theme, they've still made the world a better place by making themselves happy with honest endevours.
Or, you could use SSL/TLS, IPSec, and/or IPv6 encryption and hide your higher-level protocol headers. You'd still have to be careful about traffic analysis, but ISPs can't start breaking SSL connections mid-trasfer based on statistical analysis of the datastream b/c of computational and memory costs, as well as costomers getting pissed of that their online shopping experience has gone to hell.
If you didn't mind patching your kernel or running freenet as root, you could also run it on port 443 (https). The current implementation does not use SSL, but an emergency switch could be made.
More strictly speaking, the document also gets cached on all of the nodes on the return search path. If you're the secret police of Farkistan trying to find who has embarassing videos of human rights violations, you end up spreading those embarassing videos all over the net. "Of course it's on my hard drive, you put it there by the shear act of looking for it, genius."
Unencrypted dmg files should be mountable via the loopback device under Linux. If you're really really lucky, all of the encryption details are identical to loop-AES, but I doubt it.
I really wish there was a cross-platform standard for volume encryption. My understanding is that with AES-256, loop-AES takes my passphrase and generates two 256-bit keys with SHA-512. The block number is encrypted using the first key to generate the initialization vector for the block, then the initialization vector and the secon key are used with AES in CBC mode to encrypt the 512-byte block. Any block device that uses blocks that are a multiple of 512 bytes can be used with loop-AES. I could be wrong on the details, but the documentation mentions SHA-512 and CBC mode, rather than SHA-256. How do Macintosh encrypted drive images work? What about OpenBSD encrypted partitions?
I got tired of small errors in my passphrase preventing me from mounting /home, so I backed everything up and wiped the encypted partitions clean. I base64-encoded some data from /dev/random and piped it through gpg and into a file in /root. On startup, I log in as root and gpg -d hda2.keyfile | mount -p 0 /dev/hda2. If I screw up the passphrase, gpg catches it and prompts me again instead of mount trying to work with a garbled decryption. This also allows me to change the passphrase without changing the device encryption keys. I've heard of people writing setuid scripts to do similar things where the actual volume encryption keys were innacessable to the unprvledged users that were mounting the encrypted devices.
One not of caution: dd if/dev/zero of=/dev/loop0 bs=512 several times with different random encryption keys is a good way to blank a partition, but it really stress tests an old drive. I've had a drive fail while being overwritten with encrypted zeros. Cheap OEM IDE drives aren't designed to have their write bandwidth maxed out for extended periods after several years of use.
Built in Zip encryption is very very flawed. GPG/PGP encrypted zip files are fine, OTOH. Just so people know, Zip encryption is much much weaker than DES or 40-bit RC4.
I can code RC4 up from memory. It's a simple algorithym and the keystream output is independent of the plaintext. DES on the other hand has several tables and permutations to memorize if you want to code it from memory. I'm not aware of anyone ever coding up DES from memory. DES is a block cipher, and is not a stream cipher in it's bare form.
No, becuase it was a joke, an exageration for the sake of humor.
I'm sure I'm not being argumentative, jus tryingto flush out some of the billions of things that could be meant by "better".
wrong verb tense
Somebody set us up the cipher? ... parse error, brain dumping core.
Maybe you read a bit on RC4 and picked out a few key words. The RC4 stream cipher is dirt simple, blazingly fast, and consists of only addition, XOR, and swapping of single bytes within a 256-byte buffer. Unfortunately, it has some serious caveats, such as discarding the first 256 bytes of keystream and taking care to never repeat keys.
Stream ciphers are most commonly produced by taking the output of a keyed pseudorandom function (which may also take previous plaintext/ciphertext as input, most notably a black cipher in CFB mode), known as the keystream, and XORing it with the plaintext to geerate the ciphertext.
Germany has sensible crypto laws and a government some what clueful on OSS and monopolistic abuses. They also have some interesting microkernel reserch going on over there. I was just starting to think it would be a good place to go to grad school. If this passes I'm back to the old drawing board.
Thanks for the clarification. As I mentioned, that's what it seemed like you were saying. However, your post basically said "Subject: not slow. Squeek's VM is better AND there's a JIT available." This could be translated to "Subject: not slow. Squeek's VM is better AND faster." Where "better" is undefined.
Both features and speed are being discussed in the article (which I assume is what you meant by "here").
The perl bytecode engine is not exposed to the ouside world. However, perl code is compiled to bytecode intrernally each time a script is executed.
Perl 6 will expose its bytecode engine (Parrot) to the outside world.
I'm too lazy to make these HTML,but here are a few I found on Google in 2 minutes.i ndex2a.html
http://hotwired.lycos.com/packet/garfinkel/97/01/
http://dev.perl.org/perl6/pdd/pdd01_overview.html
It wouldn't be too difficult to write an "OS" that represented objects in an n-torus, projected onto 2-space (this 3d "OS" ends up projecting everything onto 2-space in order to display on your monitor). However, this wouldn't be superior to the current 2d systems for most people. The current 2d systems are pretty fast for navigation and are visually simple. 3d isn't inherently faster. Sure, you can get higher visual density, but how does it affect navicability and eye strain? Current systems of virtual desktops and layered windows provide users with "2.5 dimensional" navigation, and this seems pretty optimal. It's the same way you desk is organized, with a large stackable 2d surface with auxilary stackable 2d surfaces (drawers = virtual desktops) . Why isn't you desk a stack of clear plastic cubes? Wouldn't a 3d desk be better than current 2.5d desks? I don't see a compelling reason why this would be the case. Maybe 3d really is a panacea, and up until now 3d file browsers have just been poor implementations of an amazing idea. However, my experience so far has reminded me of WinAmp visualizations and other eye candy for 1d file browsers.
Better in what way? I'm not trying to be argumentative. For all I know, the Squeak VM allows a 486 DX2 at 66 MHz to pump out 3 teraflops on .2 watts and has been shown to cure cancer in lab rats.
"Better" really doesn't say much. You might as well have made up a word or posted in Linear B.
Are you talking about inherent superiority of the VM spec? Is the design simpler? Is the set of opcodes smaller or more orthogonal without sacrificing speed or functionality? Has it supported non-blocking I/O, continuances, higher order functions, and generics/templates from day 1? (Can you tell I'm a Java programmer that hated not getting java.nio.* until Java 1.4? Now for generics and continuances...) Did Dijkstra, Turing, Ken Thompson, Xavier Leroy, Ross Andersen and Linus spend a year in seclusion atop Mount Araraat inside Noah's Ark designing a VM spec that was pretty-printed by the hand of God Almighty on the one remaining wall of Solomon's temple? Is the set of opcodes inherently faster or does it result in more compact binaries? Is the set of opcodes well chosen to be easily implemented on most architectures? Is the size of an int clearly defined in the spec (as I remember, both Perl and Python say "at least 32 bits", which is a horrible spec if you want your code to run the same across architectures)? Does the set of opcodes lend itself to rapid compilation of efficient bytecode from many source language families? Are the bytecode operations and file formats well suited to JITs? Does the VM design not force a single object model on the code? Does the opcode format offer security benefits such as efficient real-time security checks on untrusted code? Are there other ways in which the design is "cleaner", "leaner", or "more efficient".
Are you refering to the design of the curent VM implementation rather than the spec itself? Is the current VM better documented in both English and Tamil? How about clean interfaces or easy extensibility of the VM?
Are you talking about the implementation of the current bytecode engine? Is the source code for the VM well commented in Englsih and Thai? Is the entire VM and libraary set implememted in 5,000 lines of Objective C? Is the current VM available in C, Java, Scheme, Haskel, and Intercal implementations?
I suspect you mostly meant "the current canonical implementation is very fast". The speed of the current VM is much less important than inherent design limitations. If the current VM is 50% as fast as the fastest Perl VM, but is expected to be 25% faster than the fastest JVM in a year, that's much preferable to a 10% speed lead on Perl right now. If you change your VM spec too much or too often, people start jumping ship, but you could completely gut your VM every 2 years and very few people would take notice. You're stuck with your design.
I'd love to hear an analysis of the Squeak VM. I hear about so many well designed VMs that get little mind share while the unwashed masses rave about CLR/Mono without giving good details about why the CLR is inherently cross-language and high performance.
266 MHz PII, 64 MB, 4.3 GB, Matrox Millenium II 4 MB, SoundBlaster awe64. I would guess a 200 MIPS SPARC would perform about that well. He had the performance estimate about right, he just didn't properly anticipate chip designers being able to squeeze so much longevity out of the hard-to-decode x86 instruction set and assumed they'd go the easier route of discarding the thing.
My 266 MHz PII now has 288 MB of RAM and a total of about 30 GB of HD. As long as you're running Linux with a good amount of RAM, a PII 266 only shows its age in games and some compilation. Most of the stuff I do is I/O bound in one way or another. I would have upgraded, but I'm deterined to make my next system a 64-bit machine. I'm not sure if I'm going to go x86-64 or POWER4/G5.
I dual boot 2.2 and 2.4 kernels. My Fuji FinePix digital camera and IBM USB keyboard appear to not interface with kernels in the 2.2 series. (I'm the only person I know to run dual keyboards.) However, I bought a VMWare 2.x license and don't want to shell out $300 for the latest VMWare version until there's a version that supports the Linux 2.6 kernels. I've so far resisted the temptation to grab a VMWare keygen or cracked version.
There's a small computer lab just of the infinate that has an electronic (not Simplex) pushbutton lock. It has a large floor-to-cieling set of windows and is affectionately called the "fishbowl" due to your abilty to observe the students in the lab from the Infinate Corridor. My guess is that they'll either make a sturdy display case or put it inside the fish bowl, facing outwards. MIT students also have better things to do that mindlessly destroy MIT property. Occasionally they accidently ruin some alarm sensor they were trying to bypass, but vandalism is pretty rare and theft is somewhat rare.
Breaking and entering with intent to create something creaive and easily removable is about the most the average MIT student is willing to risk getting kicked out of MIT for.