... for the simple reason that the mechanism (eg: DLT-drive) and datacarrier (eg: Tape) are separated. IDE disks have both in one sealed package, which makes it terribly difficult to get to your data if your stepper motor borks.
With tapes, you just get a new drive.
I have a feeling that this part is near impossible. At this point, Linus does have total control over the kernel (albeit not being able to cope with the load) all the way to the nitty gritty details. (Bob, the machinegun).
My guess is that Linus wants a solution in which he can keep that kind of fine-grained control over the kernel, which conflicts with trusting someone else to do parts of the job - which is a necessity in the "span of control". (2 Battalion, attack objective Oscar... Bob: machinegun, Carl: mortar,...)
If there is a revolution, it's not per se "same shit, different name": I think any kind of revolution people are referring to has the goal of establishing a different modus operandi, be it CVS, a comittee, patch penguin,... Replacing one dictator with another won't help, unless there's someone with supernatural powers I haven't yet heard of:-)
the problem with nagging him about it is that no-one is really providing a better alternative
<TONGUE-IN-CHEEK>
As long as you yourself think you're the best person on this planet to do the job, no alternative is going to be "better"...
</TONGUE-IN-CHEEK>
It's exactly that attitude that has done good for the linux kernel in shaping it, but can be equally damaging to that same kernel. Linus doesn't exactly have a 'small' ego:-)
Fessing up "I'm a bastard." doesn't do diddly squat to help resolve the problem.
I'm really curious what would happen if Linus just "disappeared" from the planet: it could possibly be a complete disaster, or a gift from heaven to get the kernel development more organised. I know some big companies who would be more than happy to provide an "alternative";-)
The problem is that it isn't just "drivers". It touches the core kernel just as well, and things that can't be/shouldn't be modularized (e.g.: the VM subsystem thingie not so long ago).
I agree to a certain degree that not all drivers should always be included in the kernel, but what's kept in, and what has to go? For example: filesystems - way too many of them, but you can't boot without support compiled in, or changing some real stuff on the booting process.
Instead try to help existing maintainers, or maybe help grow new ones
The problem is that Linus' current "system" is demotivating the current maintainers because of his non-responsiveness. A lot of the efforts and productivity of the maintainers is lost b/c of the non-accepting of patches, and the work they have in keeping the patches current with every kernel version until Linus finally decides to integrate the patch.
It doesn't matter how many maintainers there are: Linus can only work through a specific amount of code/patches per day/week/month. More maintainers result in more patches being dropped, and subsequently in more efforts to keep their patches up-to-date with the kernel.
This is really hurting development, and is frustrating a lot of people who are involved in the kernel with the risk of losing them.
Anyhow: Linus does what he likes, but it's exactly that kind of attitude that will hurt Linux in the longer run - both in technological as reputational (?) way.
Please please please please do _NOT_ google it... It was embarassing enough when google acquired dejanews, and put the old usenet archives on-line.:-)
I just visited some sites from which I hoped that they dissappeared completely from cyberspace. The only defense I've got now are the old cryptic URLs of these monstrosities... Indexing that database would be a disaster, especially with an unusual name like mine...
(Yes, I was stupid enough to use my real name;-)
Damn you, wayback:p
According to ZDNET Belgium [Dutch Text], the buyer appears to be "Sharman Networks", an Australian based company.
They've also acquired the fasttrack licence.
Users will be required to agree to new terms of usage, the next time they log in.
I've seen some commenting that creating a RAID array will suffice to secure your data, but that's really not true:
RAID offers good protection for some things: hardware failure (ie: HD crash) and uptime. That aren't the only woes, however... You can loose data in a lot of ways:
Disaster (fire, quake, flood, nuff said)
Hardware failure (disk, controller,...)
OS failure (FS corruption,...)
Application failure (User space applications malbehaving, virii,...)
User failure (accidental deletes, experimental children - trust me on this one;-)
RAID will protect you from the second, but will happily add nothing in case of any of the other failures. Backing up to another media is a necessity.
Adding an extra disk (or two, or three), and some tar/cpio cronjobs will add basic protection. (No disaster recovery for you, unless it's off-site:)
Removable harddrives (firewire, frames,...) are a plus, but more cumbersome.
Tape is considered a more 'trustworthy' backup medium because the mechanism and data storage are separated (ie: tape drive / tape), while in a HD it's in one single package, and it's not as easy to replace the logic board/stepper motor if this flunks. With tape it's easier: just get a new tapedrive.
Anyhow: don't rely on RAID to save your data - it won't.
What is your stance on the USA trying to regulate a global medium (ie: the net)?
Is cyberspace part of some geographical territory, or should it have it's own legislation and jurisdiction (based on global interests), or will it be an anarchy by design?
As a European (Belgian) citizen, I'm wondering why US legislature is trying to take control of a network, that isn't US-only anymore for some time now. Both the DecSS/Sklyarov cases are quite frightening.
Tagged mails don't need to be sent to the bitbucket: store them in a seperate folder. That way, you won't lose a thing. If a message from someone gets in that folder, you should be able to select it and mark it as "not spam", which will add the source to your profile. (a bit like hotmail works nowadays)
People who find entering an email adres a challenging task, most probably won't install this kind of software themselves. They will use it if it's built-in into their mail client. Adding clear and simple support for marking specific sources/messages would be an obvious feature for such a client.
Newsletters, mailing lists and alerts all come from "trusted sources". It would/should be trivial to configure your client to accept messages based on certain constraints (email adresses, smtp servers, pgp signature...)
E-mail isn't really built for broadcasting: websites, NNTP (to name a few) are far better solutions to accomplish the same goal. Unless the content is personalize, but then injecting hashes wouldn't pose a threat anymore.
It is true that it is not always trivial to pick the pieces in a way that the fragments being hashed start at the same offset, but isn't always needed to add extra complexity. Due to the sheer numbers of the same message being sent by the spammers, it would be quite difficult and timeconsuming for them to create a lot of "slight variants" of the same message. Add to that that spammers aren't the only resourceful people on this planet: we can make it difficult for them as well.
This is how I would do it:
Strip HTML/markup language, so that we get plain text of the message.
Strip all "meaningless" characters from the text, keep only alphabetic (or alphanumeric) characters, no spaces or punctuation.
Uppercase everything.
We now have one string, with all the meaningful characters of the email, which makes it quite hard for spammers to vary much without mutilating the message they're trying to convey.
Pick a 8 entry points in this string based on the occurance a number of well-chosen, predefined two-character combinations that are likely to be found in English text(*) - these need to be defined upfront. There are lots of texts available in the gutenberg project to analyze to get to such a set.
This is hard: we need to find a good balance between physical location in the string, and the occurance of the combinations we have defined, so that we can take a broad "sample" of the text. Luckily for us , spammers tend to send long messages:-)
Now we compute the hash of the fragments, defined by our entry-points and a fixed length. These hashes combined provide a "real big signature" of the spam message. Pick the last two bytes of every hash, and stick them together for a "small signature" that can be used for searching/matching. We need to define our protocol for searching the catalogue in such a way that when a partial match is found using the small signature, we can retrieve the full signature to check further.
Based on this we have a rating from 0/8 -> 8/8 for the probability of a mail being a spam message. End user settings can define what is destined for the bitbucket, and what goes in your mailbox.
In the end, spammers can (and will) try to circumvent these measures, but it would be hard and (hopefully) time-consuming, and it will require them to mutilate their messages to be undetected. Of course, this system only works properly when people are willing to submit spam fingerprints to the catalogue servers.
Anyway, that's my 0.02 EURO...
(*)Of course, English isn't the only language being used in spam, but I guess it's the most prevalent here. You can ofcourse apply the same principle to any language. Heck, if you really want to push the envelope, you can try to detect the language (character frequency analysis and checking for very common words).
Technically, it would be possible to create hashes for different pieces of the message, which can be combined in one single "signature" to detect potential matches. It would be more complicated for the catalogue server to execute searches, and the answers won't always be absolute (e.g. partial match).
The beauty of a cryptographic hash function is that it's purely one-way: it is very easy to check if two messages are the same (they calculate to the same hash), but it is nearly impossible (or at least very very very hard) to calculate the message for any given hash.
Injecting random hashes into the network won't result in valid emails being tagged, but can flood/DOS the catalogue machines.
It would be possible to create hashes for a number of "probable" emails, but diversity in messages is so big, the chances are quite slim to actually stop a legitimate mail.
I can appreciate your side of the problem: it probably sucks to bring in your laptop for repairs and having to wait for [days|weeks|months] to get it back. But as far as I can see, Dell is fulfilling it's obligations by replacing the hinges during the warranty period free of charge: carry-in warranty is simple: you send the faulty device, they fix and send back. It's the easiest and cheapest for them (even if they do pay for transport & packaging) - but that's reflected in the pricing of the setup you bought.
The optional support packs (e.g.: Next Businessday On-site) are well worth the extra money: if you have a problem, within a few days at most there's a Dell repair engineer at your place with spare parts. Time needed: 30 minutes.
Asking for a replacement is really out of the question because:
The unit is two years old - nearly antique.
The hinges are a very minor part of the machine.
If the demand's there (Dell always looses on repairs) it could well be that newer hinges are retrofitted to your model of laptop. We have had laptops where the CPU-shield/cooler was replaced with a newer model, because the CPU got loose a lot in a specific Lattitude model; same goes for the lip (?) to keep the laptop closed which kept breaking - a newer more sturdy replacement was retrofitted without a problem.
I can imagine that it's far from optimal in your case, but Dell support is imho not too shabby - even in your case: other manufacturers could've called it "misusing the unit", and do zilch.
Further, Holocomm's "delocalization" feature can be seen also in SHA-1, where *all* output bits change when one changes a *single* input bit.
<NITPICK>
Due to the nature of bits (being 0 or 1), changing a bit means flipping them from 0 to 1 of vice versa. Changing *all* bits, would mean flipping them all, i.e. a XOR operation.
Changing a single input bit will change *some* output bits, not all of them. Would be a pretty useless hash algorithm;-)
I have to disagree with you: CS isn't about learning programming languages, it isn't about mastering a specific technique or language that is "apt for industry".
It's all about learning the basic fundamentals of programming, algorithms, data structures, different ways of solving things, lot's of theory - it's called "computer SCIENCE", remember.
Scheme is a good teaching language for a lot of reasons:
Most CS students nowadays have experience with computer "programming": VB, Delphi, C, C++, Java, Javascript,... nearly everybody has some experience with some programming language. The problem is that a lot of this experience isn't always built on the proper fundamentals, they're mostly about solving a particular problem without knowing why they should use data structure X or algorithm Y. The usage of Scheme as a teaching language has the advantage that most (if not all) students are forced to learn a new language, which probably isn't at all similar to what they're used to - enabling the teachers to start from scratch. That way, there aren't differences in the level of knowledge of the students, also a plus.
The language structure of scheme is very flexible: most (if not all) fundamental bits can be dealt with properly in Scheme: procedural programming, heaps of different data structures, OOP,...
I do agree that other languages (be it C, C++, Java, Pascal, Fortran, O'Caml, Eiffel,...) should be taught as well. But only on a later stage in the education: the most important thing is that the fundaments of your knowledge are strong, well-taught. Scheme is a good language to do just that: laying those fundaments.
With the boom of IT and internet the last 5 years, there are so many programmers out there that lack those proper fundaments. I'm not saying that they aren't any good, but there are a lot of people that don't have a grip on what lies beneath - which is a pity.
Don Knuth showed us that computer programming is an art, not based on a specific programming language, and I tend to agree with him:).
An E1 connection is 2.048 mbit/s. 1984 kbit/sec is 1.9375 mbit/sec.
I'm afraid I'll have to correct you on your calculations:
An E1 connection is 2048 kbit or 2 mbit - not 2.048 mbit/s.
E1 is actually a bundle of 32 64kbit channels (timeslots) over the same physical medium, where it is either possible to use all 32 timeslots for data (unframed E1), or where 1 64kbit timeslot is being used to transmit timeslot information to the interface placed by the telco (framed E1) - thus having an actual data rate of 2048-64=1984 kbit.
A 1984 kbit connection could well be what the university has ordered, if the telco is using 1 channel for timeslot synchronisation (very common here in Belgium).
Using a large compressed file over FTP for speedtesting is indeed a good way to have an indication of the linespeed, but doesn't cut it to get a good picture.
Using MRTG on your router (probably cisco 2600-ish) will yield far more correct results
A weakness in the RC4 encryption algorithm, where the usage of certain weak keys can "leak" bits of the secret key.
Static bits in the ethernet frames. Since they are SNAP frames, the first byte of the frame is always 0xaa.
The scary part of the paper is that the attack didn't rely on the poort initialisation vector. So it will work on networks with the random IV feature being implemented in the latest lucent firmware.
And people who have laptops in a company, are more likely to have a PDA as well (where I work, anyway).
I've had my share of Dell Latitude's with broken serial ports because of the Palm V Cradle, and these MB's were replaced by Dell Technicians multiple times without any problems. But it's a pain, especially if you are trying to emergency-flash a cisco router over the serial console, with some very impatient client watching your every move. Bad timing to figure out that your laptop's serial port has been blown to smithereens just hours before:).
Palm's Cradle has zapped many-a-MB, but filing a class-action suit is probably a bit overreacted. That's what you get for living in the land of the free.
If the VPN-product is well-configured, and secured by a good method (public/private key pair), there is little or nothing to gain by limiting the access to the VPN server to a few private IP's.
Unless you're using the IP address as sole authentication --in which case you deserve to be spanked mercilessly-- having a dynamic IP is a non-issue.
Even with VPN, road warriors should have very restricted capabilities, since the chances that their (personal) workstations get compromised are much bigger, and can have pretty big consequences if they have unlimited access on the internal network. IT staff should focus on keeping these PC's secured in stead of nagging about limited IP access to the VPN server.
Slashdot Mirror
With tapes, you just get a new drive.
My guess is that Linus wants a solution in which he can keep that kind of fine-grained control over the kernel, which conflicts with trusting someone else to do parts of the job - which is a necessity in the "span of control". (2 Battalion, attack objective Oscar... Bob: machinegun, Carl: mortar,
If there is a revolution, it's not per se "same shit, different name": I think any kind of revolution people are referring to has the goal of establishing a different modus operandi, be it CVS, a comittee, patch penguin, ... Replacing one dictator with another won't help, unless there's someone with supernatural powers I haven't yet heard of :-)
As long as you yourself think you're the best person on this planet to do the job, no alternative is going to be "better"...
</TONGUE-IN-CHEEK>
It's exactly that attitude that has done good for the linux kernel in shaping it, but can be equally damaging to that same kernel. Linus doesn't exactly have a 'small' ego :-)
Fessing up "I'm a bastard." doesn't do diddly squat to help resolve the problem.
I'm really curious what would happen if Linus just "disappeared" from the planet: it could possibly be a complete disaster, or a gift from heaven to get the kernel development more organised. I know some big companies who would be more than happy to provide an "alternative" ;-)
I agree to a certain degree that not all drivers should always be included in the kernel, but what's kept in, and what has to go? For example: filesystems - way too many of them, but you can't boot without support compiled in, or changing some real stuff on the booting process.
It doesn't matter how many maintainers there are: Linus can only work through a specific amount of code/patches per day/week/month. More maintainers result in more patches being dropped, and subsequently in more efforts to keep their patches up-to-date with the kernel.
This is really hurting development, and is frustrating a lot of people who are involved in the kernel with the risk of losing them.
Anyhow: Linus does what he likes, but it's exactly that kind of attitude that will hurt Linux in the longer run - both in technological as reputational (?) way.
I just visited some sites from which I hoped that they dissappeared completely from cyberspace. The only defense I've got now are the old cryptic URLs of these monstrosities... Indexing that database would be a disaster, especially with an unusual name like mine...
(Yes, I was stupid enough to use my real name
Damn you, wayback
They've also acquired the fasttrack licence.
Users will be required to agree to new terms of usage, the next time they log in.
RAID offers good protection for some things: hardware failure (ie: HD crash) and uptime. That aren't the only woes, however... You can loose data in a lot of ways:
Disaster (fire, quake, flood, nuff said)
Hardware failure (disk, controller, ...)
OS failure (FS corruption, ...)
Application failure (User space applications malbehaving, virii, ...)
User failure (accidental deletes, experimental children - trust me on this one ;-)
:)
...) are a plus, but more cumbersome.
RAID will protect you from the second, but will happily add nothing in case of any of the other failures. Backing up to another media is a necessity.
Adding an extra disk (or two, or three), and some tar/cpio cronjobs will add basic protection. (No disaster recovery for you, unless it's off-site
Removable harddrives (firewire, frames,
Tape is considered a more 'trustworthy' backup medium because the mechanism and data storage are separated (ie: tape drive / tape), while in a HD it's in one single package, and it's not as easy to replace the logic board/stepper motor if this flunks. With tape it's easier: just get a new tapedrive.
Anyhow: don't rely on RAID to save your data - it won't.
Is cyberspace part of some geographical territory, or should it have it's own legislation and jurisdiction (based on global interests), or will it be an anarchy by design?
As a European (Belgian) citizen, I'm wondering why US legislature is trying to take control of a network, that isn't US-only anymore for some time now. Both the DecSS/Sklyarov cases are quite frightening.
People who find entering an email adres a challenging task, most probably won't install this kind of software themselves. They will use it if it's built-in into their mail client. Adding clear and simple support for marking specific sources/messages would be an obvious feature for such a client.
E-mail isn't really built for broadcasting: websites, NNTP (to name a few) are far better solutions to accomplish the same goal. Unless the content is personalize, but then injecting hashes wouldn't pose a threat anymore.
You are absolutely correct.
This is how I would do it:
Strip HTML/markup language, so that we get plain text of the message.
Strip all "meaningless" characters from the text, keep only alphabetic (or alphanumeric) characters, no spaces or punctuation.
Uppercase everything.
:-)
We now have one string, with all the meaningful characters of the email, which makes it quite hard for spammers to vary much without mutilating the message they're trying to convey.
Pick a 8 entry points in this string based on the occurance a number of well-chosen, predefined two-character combinations that are likely to be found in English text(*) - these need to be defined upfront. There are lots of texts available in the gutenberg project to analyze to get to such a set.
This is hard: we need to find a good balance between physical location in the string, and the occurance of the combinations we have defined, so that we can take a broad "sample" of the text. Luckily for us , spammers tend to send long messages
Now we compute the hash of the fragments, defined by our entry-points and a fixed length. These hashes combined provide a "real big signature" of the spam message. Pick the last two bytes of every hash, and stick them together for a "small signature" that can be used for searching/matching. We need to define our protocol for searching the catalogue in such a way that when a partial match is found using the small signature, we can retrieve the full signature to check further.
Based on this we have a rating from 0/8 -> 8/8 for the probability of a mail being a spam message. End user settings can define what is destined for the bitbucket, and what goes in your mailbox.
In the end, spammers can (and will) try to circumvent these measures, but it would be hard and (hopefully) time-consuming, and it will require them to mutilate their messages to be undetected. Of course, this system only works properly when people are willing to submit spam fingerprints to the catalogue servers.
Anyway, that's my 0.02 EURO...
(*)Of course, English isn't the only language being used in spam, but I guess it's the most prevalent here. You can ofcourse apply the same principle to any language. Heck, if you really want to push the envelope, you can try to detect the language (character frequency analysis and checking for very common words).
Injecting random hashes into the network won't result in valid emails being tagged, but can flood/DOS the catalogue machines.
It would be possible to create hashes for a number of "probable" emails, but diversity in messages is so big, the chances are quite slim to actually stop a legitimate mail.
I can appreciate your side of the problem: it probably sucks to bring in your laptop for repairs and having to wait for [days|weeks|months] to get it back. But as far as I can see, Dell is fulfilling it's obligations by replacing the hinges during the warranty period free of charge: carry-in warranty is simple: you send the faulty device, they fix and send back. It's the easiest and cheapest for them (even if they do pay for transport & packaging) - but that's reflected in the pricing of the setup you bought.
The optional support packs (e.g.: Next Businessday On-site) are well worth the extra money: if you have a problem, within a few days at most there's a Dell repair engineer at your place with spare parts. Time needed: 30 minutes.
Asking for a replacement is really out of the question because:
The unit is two years old - nearly antique.
The hinges are a very minor part of the machine.
If the demand's there (Dell always looses on repairs) it could well be that newer hinges are retrofitted to your model of laptop. We have had laptops where the CPU-shield/cooler was replaced with a newer model, because the CPU got loose a lot in a specific Lattitude model; same goes for the lip (?) to keep the laptop closed which kept breaking - a newer more sturdy replacement was retrofitted without a problem.
I can imagine that it's far from optimal in your case, but Dell support is imho not too shabby - even in your case: other manufacturers could've called it "misusing the unit", and do zilch.
Damn!
I really meant "XOR with one input always 1"
</SLAP>
<NITPICK>
Due to the nature of bits (being 0 or 1), changing a bit means flipping them from 0 to 1 of vice versa. Changing *all* bits, would mean flipping them all, i.e. a XOR operation.
Changing a single input bit will change *some* output bits, not all of them. Would be a pretty useless hash algorithm
</NITPICK>
It's all about learning the basic fundamentals of programming, algorithms, data structures, different ways of solving things, lot's of theory - it's called "computer SCIENCE", remember.
Scheme is a good teaching language for a lot of reasons:
Most CS students nowadays have experience with computer "programming": VB, Delphi, C, C++, Java, Javascript,... nearly everybody has some experience with some programming language. The problem is that a lot of this experience isn't always built on the proper fundamentals, they're mostly about solving a particular problem without knowing why they should use data structure X or algorithm Y. The usage of Scheme as a teaching language has the advantage that most (if not all) students are forced to learn a new language, which probably isn't at all similar to what they're used to - enabling the teachers to start from scratch. That way, there aren't differences in the level of knowledge of the students, also a plus.
The language structure of scheme is very flexible: most (if not all) fundamental bits can be dealt with properly in Scheme: procedural programming, heaps of different data structures, OOP,
I do agree that other languages (be it C, C++, Java, Pascal, Fortran, O'Caml, Eiffel,
With the boom of IT and internet the last 5 years, there are so many programmers out there that lack those proper fundaments. I'm not saying that they aren't any good, but there are a lot of people that don't have a grip on what lies beneath - which is a pity.
Don Knuth showed us that computer programming is an art, not based on a specific programming language, and I tend to agree with him
I'm afraid I'll have to correct you on your calculations:
An E1 connection is 2048 kbit or 2 mbit - not 2.048 mbit/s.
E1 is actually a bundle of 32 64kbit channels (timeslots) over the same physical medium, where it is either possible to use all 32 timeslots for data (unframed E1), or where 1 64kbit timeslot is being used to transmit timeslot information to the interface placed by the telco (framed E1) - thus having an actual data rate of 2048-64=1984 kbit.
A 1984 kbit connection could well be what the university has ordered, if the telco is using 1 channel for timeslot synchronisation (very common here in Belgium).
Using a large compressed file over FTP for speedtesting is indeed a good way to have an indication of the linespeed, but doesn't cut it to get a good picture.
Using MRTG on your router (probably cisco 2600-ish) will yield far more correct results
They also have firewave (no typo) cards as options in their desktop PCs, and they come pretty cheap (I think it's about 25 EUR for the card).
A weakness in the RC4 encryption algorithm, where the usage of certain weak keys can "leak" bits of the secret key.
Static bits in the ethernet frames. Since they are SNAP frames, the first byte of the frame is always 0xaa.
The scary part of the paper is that the attack didn't rely on the poort initialisation vector. So it will work on networks with the random IV feature being implemented in the latest lucent firmware.
I've had my share of Dell Latitude's with broken serial ports because of the Palm V Cradle, and these MB's were replaced by Dell Technicians multiple times without any problems. But it's a pain, especially if you are trying to emergency-flash a cisco router over the serial console, with some very impatient client watching your every move. Bad timing to figure out that your laptop's serial port has been blown to smithereens just hours before :).
Palm's Cradle has zapped many-a-MB, but filing a class-action suit is probably a bit overreacted. That's what you get for living in the land of the free.
Microsoft don't have their own virusscanner anyhow, so perhaps we can expect Microsoft Viruscan pretty soon ;-)
Unless you're using the IP address as sole authentication --in which case you deserve to be spanked mercilessly-- having a dynamic IP is a non-issue.
Even with VPN, road warriors should have very restricted capabilities, since the chances that their (personal) workstations get compromised are much bigger, and can have pretty big consequences if they have unlimited access on the internal network. IT staff should focus on keeping these PC's secured in stead of nagging about limited IP access to the VPN server.