Unless I'm mistaken, there's a card in the back you can send in to have a disk sent to you. The only reason you don't get the software on a disk to begin with is because that would increase production costs.
To be a bit pedantic, resource forks aren't what make this work anymore. Although HFS resource forks are still supported under OS X (from the command line, try less path/to/file/rsrc to view the resource fork!) but they are officially deprecated for Cocoa apps. Multiple binaries are supported by putting several binaries in the data fork of the file -- the MachO standard allows for this, as you said.
I guess you could go up to 16GB then, assuming you have the $$. Oughta tell Apple about this for extra marketing hype (not that they need it; the G5's been eagerly awaited for about forever)...
Do note that sllort's comment was in reply to fyodor's own comment, in which he notes (among other things) that sdem is a known troll. (In the page referenced, he notes that he's currently impersonating Theo De Raadt. sdem is obviously not to be trusted.
Apparently the claims that fyodor had hacked a kid's machine were falsified. The same person who first claimed this had happened recently said (sorry, no references -- someone back me up?) that he was trolling, and that he's now moved on to another target.
It does -- in fact, the Fink project has it precompiled for you -- but it's really quite slow and suffers from the same workflow diconnectedness as xterm. Stick to xterm if you like OS X X11.
Wasn't it in the Hyperion series (by Dan Simmons) in which the backstory included a scientific research project -- the Kiev Project -- which created a number of small black holes which sunk to the earth's core, destroying the planet over a period of several hundred years?
This article is about the Menlo School, and was posted by a friend of mine. Menlo has more like 100 or 200 computers, so the task isn't really quite as gigantic as it seems by the article. Still...
For "electrical power" read "processing power". At least, that's what I did. Makes a good deal more sense that way, and you don't even have to break the laws of thermodynamics.
Nope. Uuencoding decreases the entropy per character from a maximum of 8 bits per character to a maximum of 6 bits per character. The total entropy is kept constant. The only way you can increase the entropy of a message is by adding pseudorandom data to it somehow.
Please read a book on cryptography --- I'd recommend Applied Cryptography by Bruce Schneier (sp?).
Actually, most serious encryption packages (as opposed to algorithms) compress the data before they encrypt it. This increases the entropy-per-bit of the data being encrypted, making it harder to break.
It is true, though, that many encryption systems don't compress. This makes them weaker, though, and it's why PGP compresses the text (using gzip, I think) before encrypting it.
First of all, you probably mean 160Kbps, as 162 is not a standard MP3 or AAC bitrate.
Secondly, AAC (not ACC) works "better" as a compressor than MP3 does, not even taking into consideration the fact that the iTunes MP3 encoder sucks. So 160Kbps (or even the Apple Music Store's 128Kbps) AAC files will sound just fine, I hope.
LFS is a set of instructions for creating a Linux installation to do, well, whatever. If you want these features, you can go ahead and implement them yourself, because that's what LFS is for.
Never gonna happen. All that WineX does is emulate Win32 API calls -- it doesn't touch the x86 assembly. If you want to run Windows games on your Mac, use VirtualPC (Bochs is painfully slow).
The cryptography code in SSH has never been cracked, AFAIK. The code that *has* been cracked is general-purpose networking code, I think -- the error exploited has generally been a buffer overflow.
This is NOT a "mistake while doing cryptography", it is a mistake programming normal code. If you only had access to the content flowing over the network, SSH would be uncrackable, as far as anybody knows.
Slashdot Mirror
Unless I'm mistaken, there's a card in the back you can send in to have a disk sent to you. The only reason you don't get the software on a disk to begin with is because that would increase production costs.
To be a bit pedantic, resource forks aren't what make this work anymore. Although HFS resource forks are still supported under OS X (from the command line, try less path/to/file/rsrc to view the resource fork!) but they are officially deprecated for Cocoa apps. Multiple binaries are supported by putting several binaries in the data fork of the file -- the MachO standard allows for this, as you said.
The Places sidebar also shows up in Open/Save windows. Try getting stuff from the Dock to show up in file dialogs...
I have heard from several insiders that Panther actually runs better than Jaguar did on low-end machines.
I guess you could go up to 16GB then, assuming you have the $$. Oughta tell Apple about this for extra marketing hype (not that they need it; the G5's been eagerly awaited for about forever)...
> Why only 8-gig of RAM? Because there are only eight slots to put the DIMMs into. Physical limitations strike again!
Do note that sllort's comment was in reply to fyodor's own comment, in which he notes (among other things) that sdem is a known troll. (In the page referenced, he notes that he's currently impersonating Theo De Raadt. sdem is obviously not to be trusted.
Apparently the claims that fyodor had hacked a kid's machine were falsified. The same person who first claimed this had happened recently said (sorry, no references -- someone back me up?) that he was trolling, and that he's now moved on to another target.
What was wrong with file permissions under previous versions?
It does -- in fact, the Fink project has it precompiled for you -- but it's really quite slow and suffers from the same workflow diconnectedness as xterm. Stick to xterm if you like OS X X11.
Wasn't it in the Hyperion series (by Dan Simmons) in which the backstory included a scientific research project -- the Kiev Project -- which created a number of small black holes which sunk to the earth's core, destroying the planet over a period of several hundred years?
Whoops, screwed up the link. (Wrong TLD.) Try this one instead.
Obligatory link: Make sure to defraggle your motherdisk!
This article is about the Menlo School, and was posted by a friend of mine. Menlo has more like 100 or 200 computers, so the task isn't really quite as gigantic as it seems by the article. Still...
For "electrical power" read "processing power". At least, that's what I did. Makes a good deal more sense that way, and you don't even have to break the laws of thermodynamics.
Please read a book on cryptography --- I'd recommend Applied Cryptography by Bruce Schneier (sp?).
It is true, though, that many encryption systems don't compress. This makes them weaker, though, and it's why PGP compresses the text (using gzip, I think) before encrypting it.
Secondly, AAC (not ACC) works "better" as a compressor than MP3 does, not even taking into consideration the fact that the iTunes MP3 encoder sucks. So 160Kbps (or even the Apple Music Store's 128Kbps) AAC files will sound just fine, I hope.
Just build a LFS system under chroot (or on a partition), write some nice installer scripts, and burn it to a CD. Have fun ;-)
LFS is a set of instructions for creating a Linux installation to do, well, whatever. If you want these features, you can go ahead and implement them yourself, because that's what LFS is for.
Impossible. Wine doesn't emulate the x86 instruction set.
Never gonna happen. All that WineX does is emulate Win32 API calls -- it doesn't touch the x86 assembly. If you want to run Windows games on your Mac, use VirtualPC (Bochs is painfully slow).
Hah! I was the one who stuck around after the talk to berate MP3 for silly metadata setup. Hope you don't mind the hordes of visitors too much.
This is NOT a "mistake while doing cryptography", it is a mistake programming normal code. If you only had access to the content flowing over the network, SSH would be uncrackable, as far as anybody knows.