The stable kernel is usually
released a couple of months after the feature freeze (bugs permitting).
+1, Funny. I think you mean after the code freeze, which usually happens a month later, well, two, three, ok, six months later. You also forgot to mention that Linus usually has multiple freezes, and the one on 31 Oct is only the first. With each successive freeze he puts on a more threatening tone, crying woe unto them who would dare tempt him to thaw the kernel again. Eventually the first code freeze happens, then maybe one or two more of those....
They mean faster reboots period because they never need to be checked on boot - so you don't get that annoying "Ahem, you've
rebooted too many times, I'm going to check your hard drive while your client, who's looking over you shoulder, wonders why you
re-assured him you'd only have his production server down for half a minute to install the new kernel, and I'm spending 5 minutes
scanning his drives."
Yeah that check can hit at inconvenient times.
Of course you can turn off those checks on ext2 too, but that would be stupid.
Just as stupid for ext2, ext3, xfs, reiserfs, or jffs2. The check is not just for fear of bugs in the filesystem code. Any sort of hardware or software bugs could trigger inconsistencies. If a filesystem doesn't offer the option to check your disks ever N mounts or every N days, that doesn't mean your system is therefore safe from such things. You are at the mercy of every line of code you choose to compile into your kernel, every byte of firmware on your motherboard / SCSI card / drive, and every stray cosmic ray that wanders through your office. Doing a sanity check on the layout of your filesystem once in awhile is not just a good idea, it's, well, ok, it's just a good idea.
Now if we could just get some stable NTFS read/write support I
would be set.
It's on the way. Read-only NTFS (rather poor in 2.4) has been rewritten and is much improved in 2.5, and a certain subset of read-write (writing new contents to an existing file) is reported to be stable. I haven't tried it. Full read-write may or may not make 2.6.0 but you can be sure it is in active development.
Every month or so, I had to sit through the following:
"Warning: drive has been mounted more than 30 times, check forced" on the ext3 partition
This is a safety feature. Filesystem corruption can be caused by hardware funnies as well as software bugs. Your memory could be flaky, your hard drive could be on its way out, your IDE cable could be too long, your SCSI chain could be improperly terminated, your motherboard might be iffy, your CPU could be running too hot. There might be software bugs in the generic kernel, the block / scsi drivers, the ext3 code, or even some random driver that has nothing to do with filesystems or memory management.
Because of this, ext2 and ext3 have tunable parameters for how often to force an fsck, overriding the fact that the fs is supposed to be in a known clean state. Apparently reiserfs does not have this safety feature - or does it? (I don't know.)
If this annoys you, turn it off. 'man tune2fs', or specifically,
The fact that a cypher is symmetric or asymmetric has no impact on its "crackability" per se, unless a method different from brute
force is used.
Except that no public-key algorithms have been found which are anywhere near as efficient in terms of strength per bit. AES-160 is quite a bit harder to crack than RSA-512, right?
So if you determine "crackability" as "per key size", then the best symmetric algorithms are a lot better than the best asymmetric ones.
To be very secure, I would not like to use a fixed key size for all future communication. I'd rather increase the key size by a few
bits whenever a message is being exchanged. With a fixed key size, the chance of breaking the system will converge toward 100% as
the number of attempts converges toward infinity.
Adding a few bits to the key every message or two does not really help, if you assume the attacker archives all your ciphertext.[*] Say ten years from now he breaks your first message. He just has to connect the dots and he has now broken your new thrice-as-long key.
Even if he only has some of your messages... say for example he is missing a message where 8 bits are added to the key. He knows your 160-bit key but needs your 168-bit key. Guess what? He only has to break an 8-bit key, which can be done on the Atari 2600 in his basement.
Here I'm assuming your key is for a symmetric algo. Your scheme wouldn't work at all for, say, RSA. You can't just take a valid RSA key, add a few random bits and get a new valid key.
[*] Perhaps you are assuming that nobody can archive your ciphertext because the message is unobservable - to observe it you must disrupt it. Is there really such a strong guarantee that QC does not allow a mitm to archive your conversation for later analysis?
So the message header is normal bits describing where to route, and the payload is actual qubits that contain the encypted
payload with all the usual guarentees, apparently it works although its a bit of a headf**k.
But you can't route it, right? It has to go point-to-point? I don't think I really understand this stuff (scratch that - I know I don't understand this stuff) but if something needs to use a direct p2p (no that's not "peer-to-peer") link, it kind of defeats the whole purpose of having an Internet. (No, I'm not referring to the "purpose" of efficient pr0n distribution.)
The actual problem you are thinking of is finding the prime factors of very large numbers. As already noted, finding the factors of
prime numbers is trivial.
Oh, come on. It takes longer to find the factors of a large prime number than a non-prime in the same ballpark.
(I'm assuming, obviously, that you don't already know it's prime. If you did know, it means you're not actually finding the factors, since you've already been told what they are.)
I download a compiled version of, say, Gimp. I reverse engineer it. Am I free of the licence restrictions?
Point the first. There are no license restrictions. There are only license grants. Unlike an EULA, the GIMP license (the GNU GPL) does not restrict any rights you already had under copyright law. It only gives you additional rights - to wit, the right to redistribute the software, with certain restrictions.
Corollary to point the first. Copyright law lets you use the software for anything you wish - canonical example being to take screenshots of it and print them onto soft paper, then use the paper in your lavatory. Copyright law does not let you make extra copies for use outside your own domain. (Backups for your own use are, I believe, considered fair use.) So you don't need to care about the GPL until you plan to redistribute the software - give it to others, or sell it.
Point the second. You are not free of the GPL terms of the software itself, but once you have reverse engineered it (quite easy, since you have the source code), the ideas you have gained from studying the code are yours to keep. Copyright law does not cover ideas, only actual written works. If you want to build a better GIMP, feel free to have a code printout in your cubicle for reference, so long as what you write does not actually cut/paste the code itself.
NOTE: do not try this with most proprietary software - the company is likely to sue you for "polluting" your mind with their IP. This may or may not hold up in court but it will cost you a lot either way. This is why the FreeType people put such emphasis on the fact that FreeType is a clean-room reimplementation of TrueType - that is, done without looking at other implementations. TrueType, you see, involves two of the three big law firms disguised as software houses (Apple, Microsoft and Oracle), and nobody wants to mess with them.
What happends when you look at the code of a program under the gpl. Can you ever write a simulair program without having to place
it under the GPL?
It has always been the position of any free software advocate I've ever heard from that this sort of thing is ridiculous.
In the proprietary software world, sure, people are afraid of being sued because their IP was "tainted" by having seen someone else's IP. And certainly, at least in many allegedly civilised countries, anyone can sue anyone for any reason, so there is no way to protect yourself 100% from the annoyance of a court proceeding. Novell for one seems to be rather trigger-happy, if you ask Jeff Merkey at least. I suppose it doesn't pay to piss of Apple either, given their legal track record.
So it comes down to whether or not you trust the intentions of the free software camp. Certainly the GIMP people could go out and start suing everyone in sight who made any kind of image manipulation software, just as a fishing expedition, and they would probably lose unilaterally. But the free software culture, as I said, has long been opposed to the legal theory that copyright extends to ideas as opposed to implementations, and to the idea of your brain being tainted by how or where it learned things. I mean, really. Does anyone expect popular novelists never to read each other's works just to protect themselves from suits about adjective placement?
OTOH, since the proprietary software world is so consumed with the idea of IP über alles, we in the free software world know we have to be very careful looking at source code we don't have the right to hack on. Not because the law is on (say) Microsoft's side, but because they could affort to harrass us with a legal stink either way.
seriously, what are you going to do when you have the source? grep for spyware?
Heh. (:
Actually, a lot of having the source is a psychological effect which, for all that, is quite effective. As it is now, the vendor can say "Trillian has no ads and no spyware" and we have no way of checking this, short of running it in a room full of computers for a few weeks, behind a firewall that logs all packets not destined for known AOL/MSN/etc servers. This is impractical, so the vendor can basically get away with saying whatever they want even if they do sport spyware.
Sure, the install file is over 2 MB, and the source could potentially be quite a bit bigger, so one person isn't going to read through the whole thing over an afternoon. But unless the source is intentionally obfuscated to a great degree, it should be pretty easy to isolate the bits that actually do network calls, and audit those. I personally may or may not do such an audit - but you (and Trillian's vendor) can be sure that someone will.
Therefore, if Trillian were open source (or even "community source" or some such rot), there is no way they could hide things like spyware for long. They know this, so they'd be stupid to try.
You missed the subtle joke.. Object Management Group shortens to OMG.
No I didn't. You missed my point. I said, "Why is this not modded funny?" I thought it should have been, you see, but it wasn't. *sigh*, you really can't win in this game.
Yes indeed. My question about Trillian and Jabber was partly curiosity, but mostly to confirm my suspicion that the standard knee-jerk reaction "why bother with other IM clients, just use Trillian" is not always correct. (:
(My question further down about wanting to see the Trillian source code to verify its alleged lack of spyware was another devilishly clever attempt to point this out.)
all the times Trillian has been unable to run AIM, GAIM seems to work for me.
Hmmmm, so this story has a downside. Now that GAIM is available for Windows, it may gain enough userbase to show up on AOL's radar, and the two of them will subsequently have the same arms race we've seen with Trillian.
There's something to be said for a small userbases, whether it be running Apache+OpenSSL on non-i386 Linux, or GAIM on non-Windows....
Re:noooo, use Trillian :)
on
Gaim For Windows
·
· Score: 0, Redundant
Where do I get the Trillian source code? I can't find it. The web page says the binary has no spyware in it, but I'd like to see for myself.
Yes, GAIM is great for Linux but on Windows, I use Trillian Supports all the protocols as well as IRC.
Including Jabber? I skimmed a couple of their web pages and didn't notice it.
I plan to roll out an experimental Jabber server here soon - cross-platform support is nice for that sort of thing, as most of my users are still on Windows. gaim/win32 sounds very useful - we'll see whether it actually works yet.
Or is there another IM protocol out there with a free server implementation? I thought Jabber was pretty much the only game in town if you didn't want to rely on someone else for your IM service.
Now that the GTK+ Windows port has started to mature, this sort of thing is inevitable. The biggest obstacle to portability in ANSI C these days is usually your GUI layer. The rest of your portability problems - well, that's why we also have glib for Windows..
Re:Let's try that in Welsh
on
Wireless Wales
·
· Score: 1
Ignore this guy - what would someone named "dafydd" know about Celtic languages, anyway?
After all, we don't recompile Bash or dynamically load libraries into Bash every time someone comes out with a new command line
program.
No, but you could, if you needed it to be a shell builtin for performance or other reasons.
We shouldn't have to do that either for a new file system type, networking protocol, or driver.
You still have to write and compile something - why not a kernel module?
Kernel modules, in Linux and other Unix variants, has greatly decreased the need for a message-passing kernel architecture. You get the modularity without the performance hit or the design weirdness to work around the performance hit.
Not that OS X is actually a microkernel OS! It's more like MkLinux or User-Mode Linux, in that one kernel is running on top of another but basically only using the host kernel for access to the hardware.
Because:
1) Not everyone like Debian for other reasons; in different systems update is more difficult
Heh - thank the trade press for that one - any time any "tech" journalist reviews a new OS (particularly Linux, it seems) most of the review concentrates on how easy it is or isn't to install. Ergo many users will absorb the same priorities. Thus Debian loses out even though until fairly recently it was the only Linux distro possible to update in an automated, pain-free manner.
(OK, take issue with that statement, if you will - the fact remains that at least the other mainstream distros never had anything even close to the capabilities of dselect until a couple years ago - never mind the capabilities of apt. I was doing quick 'n' easy updates back in '97 or so, and I was a relative latecomer to Debian. I have to say, tracking Debian unstable was so painless, I didn't even notice the libc5 -> libc6 transition until it was well underway!... not that I was using Debian for anything serious back then.)
So, we have RMS and Hansu the Kracku here. Who's up next?
That would be me. If you think that bothering to learn to use your computer is beneath you and a waste of your oh-so-valuable time, then I think giving you a step-by-step to help you short-circuit that process is a waste of my time.
Elitism is soooo much fun.
Most people's attitude to computers seems to be "I just want to ride a motorcycle, why do I have to learn all this manual[*] shifting crap?"
I don't even run an SSL-enabled apache server (though I do run sshd on port 443).
FWIW, and contrary to popular belief, sshd is not vulnerable to the recent openssl holes. ssh only uses a small part of the openssl libraries (certain crypto functions); the holes are in a different part (the actual SSL implementation).
Yeah, when I first read about openssl having problems I immediately thought of openssh too....
If you want the cron job can also then just check for new updates and send an email to the administrator every time a new patch is
available so that it not blindly installs every new patch without human interaction.
Better yet - do this on one machine. Your devel / test machine. On the same machine, set up a local apt repository. When a new update comes in that affects a package you use in production, vet it with your usual QA procedures. If it passes, put it up on your local repository. Your other boxes all have cron jobs to auto-update from there.
(No, I haven't set up such a system yet, but I keep thinking about it. I only have a few Linux boxes out there so it's not critical for me just yet.)
Slashdot Mirror
+1, Funny. I think you mean after the code freeze, which usually happens a month later, well, two, three, ok, six months later. You also forgot to mention that Linus usually has multiple freezes, and the one on 31 Oct is only the first. With each successive freeze he puts on a more threatening tone, crying woe unto them who would dare tempt him to thaw the kernel again. Eventually the first code freeze happens, then maybe one or two more of those....
Even odds we get a 2.6.0 by June.
Yeah that check can hit at inconvenient times.
Just as stupid for ext2, ext3, xfs, reiserfs, or jffs2. The check is not just for fear of bugs in the filesystem code. Any sort of hardware or software bugs could trigger inconsistencies. If a filesystem doesn't offer the option to check your disks ever N mounts or every N days, that doesn't mean your system is therefore safe from such things. You are at the mercy of every line of code you choose to compile into your kernel, every byte of firmware on your motherboard / SCSI card / drive, and every stray cosmic ray that wanders through your office. Doing a sanity check on the layout of your filesystem once in awhile is not just a good idea, it's, well, ok, it's just a good idea.
It's on the way. Read-only NTFS (rather poor in 2.4) has been rewritten and is much improved in 2.5, and a certain subset of read-write (writing new contents to an existing file) is reported to be stable. I haven't tried it. Full read-write may or may not make 2.6.0 but you can be sure it is in active development.
This is a safety feature. Filesystem corruption can be caused by hardware funnies as well as software bugs. Your memory could be flaky, your hard drive could be on its way out, your IDE cable could be too long, your SCSI chain could be improperly terminated, your motherboard might be iffy, your CPU could be running too hot. There might be software bugs in the generic kernel, the block / scsi drivers, the ext3 code, or even some random driver that has nothing to do with filesystems or memory management.
Because of this, ext2 and ext3 have tunable parameters for how often to force an fsck, overriding the fact that the fs is supposed to be in a known clean state. Apparently reiserfs does not have this safety feature - or does it? (I don't know.)
If this annoys you, turn it off. 'man tune2fs', or specifically,
HTH..
Except that no public-key algorithms have been found which are anywhere near as efficient in terms of strength per bit. AES-160 is quite a bit harder to crack than RSA-512, right?
So if you determine "crackability" as "per key size", then the best symmetric algorithms are a lot better than the best asymmetric ones.
Adding a few bits to the key every message or two does not really help, if you assume the attacker archives all your ciphertext.[*] Say ten years from now he breaks your first message. He just has to connect the dots and he has now broken your new thrice-as-long key.
Even if he only has some of your messages ... say for example he is missing a message where 8 bits are added to the key. He knows your 160-bit key but needs your 168-bit key. Guess what? He only has to break an 8-bit key, which can be done on the Atari 2600 in his basement.
Here I'm assuming your key is for a symmetric algo. Your scheme wouldn't work at all for, say, RSA. You can't just take a valid RSA key, add a few random bits and get a new valid key.
[*] Perhaps you are assuming that nobody can archive your ciphertext because the message is unobservable - to observe it you must disrupt it. Is there really such a strong guarantee that QC does not allow a mitm to archive your conversation for later analysis?
But you can't route it, right? It has to go point-to-point? I don't think I really understand this stuff (scratch that - I know I don't understand this stuff) but if something needs to use a direct p2p (no that's not "peer-to-peer") link, it kind of defeats the whole purpose of having an Internet. (No, I'm not referring to the "purpose" of efficient pr0n distribution.)
Oh, come on. It takes longer to find the factors of a large prime number than a non-prime in the same ballpark.
(I'm assuming, obviously, that you don't already know it's prime. If you did know, it means you're not actually finding the factors, since you've already been told what they are.)
Point the first. There are no license restrictions. There are only license grants. Unlike an EULA, the GIMP license (the GNU GPL) does not restrict any rights you already had under copyright law. It only gives you additional rights - to wit, the right to redistribute the software, with certain restrictions.
Corollary to point the first. Copyright law lets you use the software for anything you wish - canonical example being to take screenshots of it and print them onto soft paper, then use the paper in your lavatory. Copyright law does not let you make extra copies for use outside your own domain. (Backups for your own use are, I believe, considered fair use.) So you don't need to care about the GPL until you plan to redistribute the software - give it to others, or sell it.
Point the second. You are not free of the GPL terms of the software itself, but once you have reverse engineered it (quite easy, since you have the source code), the ideas you have gained from studying the code are yours to keep. Copyright law does not cover ideas, only actual written works. If you want to build a better GIMP, feel free to have a code printout in your cubicle for reference, so long as what you write does not actually cut/paste the code itself.
NOTE: do not try this with most proprietary software - the company is likely to sue you for "polluting" your mind with their IP. This may or may not hold up in court but it will cost you a lot either way. This is why the FreeType people put such emphasis on the fact that FreeType is a clean-room reimplementation of TrueType - that is, done without looking at other implementations. TrueType, you see, involves two of the three big law firms disguised as software houses (Apple, Microsoft and Oracle), and nobody wants to mess with them.
It has always been the position of any free software advocate I've ever heard from that this sort of thing is ridiculous.
In the proprietary software world, sure, people are afraid of being sued because their IP was "tainted" by having seen someone else's IP. And certainly, at least in many allegedly civilised countries, anyone can sue anyone for any reason, so there is no way to protect yourself 100% from the annoyance of a court proceeding. Novell for one seems to be rather trigger-happy, if you ask Jeff Merkey at least. I suppose it doesn't pay to piss of Apple either, given their legal track record.
So it comes down to whether or not you trust the intentions of the free software camp. Certainly the GIMP people could go out and start suing everyone in sight who made any kind of image manipulation software, just as a fishing expedition, and they would probably lose unilaterally. But the free software culture, as I said, has long been opposed to the legal theory that copyright extends to ideas as opposed to implementations, and to the idea of your brain being tainted by how or where it learned things. I mean, really. Does anyone expect popular novelists never to read each other's works just to protect themselves from suits about adjective placement?
OTOH, since the proprietary software world is so consumed with the idea of IP über alles, we in the free software world know we have to be very careful looking at source code we don't have the right to hack on. Not because the law is on (say) Microsoft's side, but because they could affort to harrass us with a legal stink either way.
Heh. (:
Actually, a lot of having the source is a psychological effect which, for all that, is quite effective. As it is now, the vendor can say "Trillian has no ads and no spyware" and we have no way of checking this, short of running it in a room full of computers for a few weeks, behind a firewall that logs all packets not destined for known AOL/MSN/etc servers. This is impractical, so the vendor can basically get away with saying whatever they want even if they do sport spyware.
Sure, the install file is over 2 MB, and the source could potentially be quite a bit bigger, so one person isn't going to read through the whole thing over an afternoon. But unless the source is intentionally obfuscated to a great degree, it should be pretty easy to isolate the bits that actually do network calls, and audit those. I personally may or may not do such an audit - but you (and Trillian's vendor) can be sure that someone will.
Therefore, if Trillian were open source (or even "community source" or some such rot), there is no way they could hide things like spyware for long. They know this, so they'd be stupid to try.
Weird. Must be a cygwin thing. (Yes, I tried this, with bash 2.05b.0(2)-release (i386-pc-linux-gnu).)
I haven't used csh in years, but who can forget the classic:
No I didn't. You missed my point. I said, "Why is this not modded funny?" I thought it should have been, you see, but it wasn't. *sigh*, you really can't win in this game.
Yes indeed. My question about Trillian and Jabber was partly curiosity, but mostly to confirm my suspicion that the standard knee-jerk reaction "why bother with other IM clients, just use Trillian" is not always correct. (:
(My question further down about wanting to see the Trillian source code to verify its alleged lack of spyware was another devilishly clever attempt to point this out.)
Hmmmm, so this story has a downside. Now that GAIM is available for Windows, it may gain enough userbase to show up on AOL's radar, and the two of them will subsequently have the same arms race we've seen with Trillian.
There's something to be said for a small userbases, whether it be running Apache+OpenSSL on non-i386 Linux, or GAIM on non-Windows....
Where do I get the Trillian source code? I can't find it. The web page says the binary has no spyware in it, but I'd like to see for myself.
Including Jabber? I skimmed a couple of their web pages and didn't notice it.
I plan to roll out an experimental Jabber server here soon - cross-platform support is nice for that sort of thing, as most of my users are still on Windows. gaim/win32 sounds very useful - we'll see whether it actually works yet.
Or is there another IM protocol out there with a free server implementation? I thought Jabber was pretty much the only game in town if you didn't want to rely on someone else for your IM service.
Now that the GTK+ Windows port has started to mature, this sort of thing is inevitable. The biggest obstacle to portability in ANSI C these days is usually your GUI layer. The rest of your portability problems - well, that's why we also have glib for Windows..
Ignore this guy - what would someone named "dafydd" know about Celtic languages, anyway?
No, but you could, if you needed it to be a shell builtin for performance or other reasons.
You still have to write and compile something - why not a kernel module?
Kernel modules, in Linux and other Unix variants, has greatly decreased the need for a message-passing kernel architecture. You get the modularity without the performance hit or the design weirdness to work around the performance hit.
Not that OS X is actually a microkernel OS! It's more like MkLinux or User-Mode Linux, in that one kernel is running on top of another but basically only using the host kernel for access to the hardware.
Heh - thank the trade press for that one - any time any "tech" journalist reviews a new OS (particularly Linux, it seems) most of the review concentrates on how easy it is or isn't to install. Ergo many users will absorb the same priorities. Thus Debian loses out even though until fairly recently it was the only Linux distro possible to update in an automated, pain-free manner.
(OK, take issue with that statement, if you will - the fact remains that at least the other mainstream distros never had anything even close to the capabilities of dselect until a couple years ago - never mind the capabilities of apt. I was doing quick 'n' easy updates back in '97 or so, and I was a relative latecomer to Debian. I have to say, tracking Debian unstable was so painless, I didn't even notice the libc5 -> libc6 transition until it was well underway! ... not that I was using Debian for anything serious back then.)
That would be me. If you think that bothering to learn to use your computer is beneath you and a waste of your oh-so-valuable time, then I think giving you a step-by-step to help you short-circuit that process is a waste of my time.
Elitism is soooo much fun.
Most people's attitude to computers seems to be "I just want to ride a motorcycle, why do I have to learn all this manual[*] shifting crap?"
FWIW, and contrary to popular belief, sshd is not vulnerable to the recent openssl holes. ssh only uses a small part of the openssl libraries (certain crypto functions); the holes are in a different part (the actual SSL implementation).
Yeah, when I first read about openssl having problems I immediately thought of openssh too....
Better yet - do this on one machine. Your devel / test machine. On the same machine, set up a local apt repository. When a new update comes in that affects a package you use in production, vet it with your usual QA procedures. If it passes, put it up on your local repository. Your other boxes all have cron jobs to auto-update from there.
(No, I haven't set up such a system yet, but I keep thinking about it. I only have a few Linux boxes out there so it's not critical for me just yet.)
And when Apache = Linux.