You've got a point, but I've got a troubleshooting tips for you to avoid such situations in the future.
When a network application doesn't work.. the first thing I would do is to use tcpdump (or ethereal/wireshark) to see whether the packets arrive properly. If they do, 'lsof' or 'netstat' to check whether something listens on the port the packet is destined for.. and finally 'strace' to see if the receiving application actually receives anything.
With those tools in your new and now probably improved toolset - it gets way, way easier to debug almost any kind of problem:-)
Afraid I haven't used a Microsoft operating system for more than 10 years, and my linux boxen chugs quite nicely along with an old processor, thank you very much.:)
I'm sorry, but the computer explosion started around 1993.:) And about technologies.. the REAL floppy drives was dead in 1993. Actually, two generations of floppy drives were dead..
- Furthermore, disk drives. They were no longer huge behemoths, but small nifty ones. - Remember 8250 UART serial ports? Long dead. - Remember 2400bps modems? Long dead. How about accoustic couplers? - We had pensioned CGA and EGA - and gone for VGA by 1993. SVGA came soon afterwards.
New technologies came and went darn fast back in 1993, just as they do now. Hell, back in 1993, 286 machines were going unusable. These days I have no problems using a machine from 9 years ago thinking it's fast enough. In 1993, using a computer from 1984 was a painful experience. Back then, I had a need to upgrade my CPU, my hard-drives, and so forth every so often - since they were quite simply not fast enough.
These days, on the other hand, I still am quite happy with almost a decade old machines, chugging around for various tasks. They're more than fast enough.
In short, I don't think 16 years old technology will be much of a problem. I think it'll be less of a problem with technology bought "now", than it is now with technology from 1993..
So, what do you do when the guy shows you his ID? Let him in? Or do you make a point of always noting down what the ID says, closing and locking the door, figuring out what the company's phone number is, then call them and verify that it is the correct person at your door?
If not - how do you know whether the ID is fake or not?
Here is a quote directly from Peter I received Saturday, he asked to have it passed on to the list. -Snip- >I'd love to hear some thoughts on this from security and data experts >out there. People should note the epilogue to the paper:
Epilogue
In the time since this paper was published, some people have treated the 35-
pass overwrite technique described in it more as a kind of voodoo
incantation to banish evil spirits than the result of a technical analysis
of drive encoding techniques. As a result, they advocate applying the
voodoo to PRML and EPRML drives even though it will have no more effect than
a simple scrubbing with random data. In fact performing the full 35-pass
overwrite is pointless for any drive since it targets a blend of scenarios
involving all types of (normally-used) encoding technology, which covers
everything back to 30+-year-old MFM methods (if you don't understand that
statement, re-read the paper). If you're using a drive which uses encoding
technology X, you only need to perform the passes specific to X, and you
never need to perform all 35 passes. For any modern PRML/EPRML drive, a few
passes of random scrubbing is the best you can do. As the paper says, "A
good scrubbing with random data will do about as well as can be expected".
This was true in 1996, and is still true now.
Looking at this from the other point of view, with the ever-increasing data
density on disk platters and a corresponding reduction in feature size and
use of exotic techniques to record data on the medium, it's unlikely that
anything can be recovered from any recent drive except perhaps one or two
levels via basic error-cancelling techniques. In particular the the drives
in use at the time that this paper was originally written have mostly fallen
out of use, so the methods that applied specifically to the older, lower-
density technology don't apply any more. Conversely, with modern high-
density drives, even if you've got 10KB of sensitive data on a drive and
can't erase it with 100% certainty, the chances of an adversary being able
to find the erased traces of that 10KB in 80GB of other erased traces are
close to zero.
No, it is not being prudent - it is being panicky.
Contingency plans in this case is simple. If shit hits the fan bigtime and the entire CentOS stuff gets swallowed into the earth, well, then it's time to cough up money to pay redhat. And the good thing? No reinstallation needed.
CentOS is just RedHat recompiled, and lacking two files or somesuch. Rather great.
Seriously considering migrating to another distro completely, with all the work that would involve, doesn't seem prudent at all.
They did what they had to do, to get control over some important aspects of the project - while all the main developers were still behind it.
If you had bothered to spend about one minute researching the topics before you had meetings with "your team", you would have discovered that the developers openly said that everything would continue as before. Worst case scenario: They would've have to move the domain-name and get new IRC channels, plus they would have lost some donations.
That you overreacted like some crazy clown.. well, that's entirely your fault, and nobody elses.
Anti virus software has been breaking stuff for more than a decade. There will always be false positives, and there will always be stuff that hasn't been tested, thought about, and so forth.
Of course, now, after this incident, they'll add a unittest to make sure that this exact thing doesn't happen again, and maybe add some for other music services. But hey - this is NOT something that should be thought of as wrong, foolish or whatever. These things *happen*.
Anti-virus software has signatures, heuristics, and so forth. It'll be wrong from time to time. It's actually just business as usual.
I'm not sure this is a good idea.. but it might be.
How about trying to expose the main ways of programming, at once?
Assembler = The barebones. C = Everybody still uses it. Python = Easy to use, etc. LISP = Apparantly very important, but I wasn't exposed to it early enough - and still don't get it.
Whether or not to show Perl depends on whether you love it or hate it.:P
The best way to get to the fun roles, are by teaching yourself how things work. This is usually not accomplished at schools, but with you yourself playing around with things.
The easiest way, from my point of view, is starting to play around with various unix systems.
I don't know the current state of slackware, but back when I wanted to learn linux, I tried getting slackware to work on my workstation, including X. I tried and failed for a couple of weeks - but I learned a huge lot from it. I went on to install Debian. These days - I'd suggest going the Gentoo route, and then try to build your own linux distro from scratch. See: http://www.linuxfromscratch.org/
Buy the book "Running Linux". Read it, understand it.
Don't stop there. After playing around with linuxfromscratch and reading 'Running Linux', I would go on to download OpenBSD, and read the FAQ's/Howto's and most importantly - the man-pages you're referred to after installation. There is an incredible amount or good documentation for OpenBSD. It's easy to read - and you learn a lot - fast.
After playing around with OpenBSD - I would go on to play around with NetBSD. When I played around with it (1.5.2, I think) - it was a very nice and barebone unix. Documentation wasn't perfect, but that lead me to learn even more.
FreeBSD is very nice - but last time I played around with it, it suffered from having too many users having written too much contradicting information. It was more difficult to pick up than Open/Net-BSD, but it's way more usable for an end user. THAT, however, should not be one of your considerations when you want to learn. Pick the best documented one, not the one that has the most fancy features for your desktop.:)
In the process of installing and fooling around with all these systems, try to build your own firewall for your home computers. Read up on firewalling - it's a good goal - as to create a useful firewall you'll need to teach yourself TCP/IP in the process.
This book will teach you a lot, and now that you've used Unix for a while - you'll understand quite a bit of it. Not all, but it's a good read, and will teach you even more of what you need to know.
After fooling around with all this, or preferably in between and along the way, you'll need to:
- Configure BIND (DNS), and maybe look at djbdns
- Configure postfix/exim, and maybe also take a look at qmail
- Configure a dhcp-server.
- Fool around a bit with apache, building it from source and swearing at it.:)
- Set up an nntp-server.
- Maybe set up an IRC server to fool around with.
Also, it's important to get to know a couple of programming languages. Not necessarily to expert level, but it's important that you fool around with C (not C++, but you might want to learn a bit of that in addition) - plus a couple of scripting languages. It's important that you teach yourself bash (since it's probably your shell) - in addition to either perl or python. You'll find camps that say that perl is more important, while other camps will claim that python is more important. I went with perl first, and I'm now trying to teach myself python.
Now, this is a huge list of things to play around with. There are lots more - but it should give you a good 12-24 months of fooling around and studying. With all the knowledge you gather from this, if you complete it, you should be ready to get yourself fun, challenging and other frustrating work.:-)
I don't see why there shouldn't be any buzz about a service that has been launched other places, but not in the US yet. You mean you american guys never hear about products before they're launched in the US ?
sheez. Talk about having ones head stuck in the sand.
Running the code shouldn't require any particular permissions.. but installing? That's an admin task, not a user task.
We have a very, very, very different worldview.
Admin tasks are installing the operating systems and the default profiles. It's creating the authentication mechanism. It's automating the installation process. It includes designing the network, configuring the firewalls and IDS systems. It includes creating / making available a system for automatic updates. It includs having the administrator access to the "domain", and thus to all the workstations.
Individual users on the other hand, have been given a login and password. They have access to the programs already installed. They also have access to their home directory, where they can put the extra stuff they need. That's where they can install the extra software needed. That's where they can pull down stuff and compile it themselves - if need be.
It's not an admin task to restrict the users productivity. It's an admin task to enable them to do their work. It's an admin task to help them making smart choices.
Installing software is an admin task. AND Installing software is a user task.
This isn't tips for preventing lockups. If it's a true lock-up, it cannot be fixed. If you read my original message, I called these "soft lockups".
If the kernel crashes, you're fscked. I've experienced that very few times (less than 10) since I switched to linux in the 90s. Most of those times were due to either hardware-trouble. Some of them were due to driver problems. And one or two due to what I think was kernel bugs.
What usually happens, however, is that your computer doesn't freeze, but some software starts hogging X in some ways or another. X is a tad silly - as it requires quite clean code. One program can interfere with other programs and "take over" stuff. One program can in effect make it seem like your computer freezes.
To explain my "solutions" in a tad more detail.
1. ctrl+alt+F(1-8). That is, F1 - F8. Log in there, find the process, kill it.
This one tells the kernel to switch you to another tty. The X tty usually runs on tty8 (or was it 7? Can't remember). The others have a text-based terminal waiting for you to log on. You can log in, use ps, top and other programs to try to figure out which program is hogging X, and kill it. After killing it you use ctrl+alt+f7 (or was it f8?) to return to X and see if it's now unfrozen. If it is -- great. It wasn't a real lockup.
Unfortunately there is no real way of "solving" this, as X is the mainstay of graphical interfaces in Unix -- and it's a 10+ year old design issue that is behind this. It cannot be fixed without breaking waaaay too much stuff.
2. If the machine doesn't take your keys immediately, try "alt+sysrq r" , which switches your keyboard from XLATE to RAW mode. Then go to 1.
This is to make sure that the kernel will get your keys. I haven't checked, but I guess it's to avoid some programs from intercepting the keys by accident. Again, this make sure the kernel intercept the keys.
3. ssh into the machine from another machine and kill the misbehaving process
This is simple enough. As long as you have sshd running and the machine isn't hung - you can do this instead of point 1 and 2. There is a couple of reasons of doing it this way instead of 1 and 2.
- A few years ago, many 3d chipsets were buggy with X. If you switched to another terminal and then back to X, X would really screw you over and wouldn't come back without killing. By sshing into the machine, you avoided that problem.
- If you've chosen (or your distro has chosen) to not have other terminals available (You can modify this manually by editing/etc/inittab).
4. ctrl+alt+backspace (kills X and all applications running in your X session).
Sometimes there are bugs in X, and this is the easiest solution. The problem of course is that you'll probably lose your work. You can also do this stuff by ssh'ing into the machine and just kill X.
I have had system lockups, but not often (not every year). However, if your system locks up "softly" it's very easy:
1. ctrl+alt+F(1-8). That is, F1 - F8. Log in there, find the process, kill it. 2. If the machine doesn't take your keys immediately, try "alt+sysrq r" , which switches your keyboard from XLATE to RAW mode. Then go to 1. 3. ssh into the machine from another machine and kill the misbehaving process 4. ctrl+alt+backspace (kills X and all applications running in your X session).
Knowing the above tricks, you'll get way fewer lockups. The usual suspects for lockups in my case has been funky graphics cards and laptops with funny sleep/suspend/hibernate modes.
Self signed certificates means LESS security, UNLESS you have verified the certificate (or its fingerprint) out of band.
Why?
Ranking: 1. Signed certificates are, in theory (but not in practice), safe. 2. No certificate means your communication may be sniffed. 3. Self-signed / Wrong URL certificates indicates that someone is a man-in-the-middle.
Yes, there might be some cheapass on the other end. However, that is up to you to verify. If you out-of-band verify that, and manually add the certificate on your end, then the 3 would go up to a number 1 - after verifying the fingerprint. Until that, it's an indication that it's a man in the middle.
In other words, that someone is actively sniffing the conversation.
The entire idea that self-signed certificates gives ANY security is insane! If someone is able to intercept the traffic and listen to it - they are most probably able to be a man in the middle. In other words - it provides absolutely no security what-so-ever !... unless it's verified out of band, but then it would be added to your local certificate store, and thus be a number 1.
That you have been rated as 5 is completely nuts. You don't understand the security model, and neither does the moderators.
This indicates a broken grading system with a bad kludge of a hack on top.
If someone gets 5% at first half, and then majorly improves during the second half and gets 80% - and would easily be able to redo the tests of the first half and get 80% on them too at this time -- then of course the final grade should be around 80% - and the first grading should be ignored completely.
It's the actual knowledge at the end of the semester that should be graded - not the performance throughout the year. It's the knowledge one possesses at the end that is important.
Slashdot Mirror
Wrong.
0.01*0.01 = 0.0001
Which is ten times better than 0.001
You've got a point, but I've got a troubleshooting tips for you to avoid such situations in the future.
When a network application doesn't work .. the first thing I would do is to use tcpdump (or ethereal/wireshark) to see whether the packets arrive properly. If they do, 'lsof' or 'netstat' to check whether something listens on the port the packet is destined for.. and finally 'strace' to see if the receiving application actually receives anything.
With those tools in your new and now probably improved toolset - it gets way, way easier to debug almost any kind of problem :-)
Cheers.
Afraid I haven't used a Microsoft operating system for more than 10 years, and my linux boxen chugs quite nicely along with an old processor, thank you very much. :)
I'm sorry, but the computer explosion started around 1993. :) And about technologies.. the REAL floppy drives was dead in 1993. Actually, two generations of floppy drives were dead..
- Furthermore, disk drives. They were no longer huge behemoths, but small nifty ones.
- Remember 8250 UART serial ports? Long dead.
- Remember 2400bps modems? Long dead. How about accoustic couplers?
- We had pensioned CGA and EGA - and gone for VGA by 1993. SVGA came soon afterwards.
New technologies came and went darn fast back in 1993, just as they do now. Hell, back in 1993, 286 machines were going unusable. These days I have no problems using a machine from 9 years ago thinking it's fast enough. In 1993, using a computer from 1984 was a painful experience. Back then, I had a need to upgrade my CPU, my hard-drives, and so forth every so often - since they were quite simply not fast enough.
These days, on the other hand, I still am quite happy with almost a decade old machines, chugging around for various tasks. They're more than fast enough.
In short, I don't think 16 years old technology will be much of a problem. I think it'll be less of a problem with technology bought "now", than it is now with technology from 1993..
So, what do you do when the guy shows you his ID? Let him in? Or do you make a point of always noting down what the ID says, closing and locking the door, figuring out what the company's phone number is, then call them and verify that it is the correct person at your door?
If not - how do you know whether the ID is fake or not?
Let me pull a bugtraq posting from 2005 out for perusal. There are other interesting tidbits in that thread too.
http://seclists.org/bugtraq/2005/Jul/0464.html
===
From: dave kleiman
Date: Sun, 24 Jul 2005 15:30:30 -0400
Here is a quote directly from Peter I received Saturday, he asked to have it
passed on to the list.
-Snip-
>I'd love to hear some thoughts on this from security and data experts
>out there.
People should note the epilogue to the paper:
Epilogue
In the time since this paper was published, some people have treated the
35-
pass overwrite technique described in it more as a kind of voodoo
incantation to banish evil spirits than the result of a technical analysis
of drive encoding techniques. As a result, they advocate applying the
voodoo to PRML and EPRML drives even though it will have no more effect
than
a simple scrubbing with random data. In fact performing the full 35-pass
overwrite is pointless for any drive since it targets a blend of scenarios
involving all types of (normally-used) encoding technology, which covers
everything back to 30+-year-old MFM methods (if you don't understand that
statement, re-read the paper). If you're using a drive which uses
encoding
technology X, you only need to perform the passes specific to X, and you
never need to perform all 35 passes. For any modern PRML/EPRML drive, a
few
passes of random scrubbing is the best you can do. As the paper says, "A
good scrubbing with random data will do about as well as can be expected".
This was true in 1996, and is still true now.
Looking at this from the other point of view, with the ever-increasing
data
density on disk platters and a corresponding reduction in feature size and
use of exotic techniques to record data on the medium, it's unlikely that
anything can be recovered from any recent drive except perhaps one or two
levels via basic error-cancelling techniques. In particular the the
drives
in use at the time that this paper was originally written have mostly
fallen
out of use, so the methods that applied specifically to the older, lower-
density technology don't apply any more. Conversely, with modern high-
density drives, even if you've got 10KB of sensitive data on a drive and
can't erase it with 100% certainty, the chances of an adversary being able
to find the erased traces of that 10KB in 80GB of other erased traces are
close to zero.
Peter.
===
No, it is not being prudent - it is being panicky.
Contingency plans in this case is simple. If shit hits the fan bigtime and the entire CentOS stuff gets swallowed into the earth, well, then it's time to cough up money to pay redhat. And the good thing? No reinstallation needed.
CentOS is just RedHat recompiled, and lacking two files or somesuch. Rather great.
Seriously considering migrating to another distro completely, with all the work that would involve, doesn't seem prudent at all.
Grow a pair of balls.
Seriously.
They did what they had to do, to get control over some important aspects of the project - while all the main developers were still behind it.
If you had bothered to spend about one minute researching the topics before you had meetings with "your team", you would have discovered that the developers openly said that everything would continue as before. Worst case scenario: They would've have to move the domain-name and get new IRC channels, plus they would have lost some donations.
That you overreacted like some crazy clown .. well, that's entirely your fault, and nobody elses.
Seriously.
Anti virus software has been breaking stuff for more than a decade. There will always be false positives, and there will always be stuff that hasn't been tested, thought about, and so forth.
Of course, now, after this incident, they'll add a unittest to make sure that this exact thing doesn't happen again, and maybe add some for other music services. But hey - this is NOT something that should be thought of as wrong, foolish or whatever. These things *happen*.
Anti-virus software has signatures, heuristics, and so forth. It'll be wrong from time to time. It's actually just business as usual.
So, why is this news?
I'm not sure this is a good idea.. but it might be.
How about trying to expose the main ways of programming, at once?
Assembler = The barebones.
C = Everybody still uses it.
Python = Easy to use, etc.
LISP = Apparantly very important, but I wasn't exposed to it early enough - and still don't get it.
Whether or not to show Perl depends on whether you love it or hate it. :P
We reached Oct 1. a long time ago. AOL shut down their usenet access years ago.
The best way to get to the fun roles, are by teaching yourself how things work. This is usually not accomplished at schools, but with you yourself playing around with things.
The easiest way, from my point of view, is starting to play around with various unix systems.
I don't know the current state of slackware, but back when I wanted to learn linux, I tried getting slackware to work on my workstation, including X. I tried and failed for a couple of weeks - but I learned a huge lot from it. I went on to install Debian. These days - I'd suggest going the Gentoo route, and then try to build your own linux distro from scratch.
See: http://www.linuxfromscratch.org/
Buy the book "Running Linux". Read it, understand it.
Don't stop there. After playing around with linuxfromscratch and reading 'Running Linux', I would go on to download OpenBSD, and read the FAQ's/Howto's and most importantly - the man-pages you're referred to after installation. There is an incredible amount or good documentation for OpenBSD. It's easy to read - and you learn a lot - fast.
After playing around with OpenBSD - I would go on to play around with NetBSD. When I played around with it (1.5.2, I think) - it was a very nice and barebone unix. Documentation wasn't perfect, but that lead me to learn even more.
FreeBSD is very nice - but last time I played around with it, it suffered from having too many users having written too much contradicting information. It was more difficult to pick up than Open/Net-BSD, but it's way more usable for an end user. THAT, however, should not be one of your considerations when you want to learn. Pick the best documented one, not the one that has the most fancy features for your desktop. :)
In the process of installing and fooling around with all these systems, try to build your own firewall for your home computers. Read up on firewalling - it's a good goal - as to create a useful firewall you'll need to teach yourself TCP/IP in the process.
When you feel that you've mastered most of this (you haven't, but that's beside the point) - you should've spent 6-12 months. It's now time to pick up "Advanced Programming in the Unix Environment". See: http://www.amazon.com/Programming-Environment-Addison-Wesley-Professional-Computing/dp/0201563177
This book will teach you a lot, and now that you've used Unix for a while - you'll understand quite a bit of it. Not all, but it's a good read, and will teach you even more of what you need to know.
After fooling around with all this, or preferably in between and along the way, you'll need to: :)
- Configure BIND (DNS), and maybe look at djbdns
- Configure postfix/exim, and maybe also take a look at qmail
- Configure a dhcp-server.
- Fool around a bit with apache, building it from source and swearing at it.
- Set up an nntp-server.
- Maybe set up an IRC server to fool around with.
Also, it's important to get to know a couple of programming languages. Not necessarily to expert level, but it's important that you fool around with C (not C++, but you might want to learn a bit of that in addition) - plus a couple of scripting languages. It's important that you teach yourself bash (since it's probably your shell) - in addition to either perl or python. You'll find camps that say that perl is more important, while other camps will claim that python is more important. I went with perl first, and I'm now trying to teach myself python.
Now, this is a huge list of things to play around with. There are lots more - but it should give you a good 12-24 months of fooling around and studying. With all the knowledge you gather from this, if you complete it, you should be ready to get yourself fun, challenging and other frustrating work. :-)
I don't see why there shouldn't be any buzz about a service that has been launched other places, but not in the US yet. You mean you american guys never hear about products before they're launched in the US ?
sheez. Talk about having ones head stuck in the sand.
Yup, I've never heard of Spotify and I can't imagine why I'd be interested in this.
Amazing. Where have you been the last months?
It's just the most amazingly fast-growing music-site.
Oh, but it's not an american site. No wonder you haven't heard about it.
Military intelligence .. and today:
Religious tolerance
Business Ethics
American democracy
Except that the campaign in Norway is being run by:
- All major newspapers
- The state broadcaster
- The major consumer websites
- At least one bank/insurance company
What's a "wall of words" ?
Or maybe he, like me, haven't used windows since the 90s.
If asked to admin windows boxes, I would have to say no. I quite simply do not have a clue when it comes to windows. Not a clue at all.
Running the code shouldn't require any particular permissions.. but installing? That's an admin task, not a user task.
We have a very, very, very different worldview.
Admin tasks are installing the operating systems and the default profiles. It's creating the authentication mechanism. It's automating the installation process. It includes designing the network, configuring the firewalls and IDS systems. It includes creating / making available a system for automatic updates. It includs having the administrator access to the "domain", and thus to all the workstations.
Individual users on the other hand, have been given a login and password. They have access to the programs already installed. They also have access to their home directory, where they can put the extra stuff they need. That's where they can install the extra software needed. That's where they can pull down stuff and compile it themselves - if need be.
It's not an admin task to restrict the users productivity. It's an admin task to enable them to do their work. It's an admin task to help them making smart choices.
Installing software is an admin task.
AND
Installing software is a user task.
Oh, like computers from the 80s? ;P
http://en.wikipedia.org/wiki/Cray-2
The Cray-2 was immersed in liquid.
Okay, I'll explain in a tad more detail.
This isn't tips for preventing lockups. If it's a true lock-up, it cannot be fixed. If you read my original message, I called these "soft lockups".
If the kernel crashes, you're fscked. I've experienced that very few times (less than 10) since I switched to linux in the 90s. Most of those times were due to either hardware-trouble. Some of them were due to driver problems. And one or two due to what I think was kernel bugs.
What usually happens, however, is that your computer doesn't freeze, but some software starts hogging X in some ways or another. X is a tad silly - as it requires quite clean code. One program can interfere with other programs and "take over" stuff. One program can in effect make it seem like your computer freezes.
To explain my "solutions" in a tad more detail.
1. ctrl+alt+F(1-8). That is, F1 - F8. Log in there, find the process, kill it.
This one tells the kernel to switch you to another tty. The X tty usually runs on tty8 (or was it 7? Can't remember). The others have a text-based terminal waiting for you to log on. You can log in, use ps, top and other programs to try to figure out which program is hogging X, and kill it. After killing it you use ctrl+alt+f7 (or was it f8?) to return to X and see if it's now unfrozen. If it is -- great. It wasn't a real lockup.
Unfortunately there is no real way of "solving" this, as X is the mainstay of graphical interfaces in Unix -- and it's a 10+ year old design issue that is behind this. It cannot be fixed without breaking waaaay too much stuff.
2. If the machine doesn't take your keys immediately, try "alt+sysrq r" , which switches your keyboard from XLATE to RAW mode. Then go to 1.
This is to make sure that the kernel will get your keys. I haven't checked, but I guess it's to avoid some programs from intercepting the keys by accident. Again, this make sure the kernel intercept the keys.
3. ssh into the machine from another machine and kill the misbehaving process
This is simple enough. As long as you have sshd running and the machine isn't hung - you can do this instead of point 1 and 2. There is a couple of reasons of doing it this way instead of 1 and 2. /etc/inittab).
- A few years ago, many 3d chipsets were buggy with X. If you switched to another terminal and then back to X, X would really screw you over and wouldn't come back without killing. By sshing into the machine, you avoided that problem.
- If you've chosen (or your distro has chosen) to not have other terminals available (You can modify this manually by editing
4. ctrl+alt+backspace (kills X and all applications running in your X session).
Sometimes there are bugs in X, and this is the easiest solution. The problem of course is that you'll probably lose your work. You can also do this stuff by ssh'ing into the machine and just kill X.
I have had system lockups, but not often (not every year). However, if your system locks up "softly" it's very easy:
1. ctrl+alt+F(1-8). That is, F1 - F8. Log in there, find the process, kill it.
2. If the machine doesn't take your keys immediately, try "alt+sysrq r" , which switches your keyboard from XLATE to RAW mode. Then go to 1.
3. ssh into the machine from another machine and kill the misbehaving process
4. ctrl+alt+backspace (kills X and all applications running in your X session).
Knowing the above tricks, you'll get way fewer lockups. The usual suspects for lockups in my case has been funky graphics cards and laptops with funny sleep/suspend/hibernate modes.
Self signed certificates means LESS security, UNLESS you have verified the certificate (or its fingerprint) out of band.
Why?
Ranking:
1. Signed certificates are, in theory (but not in practice), safe.
2. No certificate means your communication may be sniffed.
3. Self-signed / Wrong URL certificates indicates that someone is a man-in-the-middle.
Yes, there might be some cheapass on the other end. However, that is up to you to verify. If you out-of-band verify that, and manually add the certificate on your end, then the 3 would go up to a number 1 - after verifying the fingerprint. Until that, it's an indication that it's a man in the middle.
In other words, that someone is actively sniffing the conversation.
The entire idea that self-signed certificates gives ANY security is insane! If someone is able to intercept the traffic and listen to it - they are most probably able to be a man in the middle. In other words - it provides absolutely no security what-so-ever ! ... unless it's verified out of band, but then it would be added to your local certificate store, and thus be a number 1.
That you have been rated as 5 is completely nuts. You don't understand the security model, and neither does the moderators.
slashdot needs more techies.
And norwegian. Where I grew up :P Not sure if it's swedish or norwegian in origin, but anyhow ...
This indicates a broken grading system with a bad kludge of a hack on top.
If someone gets 5% at first half, and then majorly improves during the second half and gets 80% - and would easily be able to redo the tests of the first half and get 80% on them too at this time -- then of course the final grade should be around 80% - and the first grading should be ignored completely.
It's the actual knowledge at the end of the semester that should be graded - not the performance throughout the year. It's the knowledge one possesses at the end that is important.
Bleh.
Broken sysem with a bad hack .