Not quite. The difference is that a plain upgrade will hold a package back if the new version has dependencies or conflicts which your system doesn't currently satisfy, while a dist-upgrade will automatically install new dependencies and remove any conflicts (usually obsoleted stuff, though not always) in order to meet the needs of the new version of the package.
The only time I don't use dist-upgrade is on the occasions when there's an inconsistency in the dependencies of some set of packages I use. Right now, for example, mozilla has been upgraded, but galeon (which I use) hasn't been built against the new version yet, so dist-upgrading would remove galeon so that the new mozilla can be installed. But I just look at what changes apt says it will make, notice that galeon is marked for removal, and just switch to using plain upgrades for a few days until the inconsistency is resolved.
That sort of situation is pretty uncommon though, and in most cases it's better to use dist-upgrade. Otherwise you're stuck with a bunch of old packages which aren't upgraded because the new version has spun off some functionality into a separate package, or depends on a different library (libgnutls vs. libssl, for example), and the plain upgrade won't handle the change.
The only time dist-upgrade will remove a package is when it's specifically incompatible with something else. For the general task of cleaning out old packages that you don't need anymore (libraries that nothing depends on anymore, for example), use debfoster.
That's interesting -- I'm running sid too, and GNOME still works perfectly fine for me. In the same timeframe, I upgraded from 2.4.24 to 2.6.1 (using my own merge of patch-2.6.1 into kernel-source.2.6.0), started using initrd, and migrated my root filesystem from reiserfs to XFS (/home made the change a few weeks ago). No problems whatsoever.
FWIW, "unstable" doesn't actually mean "has lots of problems". Bugs come up sometimes, generally minor, but I've been running unstable on my desktop for 3.5 years and my system is still running cleanly and smoothly. I've never had to reinstall the system, and the only time I've had to do major recovery work (reinstalling lots of packages) was when I damaged my filesystem by setting the hard drive into an unsupported DMA mode, entirely my own fault.
Rather than downloading binary packages from unstable, though, you should consider downloading the source packages ("apt-get source <packagename>") and building on your own system. You have to wait for the software to compile, but the benefit is that the resulting package uses your currently-installed versions of the dependencies, rather than the current unstable versions.
Actually, that's not where the name comes from, though it's an interesting interpretation that I hadn't heard before. Recursive acronyms started (as far as I know) with GNU, though, and Linus didn't write Linux with the original intent of using it with the GNU system -- that came later, when the Hurd kernel wasn't progressing fast enough and people needed another kernel to use with GNU.
IANAL, but doesn't copyright only apply to creative works? Error codes aren't a creative work -- they're entirely arbitrary, and all that matters is that they're the same from system to system. Nobody put any blood, sweat, & tears into deciding that the value of ENOENT should be 2 and not, say, 11235.
Not too surprising, since Windows has a significant head start -- it's always been a desktop OS, whereas Unix comes from a background of servers and workstations from before the idea of a "desktop" existed.
I don't see these technologies as "recreating" Windows, though... they're just implementing things that are useful in a desktop environment, which Microsoft has also found to be useful in a desktop environment and implemented already due to the aforementioned head start.
There are some interesting new ideas here though. I don't know much in detail about most of these technologies (I'm just starting to get into actual GNOME development), but for example, GConf has two significant improvements over the Windows Registry that I know of.
First of all, GConf stores schema as well as data. This is important because it means that conceptually, each key has a documented reason for its existance; it doesn't just happen to be left over from some app that was installed a year ago and then removed because it was buggy. And keys can have documentation strings, something the Windows Registry would greatly benefit from.
Second, and probably more importantly, GConf has a notification mechanism: applications can "listen" on a key, and receive notification when that key is changed. This is why a change made in the preferences window of one instance of an app can immediately take effect in all running instances, and AFAIK the Registry can't do this.
As for Nautilus, there are some things I wish it did more like Windows Explorer, most notably Explorer's horizontally-scrolling list view (where one click of the scroll wheel brings a whole column of icons into view, instead of just one or two at the bottom), but it's built on GNOME-VFS, which is a great idea in itself. Sure, Windows Explorer is really Internet Explorer so you can enter either a local path or an HTTP or FTP URI in the address bar, but can you install a package which adds support for SFTP URIs? I don't think so. And with the aid of GStreamer's GNOME-VFS module, you can (for example) take a stream from an SFTP location, run it through some processing, and store the output stream to a WebDAV location. You could probably even write a GStreamer module as a Bonobo component, so your workstation can make use of a codec installed on a server somewhere. You get the idea.
Actually, I think NT ACLs are simpler than standard Unix file permissions, while being more powerful at the same time. Why? Because they propagate down the tree. In Unix/Linux, each and every file has its own set of permission bits, initialized generally to the same value by the umask, but still stored separately even though the vast majority of files on most systems have the standard 644 (755 for directories) permissions.
Under the NT security model, you can set a permission on a directory and it's automatically inherited by files and subdirectories. The permission isn't individually defined thousands of times over. Newly-created files inherit permissions from their containing directory; if you have different permissions on two directories, files created in those two directories will have different default permissions. In Unix terms, that's like having a different umask associated with each directory. And later, if you want to change the permission on some part of the tree, (maybe adding write permission for a specific user), you just apply the new ACL to one directory and it propagates to everything below it; no need for a bit recursive chmod command.
Of course, most of the time you don't need per-directory umasks; you just need the typical "owner read-write, everyone else read-only" permissions. And to achieve that, no permission at all needs to be defined on a file; it's inherited from the parent.
Funny thing about those Molex connectors: when you turn them upside-down, they don't insert fully (of course), but they go far enough (by tilting downward slightly) that the pins can make contact. And since one side of the plug is 5v while the other side is 12v, connecting it upside-down means that the electronics get force-fed over twice as much current as they were meant to take.
If the lighting happens to be dim and you can't see which way the plug is oriented... yeah. I fried an 80GB Seagate Barracuda drive that way.
Thankfully, Seagate's RMA form doesn't ask how the damage occurred, (:-P), but I still lost about 60GB of data.
It's been a few years since I read "Neuromancer", but I'm pretty certain there's no mass human enslavement by AIs in that book. The concept of interfacing with a virtual world by direct brain connection might have come from "Neuromancer", (I don't know whether there's precedent for that), but not much else.
I just saw RotK last night, and I didn't notice at the time, but thinking back on it, I don't think they showed the "green screen" before any of the previews. I guess they figure if it's approved for "all audiences" then there's no one in the audience who it's not OK for, so there's no need to put up a notice.
Anyway, before the previews even started, I'd seen the sign for this hanging in the lobby, and pointed it out to the friends I was with, saying something along the lines of "hey, cool, they're making an 'I, Robot' movie!" The three of us then looked at it for a moment and decided that it looked like an ad for a product, not a movie, since it just had a picture of a robot and some text (I don't remember the words) that didn't include things like actors' names. So when we went into the screenroom and saw the preview, we didn't even consider the possibility that it might be a movie trailer.
Nobody seems to have pointed this out yet, so I will.
Imagine for a moment that you're a phone-support tech working at, say, Dell or some other consumer PC manufacturer. You get a call from a customer who says they can't "get on the Internet".
You ask this customer, "What Internet service are you using?" and the customer responds "Netscape".
Until now, anyone hearing such a response could immediately recognize that the user was talking about their browser, not their ISP (which is what the question referred to). Now, that conclusion can't be made.
With the introduction of this service, someone who is "using Netscape" is either:
Using the Netscape browser with some unspecified ISP, or
Using the the Internet Explorer browser with the Netscape ISP
Needless to say, this makes it difficult to ascertain which is the case when talking to a user who doesn't know the difference.
Actually, nowhere does it say that root privilege was used at all -- the attack was against a PHP interpreter embedded in an Apache binary running as www-data, and it started a new process which also ran as www-data. The article summary is a bit misleading.
Must've been. Look at the terminology for processes: parents have to wait for their children to die and then reap them, so they don't become zombies.
It's actually "daemon", not "demon", but that reminds me of a funny story. You know how when an email bounces, the returned message often comes from "mailer-daemon" at whatever domain your message was addressed to? Back when I was in high school, I once heard a teacher who was checking his mail exclaim, "mailer demon???", clearly thinking (at least until he read the text of the bounce message) that some sort of devilish creature was interfering with the delivery of his email.
Clearly, crypt() was meant to die: just look at its name!
As Schneier says on the first page of Chapter 1 of "Applied Cryptography",
(If you want to follow the ISO 7498-2 standard, use the terms "encipher" and "decipher". It seems that some cultures find the terms "encrypt" and "decrypt" offensive, as they refer to dead bodies.)
The receiving mailserver needs to get the originating mailserver's public key somehow. It can come from a central clearinghouse server, or it can come from the existing DNS infrastructure.
DNS is a more natural place to put such information, since it's specifically designed for looking up information related to domains. However, it's vulnerable: if this domain-key thing becomes widespread, spammers will start attacking DNS servers and replacing the real public keys with their own public keys. This will allow them to send a batch of spam through the server before everyone realizes what's happened and fixes it, and during this time, legitimate users won't be able to send mail through the domain, because recipients will be checking it against the spammer's public key.
The solution to this is DNSSEC -- signatures on DNS records themselves, to prevent tampering. DNSSEC has been slow in getting adopted, mostly (it seems) for the same reason so few people encrypt their email for privacy: they don't take the risk seriously, and they don't see anyone else doing it. Maybe, hopefully, this system of authenticating email origins will motivate administrators to secure their domains using DNSSEC as well.
Sorry, I should've clarified. If you use ssh-agent (or Accession in Windows), you can "forward" the agent connection, meaning that it's still accessible from the remote end.
For example: You have a private key on machine A, which you load into the agent running there, and the connect from machine A to machine B. Nothing out of the ordinary yet. Next, you connect from machine B to machine C, and this connection authenticates by talking to the agent running on machine A. Machine B doesn't need to have any private keys on it.
I do this regularly, and it works great. As an added bonus, once a key is stored in the agent, it can be used without typing the passphrase every time; I type my SSH passphrase once when I log in, and it stays with me for the duration of my session. (Of course, as a precaution, I have a hotkey set up to flush the key from the agent if for some reason that's necessary.)
That's a good reason to use public-key authentication with SSH, rather than password authentication. That way, the attacker looking at SucKIT's logfile only sees a challenge-response exchange, which can't be replayed thanks to timestamping.
The idea isn't a stamp of approval showing that you have skills -- it's to show affiliation. Wearing clothing with a sports team's logo doesn't tell people you're a member of the team; it tells people that you like the team. Other fans of the team can see the logo and recognize your common interest.
I'd display the logo as a statement to others that I support and approve of hackish skills and principles. Doing so doesn't make any claim about my skills in particular -- I don't claim to be a hacker -- though others familiar with the logo may rightly conclude that I value such skills.
Don't think of the logo as a seal of approval that hackerdom confers upon you; think of it as a seal of approval that you confer upon hackerdom.
I imagine that because it's still (relatively) new, use of.NET isn't as widespread now as it will be in the future.
You bash.NET and C#, but have you ever actually used either of them? They're actually quite nice. I've never been a fan of Java, but.NET has the feel of "Java done right". Similarly, C# is a nice high-level language that feels natural to anyone used to C++. (It's not a replacement for C++, just as C++ isn't a replacement for C.) Admittedly, part of the pleasantness of C# probably has to do with the fact that VS.NET is an excellent IDE.
I'm interested in Mono because I run Debian 90% of the time and Windows 10%, but the distinction between Mono and the Microsoft Framework isn't really that important -- I like.NET as a whole.
Slashdot Mirror
Not quite. The difference is that a plain upgrade will hold a package back if the new version has dependencies or conflicts which your system doesn't currently satisfy, while a dist-upgrade will automatically install new dependencies and remove any conflicts (usually obsoleted stuff, though not always) in order to meet the needs of the new version of the package.
The only time I don't use dist-upgrade is on the occasions when there's an inconsistency in the dependencies of some set of packages I use. Right now, for example, mozilla has been upgraded, but galeon (which I use) hasn't been built against the new version yet, so dist-upgrading would remove galeon so that the new mozilla can be installed. But I just look at what changes apt says it will make, notice that galeon is marked for removal, and just switch to using plain upgrades for a few days until the inconsistency is resolved.
That sort of situation is pretty uncommon though, and in most cases it's better to use dist-upgrade. Otherwise you're stuck with a bunch of old packages which aren't upgraded because the new version has spun off some functionality into a separate package, or depends on a different library (libgnutls vs. libssl, for example), and the plain upgrade won't handle the change.
The only time dist-upgrade will remove a package is when it's specifically incompatible with something else. For the general task of cleaning out old packages that you don't need anymore (libraries that nothing depends on anymore, for example), use debfoster.
That's interesting -- I'm running sid too, and GNOME still works perfectly fine for me. In the same timeframe, I upgraded from 2.4.24 to 2.6.1 (using my own merge of patch-2.6.1 into kernel-source.2.6.0), started using initrd, and migrated my root filesystem from reiserfs to XFS (/home made the change a few weeks ago). No problems whatsoever.
FWIW, "unstable" doesn't actually mean "has lots of problems". Bugs come up sometimes, generally minor, but I've been running unstable on my desktop for 3.5 years and my system is still running cleanly and smoothly. I've never had to reinstall the system, and the only time I've had to do major recovery work (reinstalling lots of packages) was when I damaged my filesystem by setting the hard drive into an unsupported DMA mode, entirely my own fault.
Rather than downloading binary packages from unstable, though, you should consider downloading the source packages ("apt-get source <packagename>") and building on your own system. You have to wait for the software to compile, but the benefit is that the resulting package uses your currently-installed versions of the dependencies, rather than the current unstable versions.
Actually, that's not where the name comes from, though it's an interesting interpretation that I hadn't heard before. Recursive acronyms started (as far as I know) with GNU, though, and Linus didn't write Linux with the original intent of using it with the GNU system -- that came later, when the Hurd kernel wasn't progressing fast enough and people needed another kernel to use with GNU.
Linus's explanation
IANAL, but doesn't copyright only apply to creative works? Error codes aren't a creative work -- they're entirely arbitrary, and all that matters is that they're the same from system to system. Nobody put any blood, sweat, & tears into deciding that the value of ENOENT should be 2 and not, say, 11235.
Abiword, bah. Use LaTeX. :-P
(Your output will look nicer if you do, and that scores points at the subconscious level.)
Not too surprising, since Windows has a significant head start -- it's always been a desktop OS, whereas Unix comes from a background of servers and workstations from before the idea of a "desktop" existed.
I don't see these technologies as "recreating" Windows, though... they're just implementing things that are useful in a desktop environment, which Microsoft has also found to be useful in a desktop environment and implemented already due to the aforementioned head start.
There are some interesting new ideas here though. I don't know much in detail about most of these technologies (I'm just starting to get into actual GNOME development), but for example, GConf has two significant improvements over the Windows Registry that I know of.
First of all, GConf stores schema as well as data. This is important because it means that conceptually, each key has a documented reason for its existance; it doesn't just happen to be left over from some app that was installed a year ago and then removed because it was buggy. And keys can have documentation strings, something the Windows Registry would greatly benefit from.
Second, and probably more importantly, GConf has a notification mechanism: applications can "listen" on a key, and receive notification when that key is changed. This is why a change made in the preferences window of one instance of an app can immediately take effect in all running instances, and AFAIK the Registry can't do this.
As for Nautilus, there are some things I wish it did more like Windows Explorer, most notably Explorer's horizontally-scrolling list view (where one click of the scroll wheel brings a whole column of icons into view, instead of just one or two at the bottom), but it's built on GNOME-VFS, which is a great idea in itself. Sure, Windows Explorer is really Internet Explorer so you can enter either a local path or an HTTP or FTP URI in the address bar, but can you install a package which adds support for SFTP URIs? I don't think so. And with the aid of GStreamer's GNOME-VFS module, you can (for example) take a stream from an SFTP location, run it through some processing, and store the output stream to a WebDAV location. You could probably even write a GStreamer module as a Bonobo component, so your workstation can make use of a codec installed on a server somewhere. You get the idea.
Actually, I think NT ACLs are simpler than standard Unix file permissions, while being more powerful at the same time. Why? Because they propagate down the tree. In Unix/Linux, each and every file has its own set of permission bits, initialized generally to the same value by the umask, but still stored separately even though the vast majority of files on most systems have the standard 644 (755 for directories) permissions.
Under the NT security model, you can set a permission on a directory and it's automatically inherited by files and subdirectories. The permission isn't individually defined thousands of times over. Newly-created files inherit permissions from their containing directory; if you have different permissions on two directories, files created in those two directories will have different default permissions. In Unix terms, that's like having a different umask associated with each directory. And later, if you want to change the permission on some part of the tree, (maybe adding write permission for a specific user), you just apply the new ACL to one directory and it propagates to everything below it; no need for a bit recursive chmod command.
Of course, most of the time you don't need per-directory umasks; you just need the typical "owner read-write, everyone else read-only" permissions. And to achieve that, no permission at all needs to be defined on a file; it's inherited from the parent.
To me, that's a lot simpler.
Funny thing about those Molex connectors: when you turn them upside-down, they don't insert fully (of course), but they go far enough (by tilting downward slightly) that the pins can make contact. And since one side of the plug is 5v while the other side is 12v, connecting it upside-down means that the electronics get force-fed over twice as much current as they were meant to take.
If the lighting happens to be dim and you can't see which way the plug is oriented... yeah. I fried an 80GB Seagate Barracuda drive that way.
Thankfully, Seagate's RMA form doesn't ask how the damage occurred, (:-P), but I still lost about 60GB of data.
I got to exactly this point in the comments while waiting for TFA to load. :-)
It's been a few years since I read "Neuromancer", but I'm pretty certain there's no mass human enslavement by AIs in that book. The concept of interfacing with a virtual world by direct brain connection might have come from "Neuromancer", (I don't know whether there's precedent for that), but not much else.
I just saw RotK last night, and I didn't notice at the time, but thinking back on it, I don't think they showed the "green screen" before any of the previews. I guess they figure if it's approved for "all audiences" then there's no one in the audience who it's not OK for, so there's no need to put up a notice.
Anyway, before the previews even started, I'd seen the sign for this hanging in the lobby, and pointed it out to the friends I was with, saying something along the lines of "hey, cool, they're making an 'I, Robot' movie!" The three of us then looked at it for a moment and decided that it looked like an ad for a product, not a movie, since it just had a picture of a robot and some text (I don't remember the words) that didn't include things like actors' names. So when we went into the screenroom and saw the preview, we didn't even consider the possibility that it might be a movie trailer.
Nobody seems to have pointed this out yet, so I will.
Imagine for a moment that you're a phone-support tech working at, say, Dell or some other consumer PC manufacturer. You get a call from a customer who says they can't "get on the Internet".
You ask this customer, "What Internet service are you using?" and the customer responds "Netscape".
Until now, anyone hearing such a response could immediately recognize that the user was talking about their browser, not their ISP (which is what the question referred to). Now, that conclusion can't be made.
With the introduction of this service, someone who is "using Netscape" is either:
Needless to say, this makes it difficult to ascertain which is the case when talking to a user who doesn't know the difference.
Reminds me of the newspapers and shopping-mall advertising seen in Minority Report...
Actually, nowhere does it say that root privilege was used at all -- the attack was against a PHP interpreter embedded in an Apache binary running as www-data, and it started a new process which also ran as www-data. The article summary is a bit misleading.
Must've been. Look at the terminology for processes: parents have to wait for their children to die and then reap them, so they don't become zombies.
It's actually "daemon", not "demon", but that reminds me of a funny story. You know how when an email bounces, the returned message often comes from "mailer-daemon" at whatever domain your message was addressed to? Back when I was in high school, I once heard a teacher who was checking his mail exclaim, "mailer demon???", clearly thinking (at least until he read the text of the bounce message) that some sort of devilish creature was interfering with the delivery of his email.
Clearly, crypt() was meant to die: just look at its name!
As Schneier says on the first page of Chapter 1 of "Applied Cryptography",
The receiving mailserver needs to get the originating mailserver's public key somehow. It can come from a central clearinghouse server, or it can come from the existing DNS infrastructure.
DNS is a more natural place to put such information, since it's specifically designed for looking up information related to domains. However, it's vulnerable: if this domain-key thing becomes widespread, spammers will start attacking DNS servers and replacing the real public keys with their own public keys. This will allow them to send a batch of spam through the server before everyone realizes what's happened and fixes it, and during this time, legitimate users won't be able to send mail through the domain, because recipients will be checking it against the spammer's public key.
The solution to this is DNSSEC -- signatures on DNS records themselves, to prevent tampering. DNSSEC has been slow in getting adopted, mostly (it seems) for the same reason so few people encrypt their email for privacy: they don't take the risk seriously, and they don't see anyone else doing it. Maybe, hopefully, this system of authenticating email origins will motivate administrators to secure their domains using DNSSEC as well.
Sorry, I should've clarified. If you use ssh-agent (or Accession in Windows), you can "forward" the agent connection, meaning that it's still accessible from the remote end.
For example: You have a private key on machine A, which you load into the agent running there, and the connect from machine A to machine B. Nothing out of the ordinary yet. Next, you connect from machine B to machine C, and this connection authenticates by talking to the agent running on machine A. Machine B doesn't need to have any private keys on it.
I do this regularly, and it works great. As an added bonus, once a key is stored in the agent, it can be used without typing the passphrase every time; I type my SSH passphrase once when I log in, and it stays with me for the duration of my session. (Of course, as a precaution, I have a hotkey set up to flush the key from the agent if for some reason that's necessary.)
That's a good reason to use public-key authentication with SSH, rather than password authentication. That way, the attacker looking at SucKIT's logfile only sees a challenge-response exchange, which can't be replayed thanks to timestamping.
The idea isn't a stamp of approval showing that you have skills -- it's to show affiliation. Wearing clothing with a sports team's logo doesn't tell people you're a member of the team; it tells people that you like the team. Other fans of the team can see the logo and recognize your common interest.
I'd display the logo as a statement to others that I support and approve of hackish skills and principles. Doing so doesn't make any claim about my skills in particular -- I don't claim to be a hacker -- though others familiar with the logo may rightly conclude that I value such skills.
Don't think of the logo as a seal of approval that hackerdom confers upon you; think of it as a seal of approval that you confer upon hackerdom.
Actually, it just uses AA-lib to draw the "pixels", rather than a conventional framebuffer. More info (and screenshots) here.
Three troll replies and one intelligent one. Good thinking. :-)
I imagine that because it's still (relatively) new, use of .NET isn't as widespread now as it will be in the future.
You bash .NET and C#, but have you ever actually used either of them? They're actually quite nice. I've never been a fan of Java, but .NET has the feel of "Java done right". Similarly, C# is a nice high-level language that feels natural to anyone used to C++. (It's not a replacement for C++, just as C++ isn't a replacement for C.) Admittedly, part of the pleasantness of C# probably has to do with the fact that VS.NET is an excellent IDE.
I'm interested in Mono because I run Debian 90% of the time and Windows 10%, but the distinction between Mono and the Microsoft Framework isn't really that important -- I like .NET as a whole.
After reading the rest of the thread and noticing the preponderance of "BSD is dying" trolls, I'd like to amend my comment. :-)
5. Offense at "BSD is dying" trolls
However, I'm inclined to ignore those in the same way that I ignore the GNAA first posts and "In Soviet Russia" jokes.