If your VTs are missing (and chances are pretty good that, if you can get into X, you can't start an xterm) you likely forgot to mount the devpts filesystem.
Try `mount -t devpts devpts/dev/pts` and see if that resolves it; if so, add the appropriate entry to your fstab.
People should read the article before modding things 'Interesting.'
In a word, no.
What Plextor has done is shorten the pits on the CDROM. If you unroll a CDROM and look at it as a linear track, they've effectively made it longer. (Yes, CDROMs are spirals, unlike most magnetic disks.) So for a given linear space, you get more bits, and presumably more throughput, though the article doesn't specify. It's a lot like reformatting 720k floppies as 1.44 (which is possible, as long as you poke a hole in the corner).
So while you're dead-on in slamming proprietary compression schemes, you're wrong about compressing compressed data. I'm sure it'll work just fine.
Yup, just as many of us have not forgotten that the K in KDE is for Kool, or was originally. I wonder why they didn't call it CDE...erm, wait....
But, though KDE is still quite kool if your spelling is atrocious, FVWM need not necessarily be Featherweight in name or functionality. Acronyms can change. Take good ol' Personal Home Page.
You mean reducing RAM latency doesn't increase bandwidth?!?!#%!1 d00d!
*sigh*
This benchmark would have been vastly more informative if the guy had gotten his tests and statistics right. First, he needs to learn the difference between a median and a mean, which are very different. Second, actually testing latency might have been nice, considering that one of his independent variables is CAS latency. Not to mention the fact that the hardcoded pixel widths in the stats table are horribly wrong on a high-DPI system. People! The em is your friend!
So basically what we have here is this:
Independent variables: bus speed (read: bandwidth), CAS latency, interleave (read: latency/bandwidth).
Dependent variables: bandwidth
Quite frankly, if I had submitted this experimental design, my advisor would still have me tied to a table in the back end of the psych building. He's not measuring what he's manipulating, and throwing in a two-factor confound like bank interleave without compensating (though the article may be misleading) just skews the measurements.
Ah, well. I'll go back to my completely untweaked Athlon and be happy.:-)
Just to explain, for any who aren't familiar with the FreeBSD release process:
FreeBSD 4.8 will be the latest release from the FreeBSD 4-STABLE branch. This could also be thought of for the time being as the -STABLE branch, as there is not yet a 5-STABLE. A lot of the goodies from 5.0 (5-CURRENT) have been merged-from-current (MFC'd) into 4.8, including Firewire and bugfixes. It's GCC2-based, and I run it on my laptop with much luck, though it lacks a lot of the ACPI goodness in 5.
5.0 is a release from 5-CURRENT. Just as they did with 4.0 before, it is released before there is a formal -STABLE branch, which is expected to appear somewhere around 5.1 or 5.2. I use it on all my workstations, and it flies -- GCC3-based, with new kernel magic that has (at least for me) dramatically improved responsiveness.
Which is no small feat, since my FreeBSD/KDE desktops consistently outperform my equivalent Linux machines in terms of, say, running two makes while playing a song over NFS with no skips. (These are k6-2 machines, one with FreeBSD5, one with Gentoo.)
The 4.0 branch will continue to be developed well into the lifetime of 5, just as 3.0 was before it. (Development on 3-STABLE only recently slowed down; it benefited from most of the bugfixes in 4 that didn't break compatibility.)
My suggestions to someone wanting to run FreeBSD right now? If it's a production machine, I'd stick to 4.7 or 4.8, simply because the ability to track the -STABLE branch with cvsup is really nice. Also, if you're not comfortable with updating your sources and recompiling your world periodically, stick to 4.x; since 5.0 doesn't yet have a controlled -STABLE branch, it will occasionally have broken features, though this has only happened to me once. On the other hand, if you have a recent machine, need good ACPI support, or want to see what all the fuss is about, try 5.0. I use it with great success -- just be warned, you may have to recompile things every so often until it goes -STABLE.
> rather than the current HORRIBLE emulation performance of 32bit apps on 64bit hardware
This is a common misunderstanding. You're probably thinking of the early Itaniums, which emulated x86 as a sort of afterthought and, obviously, had poor performance as a result. What the article refers to is AMD's x86-64 architecture, which can run 32-bit x86 code at full speed, and in fact can host 32-bit processes within a 64-bit OS and vice versa with very little performance hit. However, from what I've heard, the more recent Itaniums handle x86 a -lot- better. Take that with appropriate salt, of course.
I think perhaps you may be confusing this release with Sun's native port. That's not what this is, though we've been waiting for that for some time (Dec.2001, I believe).
What this is is an upgrade to the eyesbeyond patchset used to build JDK1.2 and 1.3 before. It's been merged into the ports tree, hence the announcement; it allows you to build a native FreeBSD JDK using the Sun sources and, for boostrapping, the Linux binaries.
Unless something massive and invisible has happened that I missed, there will be no binary packages as a result of this release, because of Sun's licensing. If you'd taken the time to build the port in question, you'll note that you still have to go through a clickwrap to obtain the sources from Sun; it doesn't auto-fetch like most ports. Until Sun's native port is released, don't expect a native FreeBSD binary JDK unless you build one yourself.
Nope, not like Parrot, because the JVM and CLI are not like Parrot. There are a lot of differences, but the two main ones are: -Static typing. -Stack-based (vs. register-based)
The JVM and CLI are both designed for static-typed languages, like Java, C, C++, C#. Parrot's main deviation from previous VMs is its design around dynamically-typed languages like Perl and Ruby, with the corresponding techniques to make this fast.
Furthermore, the JVM and CLI are both stack-based, while Parrot is register-based. These involve different optimization techniques and a different underlying virtualization.
The framework described in the Intel paper is most definitely static-type oriented (they discuss the difference in casting-exceptions in C# and Java, and how they handle it), and most probably stack-oriented (though that doesn't seem specified).
This may not be your issue, but the Xft configuration file syntax has changed in a non-backwards-compatible way as of 4.3.0. This will lead to broken font behavior if you're not careful. Is it seeing all of your fonts? Are you still getting antialiasing? If not on either of those, you probably need to tweak your Xft config.
Probably (IANLT) he's referring to the various prefix encodings and variations for instructions. From my x86 manual, "Machine language instructions...vary in length from 1 to as many as 13 bytes....There are over 20,000 variations."
Now, granted, that rather large number probably includes different target registers, but compared to (to use your example) the 68k, the x86's encoding format is just -weird-: 16-Bit: -An opcode. Either 1 or 2 bytes. -Some flags and/or target register. 1 byte, optional -Displacement. 0-2 bytes. -Immediate. 0-2 bytes.
32-Bit: -Optional address size prefix byte. -Optional operand size prefix byte. -Like above, but with 0-4-byte displacement/immediate and optional scaled index byte.
Now consider the fact that many opcodes implicitly reference registers. Decoding this instruction set by hand would be a royal bitch, and it's exactly the sort of configuration that RISC targeted for demise. However, Linus makes a good point in the e-mail, which is (paraphrased) that the x86 encoding is basically a very good compression algorithm for its code. While the RISC machines that use 32 or 64-bits for every instruction may be more regular, their code does tend to be larger.
The ironic thing, in my mind, is that the IA-64's encoding is in many ways -more- baroque than the x86s! Instructions in bundles, bundles in groups (or is it the other way around? I never remember), flags at the end to specify how to interpret the instructions before -- it's an interesting take on VLIW, in that it doesn't specify the number of execution units, but YUCK.:-)
"PDAs typically use processors designed specifically for embedded environments...the PowerPC is exactly the opposite."
Ah, not quite! Just as the presence of Athlons does not mean there are no embedded x86 Elans, the presence of the G4 doesn't mean there are no embedded PowerPCs! Don't confuse the architecture (PowerPC) with the implementation (G4).
The PowerPC has long been a staple of the embedded commuity (by 'long' here I mean 'half a decade or so':-) ). As you'll note from the Macs, chips based on the architecture tend to have low power consumption and the resulting low heat output. However, smaller PowerPC implementations can be found in everything from Cisco routers to TiVos. I know of at least one $25 'residential gateway' DSL router that's a PowerPC.
The PowerPC's proven itself to be an astoundingly flexible architecture, and if IBM says they've got a low-power-consumption chip, I'd believe it, even if they posted good performance figures. As with the ARM, which was also not originally an embedded chip, performance and power consumption are not -always- mutually exclusive.
Also, as far as Linux on the PDA is concerned...I run Linux on my iPaq (and use it as a PDA) and have found it to be smaller and more stable than WinCE, and more stable (though larger) than PalmOS. My distribution of Linux fits handily into 16M of flash, and that includes Qtopia, all my PIM apps, Konqueror, Kinkatta (an AIM client), and various wlan mapping tools. Even my non-Linux friends prefer my 'feudal' Linux PDA -- and this was put together by a bunch of volunteers. I'm really looking forward to see what IBM's got.
This strikes me as both a good and a bad thing. Good, because journalled filesystems are a Good Thing. I use FreeBSD exclusively on both desktop and workstation, and while SoftUpdates is very good, it and journalling have different aims. (SoftUpdates aims to keep all file metadata consistent at all times; journalling aims to keep all file -data- consistent at all times.) Choice is always good, and I could see myself using SoftUpdates on/home and JFS on the maildirs, for example. However, this is a bit of a Bad Thing in that one of FreeBSD's simplicities has always been the One Filesystem, UFS. Granted, UFS has evolved some (UFS-Softupdates and now UFS2) but there was never a question as to which filesystem to choose: UFS has enough tunables, most of them automated, that you can optimize it for small-file, large-file, high-latency, low-latency, etc. I've found it to be capable of keeping up with the various Linux filesystems in their own areas. But if this is merged into -current, there will be a choice to make when preparing a slice. This is one of those things that's hard to change after the fact.:-)
As for me, I'll stick with UFS2 until I see how this shapes up, but tally-ho!
Many of the posters have, I think, misinterpreted what a TiVo is. A TiVo -is- a glorified VCR, but that's not why it has captured geek hearts and minds (mine included). The key is that the TiVo downloads the program guide and parses it, removing any need for you to manually calculate when your shows begin and end, and enabling it to automatically find and record episodes of shows you've watched or shows it thinks you might like.
So chances are, connecting an FM radio to the line-in on a soundcard and scheduling LAME from cron is not quite what was intended here. The original poster notes that some of the stations in question change format frequently during the day, in which case it is doubly important to have some intelligence in the recorder so that it can adapt and pick out the diamonds in the radio rough.
As for my own suggestions, I've actually been giving this some thought recently after getting a radio again (had mine stolen). Something like the GNURadio project, a wideband multichannel receiver, could pull down RDS streams (Radio Data Service, which transmits at least station identification and sometimes program names) and parse them for TiVo-like functionality. Alternatively, you could see if any of the stations in question export their schedules using RSS or some such (some college stations do) or pull down and parse their coming-up-next webpages.
128-bit AES allows for 128-bit keys, so yes, in decimal, 3.4e38-somethingorother (2^128). Yes, this is a greater range than DES (2^56). It's also greater than 3DES using two keys (one for the first and third stage, one for the second, so 2^112). Proper 3DES implementations use three independent keys for an effective keyspace of 2^168.
However, the keyspace of an algorithm is only one of its strengths. It's only relevant if brute force is the fastest way to crack the cipher, which is very rarely the case. In the case of DES, it was refined by the oft-maligned NSA to resist differential cryptanalysis, leaving it resistant against all but brute-force until linear cryptanalysis was 'discovered' in the mid-90s. (To those who still believe the NSA weakened DES, go read your Schneier.)
AES-128 is a new algorithm, but feels good. Brute-forcing a 128-bit keyspace would take several centuries, even taking into account Moore's law, so the difference between it and 3DES's 168 bits isn't relevant. Moreover, there are known exploits against 3DES (even if they aren't terribly helpful), whereas massive scrutiny by cryptanalysis worldwide (while Rijndael was becoming AES) has turned up nothing so far. This doesn't mean there won't be exploits, but it means that the chances that Shamir or one of the other hotshot cryptanalysts is going to bring out a paper tomorrow that invalidates all your work are very small.
So: AES-128 will keep your sister from reading your diary. Unless you believe the NSA has some sort of amazing quantum computing that's forty years beyond consumer tech (which I really, really don't), AES-128 is also likely to keep your files safe from the gimmies for several decades.
Although why the NSA would be interested in, say, my homedir, is beyond me -- the most likely person trying to crack my encryption is probably a jealous girlfriend.:-)
(This is surmised from the e-mail linked from the article, and may be wrong. *grin*)
It sounds like hashes were used because, while they're a performance hit, they're not -that- big of a performance hit. Evaluating a signature (say, RSA or DSA) is more CPU-intensive than MD5 or SHA1. We're talking an order of magnitude here, maybe more. This would have to be done on each load of an executable, shared library, and shell script. Also, a lot of OSen are still resistant to putting potentially restricted crypto into kernel-level systems.
As far as placing the signatures into the ELF binaries, the author discusses that in the e-mail and rejects it for two reasons: 1. Doesn't work for #! shell scripts. A separate fingerprint table does. 2. Putting the signature in the file still allows the file to be replaced, signature and all. Loading the signatures into a kernel table on boot makes it harder to munge them at runtime. It's not just untrusted executables we don't want to allow -- replacing one trusted app with another (say, ls with rm?) can be just as bad.
Beyond that, though, I agree -- signed (rather than simply fingerprinted) files could definitely be a good thing, and I'll be watching to see how all this develops.
I concur, but keep in mind that Apple has always (afaik) made the majority of their income from hardware sales. Were they to move to an easily-cloneable PC platform (i.e. the platform that's evolved from the original IBM PC), they'd have to really move a lot of software to make up! HOWEVER: a lot of people seem to think that that fact alone will prevent them from considering Intel/AMD. I'm not so sure. Granted, all of us would love to be able to run OSX on our existing Athlons, and I doubt that will happen -- but what's to stop Apple from rolling out their own version of the PC architecture? There's a lot of cruft in the ex-IBM PC that could be dropped; with a little work, an x86 machine could be had with all the hardware integrity of a Mac, and just as hard to clone. You may be asking, Why would we want THAT? Two reasons, imho: 1) it would allow them to lower the price (though I doubt they would), and 2) x86 binaries could be run through something closer to Wine than a full-out emulator! Mmmm, compatibility.
Slashdot Mirror
If your VTs are missing (and chances are pretty good that, if you can get into X, you can't start an xterm) you likely forgot to mount the devpts filesystem.
/dev/pts` and see if that resolves it; if so, add the appropriate entry to your fstab.
Try `mount -t devpts devpts
People should read the article before modding things 'Interesting.'
In a word, no.
What Plextor has done is shorten the pits on the CDROM. If you unroll a CDROM and look at it as a linear track, they've effectively made it longer. (Yes, CDROMs are spirals, unlike most magnetic disks.) So for a given linear space, you get more bits, and presumably more throughput, though the article doesn't specify. It's a lot like reformatting 720k floppies as 1.44 (which is possible, as long as you poke a hole in the corner).
So while you're dead-on in slamming proprietary compression schemes, you're wrong about compressing compressed data. I'm sure it'll work just fine.
Yup, just as many of us have not forgotten that the K in KDE is for Kool, or was originally. I wonder why they didn't call it CDE...erm, wait....
But, though KDE is still quite kool if your spelling is atrocious, FVWM need not necessarily be Featherweight in name or functionality. Acronyms can change. Take good ol' Personal Home Page.
> what other 20 year old platform is so dear to our hearts?
:-)
Ha! I spend much of my day developing software for a 26-year-old platform! Beat that!
And that's just BSD. You Linux folks could probably claim 30 years, back to ye olde UNIX.
> Australian police have accessed the DNA database
> without consent in the past, successfully prosecuting an
> unpleasant incest case.
Oh! Well then. As long as they're not prosecuting PLEASANT INCEST CASES.
C'mon, 'unpleasant incest case' is like 'disposable condom' -- it's redundant, and it makes you shudder thinking about the alternatives.
Wow!!!!%#@
You mean reducing RAM latency doesn't increase bandwidth?!?!#%!1 d00d!
*sigh*
This benchmark would have been vastly more informative if the guy had gotten his tests and statistics right. First, he needs to learn the difference between a median and a mean, which are very different. Second, actually testing latency might have been nice, considering that one of his independent variables is CAS latency. Not to mention the fact that the hardcoded pixel widths in the stats table are horribly wrong on a high-DPI system. People! The em is your friend!
So basically what we have here is this:
- Independent variables: bus speed (read: bandwidth), CAS latency, interleave (read: latency/bandwidth).
- Dependent variables: bandwidth
Quite frankly, if I had submitted this experimental design, my advisor would still have me tied to a table in the back end of the psych building. He's not measuring what he's manipulating, and throwing in a two-factor confound like bank interleave without compensating (though the article may be misleading) just skews the measurements.Ah, well. I'll go back to my completely untweaked Athlon and be happy. :-)
I guess you sort of missed OpenZaurus, which addresses all of the concerns you list here? Ah, well, that's okay, you're an AC. :-)
Now we can call them, what, Sheppard moons? But Jupiter's ring is so insignificant!
Ahhhh, astronomy puns.
Just to explain, for any who aren't familiar with the FreeBSD release process:
FreeBSD 4.8 will be the latest release from the FreeBSD 4-STABLE branch. This could also be thought of for the time being as the -STABLE branch, as there is not yet a 5-STABLE. A lot of the goodies from 5.0 (5-CURRENT) have been merged-from-current (MFC'd) into 4.8, including Firewire and bugfixes. It's GCC2-based, and I run it on my laptop with much luck, though it lacks a lot of the ACPI goodness in 5.
5.0 is a release from 5-CURRENT. Just as they did with 4.0 before, it is released before there is a formal -STABLE branch, which is expected to appear somewhere around 5.1 or 5.2. I use it on all my workstations, and it flies -- GCC3-based, with new kernel magic that has (at least for me) dramatically improved responsiveness.
Which is no small feat, since my FreeBSD/KDE desktops consistently outperform my equivalent Linux machines in terms of, say, running two makes while playing a song over NFS with no skips. (These are k6-2 machines, one with FreeBSD5, one with Gentoo.)
The 4.0 branch will continue to be developed well into the lifetime of 5, just as 3.0 was before it. (Development on 3-STABLE only recently slowed down; it benefited from most of the bugfixes in 4 that didn't break compatibility.)
My suggestions to someone wanting to run FreeBSD right now? If it's a production machine, I'd stick to 4.7 or 4.8, simply because the ability to track the -STABLE branch with cvsup is really nice. Also, if you're not comfortable with updating your sources and recompiling your world periodically, stick to 4.x; since 5.0 doesn't yet have a controlled -STABLE branch, it will occasionally have broken features, though this has only happened to me once.
On the other hand, if you have a recent machine, need good ACPI support, or want to see what all the fuss is about, try 5.0. I use it with great success -- just be warned, you may have to recompile things every so often until it goes -STABLE.
Happy BSDing!
> rather than the current HORRIBLE emulation performance of 32bit apps on 64bit hardware
:-)
This is a common misunderstanding.
You're probably thinking of the early Itaniums, which emulated x86 as a sort of afterthought and, obviously, had poor performance as a result. What the article refers to is AMD's x86-64 architecture, which can run 32-bit x86 code at full speed, and in fact can host 32-bit processes within a 64-bit OS and vice versa with very little performance hit.
However, from what I've heard, the more recent Itaniums handle x86 a -lot- better. Take that with appropriate salt, of course.
So that's the gigantic discovery you missed.
I think perhaps you may be confusing this release with Sun's native port. That's not what this is, though we've been waiting for that for some time (Dec.2001, I believe).
What this is is an upgrade to the eyesbeyond patchset used to build JDK1.2 and 1.3 before. It's been merged into the ports tree, hence the announcement; it allows you to build a native FreeBSD JDK using the Sun sources and, for boostrapping, the Linux binaries.
Unless something massive and invisible has happened that I missed, there will be no binary packages as a result of this release, because of Sun's licensing. If you'd taken the time to build the port in question, you'll note that you still have to go through a clickwrap to obtain the sources from Sun; it doesn't auto-fetch like most ports. Until Sun's native port is released, don't expect a native FreeBSD binary JDK unless you build one yourself.
Nope, not like Parrot, because the JVM and CLI are not like Parrot. There are a lot of differences, but the two main ones are:
-Static typing.
-Stack-based (vs. register-based)
The JVM and CLI are both designed for static-typed languages, like Java, C, C++, C#. Parrot's main deviation from previous VMs is its design around dynamically-typed languages like Perl and Ruby, with the corresponding techniques to make this fast.
Furthermore, the JVM and CLI are both stack-based, while Parrot is register-based. These involve different optimization techniques and a different underlying virtualization.
The framework described in the Intel paper is most definitely static-type oriented (they discuss the difference in casting-exceptions in C# and Java, and how they handle it), and most probably stack-oriented (though that doesn't seem specified).
This may not be your issue, but the Xft configuration file syntax has changed in a non-backwards-compatible way as of 4.3.0. This will lead to broken font behavior if you're not careful. Is it seeing all of your fonts? Are you still getting antialiasing? If not on either of those, you probably need to tweak your Xft config.
Probably (IANLT) he's referring to the various prefix encodings and variations for instructions. From my x86 manual, "Machine language instructions...vary in length from 1 to as many as 13 bytes. ...There are over 20,000 variations."
:-)
Now, granted, that rather large number probably includes different target registers, but compared to (to use your example) the 68k, the x86's encoding format is just -weird-:
16-Bit:
-An opcode. Either 1 or 2 bytes.
-Some flags and/or target register. 1 byte, optional
-Displacement. 0-2 bytes.
-Immediate. 0-2 bytes.
32-Bit:
-Optional address size prefix byte.
-Optional operand size prefix byte.
-Like above, but with 0-4-byte displacement/immediate and optional scaled index byte.
Now consider the fact that many opcodes implicitly reference registers. Decoding this instruction set by hand would be a royal bitch, and it's exactly the sort of configuration that RISC targeted for demise.
However, Linus makes a good point in the e-mail, which is (paraphrased) that the x86 encoding is basically a very good compression algorithm for its code. While the RISC machines that use 32 or 64-bits for every instruction may be more regular, their code does tend to be larger.
The ironic thing, in my mind, is that the IA-64's encoding is in many ways -more- baroque than the x86s! Instructions in bundles, bundles in groups (or is it the other way around? I never remember), flags at the end to specify how to interpret the instructions before -- it's an interesting take on VLIW, in that it doesn't specify the number of execution units, but YUCK.
"PDAs typically use processors designed specifically for embedded environments...the PowerPC is exactly the opposite."
:-) ). As you'll note from the Macs, chips based on the architecture tend to have low power consumption and the resulting low heat output. However, smaller PowerPC implementations can be found in everything from Cisco routers to TiVos. I know of at least one $25 'residential gateway' DSL router that's a PowerPC.
Ah, not quite! Just as the presence of Athlons does not mean there are no embedded x86 Elans, the presence of the G4 doesn't mean there are no embedded PowerPCs! Don't confuse the architecture (PowerPC) with the implementation (G4).
The PowerPC has long been a staple of the embedded commuity (by 'long' here I mean 'half a decade or so'
The PowerPC's proven itself to be an astoundingly flexible architecture, and if IBM says they've got a low-power-consumption chip, I'd believe it, even if they posted good performance figures. As with the ARM, which was also not originally an embedded chip, performance and power consumption are not -always- mutually exclusive.
Also, as far as Linux on the PDA is concerned...I run Linux on my iPaq (and use it as a PDA) and have found it to be smaller and more stable than WinCE, and more stable (though larger) than PalmOS. My distribution of Linux fits handily into 16M of flash, and that includes Qtopia, all my PIM apps, Konqueror, Kinkatta (an AIM client), and various wlan mapping tools. Even my non-Linux friends prefer my 'feudal' Linux PDA -- and this was put together by a bunch of volunteers. I'm really looking forward to see what IBM's got.
This strikes me as both a good and a bad thing. /home and JFS on the maildirs, for example. :-)
Good, because journalled filesystems are a Good Thing. I use FreeBSD exclusively on both desktop and workstation, and while SoftUpdates is very good, it and journalling have different aims. (SoftUpdates aims to keep all file metadata consistent at all times; journalling aims to keep all file -data- consistent at all times.) Choice is always good, and I could see myself using SoftUpdates on
However, this is a bit of a Bad Thing in that one of FreeBSD's simplicities has always been the One Filesystem, UFS. Granted, UFS has evolved some (UFS-Softupdates and now UFS2) but there was never a question as to which filesystem to choose: UFS has enough tunables, most of them automated, that you can optimize it for small-file, large-file, high-latency, low-latency, etc. I've found it to be capable of keeping up with the various Linux filesystems in their own areas. But if this is merged into -current, there will be a choice to make when preparing a slice. This is one of those things that's hard to change after the fact.
As for me, I'll stick with UFS2 until I see how this shapes up, but tally-ho!
Many of the posters have, I think, misinterpreted what a TiVo is. A TiVo -is- a glorified VCR, but that's not why it has captured geek hearts and minds (mine included). The key is that the TiVo downloads the program guide and parses it, removing any need for you to manually calculate when your shows begin and end, and enabling it to automatically find and record episodes of shows you've watched or shows it thinks you might like.
So chances are, connecting an FM radio to the line-in on a soundcard and scheduling LAME from cron is not quite what was intended here. The original poster notes that some of the stations in question change format frequently during the day, in which case it is doubly important to have some intelligence in the recorder so that it can adapt and pick out the diamonds in the radio rough.
As for my own suggestions, I've actually been giving this some thought recently after getting a radio again (had mine stolen). Something like the GNURadio project, a wideband multichannel receiver, could pull down RDS streams (Radio Data Service, which transmits at least station identification and sometimes program names) and parse them for TiVo-like functionality. Alternatively, you could see if any of the stations in question export their schedules using RSS or some such (some college stations do) or pull down and parse their coming-up-next webpages.
128-bit AES allows for 128-bit keys, so yes, in decimal, 3.4e38-somethingorother (2^128). Yes, this is a greater range than DES (2^56). It's also greater than 3DES using two keys (one for the first and third stage, one for the second, so 2^112). Proper 3DES implementations use three independent keys for an effective keyspace of 2^168.
:-)
However, the keyspace of an algorithm is only one of its strengths. It's only relevant if brute force is the fastest way to crack the cipher, which is very rarely the case. In the case of DES, it was refined by the oft-maligned NSA to resist differential cryptanalysis, leaving it resistant against all but brute-force until linear cryptanalysis was 'discovered' in the mid-90s. (To those who still believe the NSA weakened DES, go read your Schneier.)
AES-128 is a new algorithm, but feels good. Brute-forcing a 128-bit keyspace would take several centuries, even taking into account Moore's law, so the difference between it and 3DES's 168 bits isn't relevant. Moreover, there are known exploits against 3DES (even if they aren't terribly helpful), whereas massive scrutiny by cryptanalysis worldwide (while Rijndael was becoming AES) has turned up nothing so far. This doesn't mean there won't be exploits, but it means that the chances that Shamir or one of the other hotshot cryptanalysts is going to bring out a paper tomorrow that invalidates all your work are very small.
So: AES-128 will keep your sister from reading your diary. Unless you believe the NSA has some sort of amazing quantum computing that's forty years beyond consumer tech (which I really, really don't), AES-128 is also likely to keep your files safe from the gimmies for several decades.
Although why the NSA would be interested in, say, my homedir, is beyond me -- the most likely person trying to crack my encryption is probably a jealous girlfriend.
(This is surmised from the e-mail linked from the article, and may be wrong. *grin*)
It sounds like hashes were used because, while they're a performance hit, they're not -that- big of a performance hit. Evaluating a signature (say, RSA or DSA) is more CPU-intensive than MD5 or SHA1. We're talking an order of magnitude here, maybe more. This would have to be done on each load of an executable, shared library, and shell script. Also, a lot of OSen are still resistant to putting potentially restricted crypto into kernel-level systems.
As far as placing the signatures into the ELF binaries, the author discusses that in the e-mail and rejects it for two reasons:
1. Doesn't work for #! shell scripts. A separate fingerprint table does.
2. Putting the signature in the file still allows the file to be replaced, signature and all. Loading the signatures into a kernel table on boot makes it harder to munge them at runtime. It's not just untrusted executables we don't want to allow -- replacing one trusted app with another (say, ls with rm?) can be just as bad.
Beyond that, though, I agree -- signed (rather than simply fingerprinted) files could definitely be a good thing, and I'll be watching to see how all this develops.
I concur, but keep in mind that Apple has always (afaik) made the majority of their income from hardware sales. Were they to move to an easily-cloneable PC platform (i.e. the platform that's evolved from the original IBM PC), they'd have to really move a lot of software to make up!
HOWEVER: a lot of people seem to think that that fact alone will prevent them from considering Intel/AMD. I'm not so sure. Granted, all of us would love to be able to run OSX on our existing Athlons, and I doubt that will happen -- but what's to stop Apple from rolling out their own version of the PC architecture? There's a lot of cruft in the ex-IBM PC that could be dropped; with a little work, an x86 machine could be had with all the hardware integrity of a Mac, and just as hard to clone.
You may be asking, Why would we want THAT? Two reasons, imho: 1) it would allow them to lower the price (though I doubt they would), and 2) x86 binaries could be run through something closer to Wine than a full-out emulator! Mmmm, compatibility.