You see, maybe that's my problem. I don't get interesting spam like that. The only ones I get are herbal viagra, and occasionally some boring ones about loans (no prefilled checks, though). "Space Bags?" That's brilliant. What I wouldn't give to be able to read about Space Bags! Taplights sound promising, too.
Maybe if somebody offered an option to get more interesting spam I'd be more excited.:P
Or, if you've thought things through, you'll be using something like Encap or GNU Stow, in which case you will be installing into one directory.
Seriously, try it out. It's absolutely wonderful. By far the best way I've found to keep your system from accumulating too much cruft (well, it won't stop the accumulation, but it will make it trivially easy to get rid of later). I've only used Encap, but it's way way cool. When you compile a program, use "--prefix=/usr/local/encap/program-1.0" with the configure script, and then you'll have/usr/local/encap/program-1.0/bin,/usr/local/encap/program-1.0/share, etc . . . Then you run "epkg -i program" and it'll install all the symlinks correctly into/usr/local the way you'd expect. Then you can remove packages, upgrade, etc, etc, etc. Very fun.
Yeah, I knew how to disable Compression, just wanted to know if I still had to before upgrading . . . I suppose I could have just tried it out myself, but why waste my time when I can waste my time AND someone else's at once?:P
As to the typing, if that's a serious question, I tend to type pretty quickly. Couldn't give you a WPM, though. Why the query?
The 3.3 release of OpenSSH required that with PrivilegeSeparation turned on, Compression had to be turned off for Linux kernels in the 2.2 line. Does anyone know if this is true for the 3.4 release as well, or has that been fixed?
Re:Nothing untrue in the article at all. /. howeve
on
Is Linux Dead?
·
· Score: 2
Well, of course articles posted here are going to be biased against MS. Any article posted on a Microsoft-heavy site is going to be biased against Linux. I agree that this particular story is biased very wrongly against MS, as the article it linked to was, in fact, quite complimentary to Linux, but that's beside the point. By posting a list of articles that could have been posted instead of this one, you're implying that they would have been better choices. I maintain that it's likely a good thing that the ones in your list got rejected. (But I'm probably just being overly grouchy now.)
Whatever.:) As to the Sakharov thing, my point there was that just submitting a title with someone's name isn't a good title at all. What's the story about? Why should I read it? They probably wouldn't let a story through with just the title "Linus Torvalds," either. Gotta give out more info in the title. Also, I'm not sure if you're aware of it, but Enlightenment is a Window Manager for X, hence the topic . . .
Re:Nothing untrue in the article at all. /. howeve
on
Is Linux Dead?
·
· Score: 2
Groovy, thanks. Sounds interesting, I should do some reading.:P
Re:Nothing untrue in the article at all. /. howeve
on
Is Linux Dead?
·
· Score: 2
Um, to be fair, your wonderful headlines aren't any better than "Is Linux Dead?"
Andrei Dmitriyevich Sakharov - Who? What are you reporting here?
Slashdot censorship - Right, like that'll get posted. Probably just more whining about supposed moderation unfairness. Whatever.
Is fetus a child? - Grammatically incorrect and not exactly the kind of topic for Slashdot. If you want an abortion debate, go elsewhere.
Just paid for a 2 months Kuro5hin subscription - So? Do I care? I'm very happy for you.
Forgive me for not feeling sorry that those got rejected.
When the story was first posted, the link looked like <a href="blahblah.com">, as opposed to <a href="http://blahblah.com">. When you clicked on the original version, you then went to http://slashdot.org/blahblah.com, instead of http://blahblah.com like you wanted to. The story has since been fixed.
Hey, those are actually pretty cool. I got one as a present and laughed at it for a bit, but as it turns out, we use it all the time. Seriously, we end up cooking practically everything on it. It's awesome.:P
I mentioned this elsewhere in the thread. I found a cool little program called Twonz that looks like it could be the start of a good solution for that. You just remember one "password", and then type in the name of the box, or the IP, or something else unique to the one box, and it'll "combine" the two to give you a fresh password. I haven't done more investigation than looking at that homepage, but there's only a few issues with it, as far as I can see:
I'd like the app itself to be password-protected, although that's not terribly necessary
I'd like to make sure that the transformation to get the final password is, indeed, a one-way transform. That way, given one password and the name of the box, you can't reverse engineer the "master" password.
It'd be nice to choose between a list of algorithms used to generate the master password, and to be able to tweak the algorithms for your own personal use.
Anyway, it seems really good, because even if someone DOES get ahold of the program, they still won't be able to find out passwords to your systems without knowing that "master" password. So you remember that one password, and you can generate passwords for all your machines.
Right, it certainly is a problem. As I mentioned in another post in this thread, I think the ideal solution would be to have some way to generate passwords based on the host name (or IP, or whatever) of the boxes you've gotta keep track of, in a non-obvious and somewhat secure way. Like, you'd have an application, password-protected itself, of course, that would have you input the name of the box. It'd then churn through a bunch of algorithms and transforms and eventually come out with a password for the box. The algorithm would obviously have to be tweakable, so you could change passwords in a uniform fashion, and the security on the program itself is paramount (you don't want just anyone getting access to the program you're using, or the algorithms used).
I found a project called Twonz that does something like that. You input a "base" password, and then the name of the host, or IP, or whatever, and it computes what the actual password would be. It looks a bit incomplete for a scalable solution; as I mentioned, I'd like to have the app itself be password protected, and have the ability to mess around with the generation algorithm, but the basic bit is there . . .
Instead, each class of server has it's own username/password structure
Okay, but that's a bit different from saying "Use the same root password for each machine." Making the password some function of the box name for a farm with 30+ machines would probably be okay if it's done right, but if it's something as simple as "blahblah-machinename," someone who's cracked their way to the root password of one machine might be able to figure it out and get in everywhere . . .
If you're willing to carry PDAs around with you, it'd be pretty cool to have a program (itself passwd-protected, of course - you'll have to remember that one) that, given the name of the box, would hash the name somehow to come up with a unique password on a per-box basis. Just type in the box name and you've got the password. Obviously if anyone who wasn't supposed to could get into that program, you'd have Issues . . . I think I've seen some things on Sourceforge that do basically that.
It's not a question of whether or not the passwords are being sent in cleartext. There have been holesfound in SSH before, and there probably will be again. Plus, there's an excellent chance that SSH isn't the ONLY thing listening on these boxes. A hole in ANY service running can be enough for someone to get in. And once someone's in, it's much easier to grab root access, because it's easier to keep tabs on what's listening on ports than all the thousands of binaries that aren't. Once you've got root on a box, it's a simple matter of installing some trojaned binaries to grab passwords for you. It doesn't matter if the password's been sent in plaintext or not.
And things can get very quickly complicated, because again, once a malicious person has gained access to ONE of your systems, suddenly it's completely trivial to get into all the rest. If you enforce different passwords on each box, then you're containing the fire. The blackhat will still have 0wNz0r3d one of your boxes, but it's contained there, and he's got to go through the same amount of work to get into any of the others, which increases the probability of someone noticing illicit behaviour, increases the probability that this person will screw up and make a mistake, and increase the probability that he might not be able to get in at all.
As to writing passwords down, obviously that's a problem. If people are going to be writing passwords down somewhere, you've got to have a good deal of actual, physical security if you want to be able to feel safe about it. It helps to have passwords related somehow. Pick a paragraph from a book; the first letter of each word in sentence 1 makes up the password for box 1, the second sentence goes for box 2 . . . There's many ways to relate passwords such that it's easier to remember.
Remember, you're not just defending against a brute-force cracker or someone sniffing plaintext passwords. There's much more to it than that.
Having the same password on multiple machines is bad. Very bad. Especially when it's a root password. Someone compromises one box, suddenly they've compromised all of them. Not good.
Re:Two Things I don't like about Portage...
on
Gentoo Linux 1.2
·
· Score: 2
If you "emerge gentoolkit" it'll give you a utility "qpkg" which will at least give you a list of all installed packages. It probably does other things, too, but I haven't played around with it much. I think that should probably be part of the default install, but whatever . . .
I'm too spoiled by Google, I think. I took one glance at the search results screen that had a few banner ads, and decided never to go there again. I understand they want to offset costs/make money off of the engine, but banner ads are ugly as sin. I'll stick with Google.
My one gripe
on
Is RPM Doomed?
·
· Score: 3, Interesting
The one thing that I really don't like about any package manager is rigid dependency checking. It only really occurs when you try to act outside of the "accepted" package system. For instance, back in my Redhat and then Debian days, I was content to let the base system get installed by RPM or apt. I also loved, especially in Debian, the ability to use apt to just install an app I wanted to use. However, for a long time, I used the DRI XFree86 that came from CVS and got compiled by hand. So I was stuck with two options - either don't install the X packages, or install them anyway but install X by hand on top of it. In the first case, it was really difficult to install any package that relied on X. On RPM, I had to turn off dependency checking to do it (which meant that the primary purpose of the package management system was bypassed, IMO), and with apt, it was nigh-impossible (I never did figure out how to get apt to install something despite dependency issues). On the second case, whenever the package management system decided to upgrade my X, then my hand-installed stuff would get overwritten.
What I'd love to have in a package manager is a more intelligent dependency check. Like, instead of just saying "I need this version of X," it would also just check for the existance of/usr/X11R6. Or if a package requires BerkelyDB, after checking "inside" the package manager, just try and see if there's a libdb.so somewhere in the LD search path. And then mark down "inside" the package management system that the "BerkelyDB" or "XFree86" dependency seemed to be fulfilled by a manual installation.
Speaking from experience, the way Zope ties into the relational databases is anything but "oh yeah, that too." It's kind of difficult to explain how the two can work together. First off, the ZopeDB really isn't OO in the way that you're thinking it is. There's many similarities, but if you try to make it work exactly like the OO model in your head, you'll probably end up banging against some walls. When you go to http://host/foo/bar/baz, "foo" "bar" and "baz" are all objects in the ZopeDB, and they aren't necessarily "heirarchical" in the way you might think. Ie, the "directory" structure could look like this:
foo
baz
bar
So when Zope's rendering "baz", it'll look at baz's "acquisition path," which will look at "bar" and "foo," and depending on what those objects do, the behavior of "baz" can be radically altered. Like "baz" could be some kind of administrative plugin object, and if you simply add "baz" into the acquisition path, and instead of getting the data-entry screen, it'll launch you into an administrative version of the screen that's still being sourced from the same place, and does extra authentication and stuff.
It's really beyond the scope of a Slashdot post to fully go into, however.:) The OO stuff is just really wicked-cool to code in.
As for the speed thing, it is really difficult to compare just because of all that Zope's doing. For every web request you make into Zope, it'll be doing authentication, persisting changes in the Zodb, doing some version control stuff, talking to the relational database, adding up all the acquisition paths and so forth . . . It's doing a *lot,* and it makes it difficult to compare to other packages because when you get to that level of complexity it becomes harder to say which is "better." Like, something might be running faster, but you don't get all the cool benefits of Zope's object acquisition, or possibly the really fine-grained level of security and permissions that Zope has built in . . . And are the replacements in the competing package "better" or "worse?" It's really hard to say. There are things you can do in Zope, programming-wise, that would be nigh-impossible in other systems, just as there are probably things in other systems that would be nigh-impossible in Zope. So it's difficult to tell.
Zope actually makes dealing with plain ol' relational databases REALLY easy. The primary database is, yes, OO, but I've built quite a few applications in Zope that deal primarily with a relational database. The OO stuff is really great for programming the actual application, and then the data can get stored away in the relational database. Really cool funky application stuff.
I do agree about documentation, however. I'm a total Zope freak; I think it's by far the best application server environment out there, but the documentation has always managed to be really boggling. There's this really bizarre learning curve involved, and for some reason they've never seemed able to get past it. Once you understand Zope, it's great, but if you don't it can be pretty hellish. At least the mailing lists are generally good sources of info if you make some effort to sound like you know *sort* of what you're doing.:)
As to benchmarks and stuff, I know that there were some tests done some time ago with Zope vs. Tomcat vs. something else, but I've long since lost the links. Search the mailing list archives, should be in there. (Of course, as the advocate, I should really be the one supplying the links, eh?)
I'm guessing not. Unless I happened to be in the area at the time. And it was free. And there wasn't anything better to be doing at the time, like stare at my toes.
Honestly, I enjoy Slashdot: The Website quite a bit. I also find the idea of Slashdot: The Convention to be utterly terrifying.
Slashdot Mirror
Is there a syntax file for IRC logs for vim? Just curious . . .
Maybe if somebody offered an option to get more interesting spam I'd be more excited. :P
How about they just not send me unsolicited advertisements at all?
Seriously, try it out. It's absolutely wonderful. By far the best way I've found to keep your system from accumulating too much cruft (well, it won't stop the accumulation, but it will make it trivially easy to get rid of later). I've only used Encap, but it's way way cool. When you compile a program, use "--prefix=/usr/local/encap/program-1.0" with the configure script, and then you'll have /usr/local/encap/program-1.0/bin, /usr/local/encap/program-1.0/share, etc . . . Then you run "epkg -i program" and it'll install all the symlinks correctly into /usr/local the way you'd expect. Then you can remove packages, upgrade, etc, etc, etc. Very fun.
(Sorry 'bout the language, if you're offended. If you've wasted as much of your life on SC2 as I have, you'll understand.)
DAMN, but that's cool.
Aaaaaah, no, I've got it now. :) Not terribly funny, but not bad, either. :)
As to the typing, if that's a serious question, I tend to type pretty quickly. Couldn't give you a WPM, though. Why the query?
The 3.3 release of OpenSSH required that with PrivilegeSeparation turned on, Compression had to be turned off for Linux kernels in the 2.2 line. Does anyone know if this is true for the 3.4 release as well, or has that been fixed?
Whatever. :) As to the Sakharov thing, my point there was that just submitting a title with someone's name isn't a good title at all. What's the story about? Why should I read it? They probably wouldn't let a story through with just the title "Linus Torvalds," either. Gotta give out more info in the title. Also, I'm not sure if you're aware of it, but Enlightenment is a Window Manager for X, hence the topic . . .
Groovy, thanks. Sounds interesting, I should do some reading. :P
- Andrei Dmitriyevich Sakharov - Who? What are you reporting here?
- Slashdot censorship - Right, like that'll get posted. Probably just more whining about supposed moderation unfairness. Whatever.
- Is fetus a child? - Grammatically incorrect and not exactly the kind of topic for Slashdot. If you want an abortion debate, go elsewhere.
- Just paid for a 2 months Kuro5hin subscription - So? Do I care? I'm very happy for you.
Forgive me for not feeling sorry that those got rejected.When the story was first posted, the link looked like <a href="blahblah.com">, as opposed to <a href="http://blahblah.com">. When you clicked on the original version, you then went to http://slashdot.org/blahblah.com, instead of http://blahblah.com like you wanted to. The story has since been fixed.
Yeah, yeah, I know, (-1, Offtopic) :)
- I'd like the app itself to be password-protected, although that's not terribly necessary
- I'd like to make sure that the transformation to get the final password is, indeed, a one-way transform. That way, given one password and the name of the box, you can't reverse engineer the "master" password.
- It'd be nice to choose between a list of algorithms used to generate the master password, and to be able to tweak the algorithms for your own personal use.
Anyway, it seems really good, because even if someone DOES get ahold of the program, they still won't be able to find out passwords to your systems without knowing that "master" password. So you remember that one password, and you can generate passwords for all your machines.I found a project called Twonz that does something like that. You input a "base" password, and then the name of the host, or IP, or whatever, and it computes what the actual password would be. It looks a bit incomplete for a scalable solution; as I mentioned, I'd like to have the app itself be password protected, and have the ability to mess around with the generation algorithm, but the basic bit is there . . .
Just an idea, anyway. :)
If you're willing to carry PDAs around with you, it'd be pretty cool to have a program (itself passwd-protected, of course - you'll have to remember that one) that, given the name of the box, would hash the name somehow to come up with a unique password on a per-box basis. Just type in the box name and you've got the password. Obviously if anyone who wasn't supposed to could get into that program, you'd have Issues . . . I think I've seen some things on Sourceforge that do basically that.
And things can get very quickly complicated, because again, once a malicious person has gained access to ONE of your systems, suddenly it's completely trivial to get into all the rest. If you enforce different passwords on each box, then you're containing the fire. The blackhat will still have 0wNz0r3d one of your boxes, but it's contained there, and he's got to go through the same amount of work to get into any of the others, which increases the probability of someone noticing illicit behaviour, increases the probability that this person will screw up and make a mistake, and increase the probability that he might not be able to get in at all.
As to writing passwords down, obviously that's a problem. If people are going to be writing passwords down somewhere, you've got to have a good deal of actual, physical security if you want to be able to feel safe about it. It helps to have passwords related somehow. Pick a paragraph from a book; the first letter of each word in sentence 1 makes up the password for box 1, the second sentence goes for box 2 . . . There's many ways to relate passwords such that it's easier to remember.
Remember, you're not just defending against a brute-force cracker or someone sniffing plaintext passwords. There's much more to it than that.
Having the same password on multiple machines is bad. Very bad. Especially when it's a root password. Someone compromises one box, suddenly they've compromised all of them. Not good.
If you "emerge gentoolkit" it'll give you a utility "qpkg" which will at least give you a list of all installed packages. It probably does other things, too, but I haven't played around with it much. I think that should probably be part of the default install, but whatever . . .
I'm too spoiled by Google, I think. I took one glance at the search results screen that had a few banner ads, and decided never to go there again. I understand they want to offset costs/make money off of the engine, but banner ads are ugly as sin. I'll stick with Google.
What I'd love to have in a package manager is a more intelligent dependency check. Like, instead of just saying "I need this version of X," it would also just check for the existance of /usr/X11R6. Or if a package requires BerkelyDB, after checking "inside" the package manager, just try and see if there's a libdb.so somewhere in the LD search path. And then mark down "inside" the package management system that the "BerkelyDB" or "XFree86" dependency seemed to be fulfilled by a manual installation.
That would be the ideal system for me.
Speaking from experience, the way Zope ties into the relational databases is anything but "oh yeah, that too." It's kind of difficult to explain how the two can work together. First off, the ZopeDB really isn't OO in the way that you're thinking it is. There's many similarities, but if you try to make it work exactly like the OO model in your head, you'll probably end up banging against some walls. When you go to http://host/foo/bar/baz, "foo" "bar" and "baz" are all objects in the ZopeDB, and they aren't necessarily "heirarchical" in the way you might think. Ie, the "directory" structure could look like this:
- foo
- baz
- bar
So when Zope's rendering "baz", it'll look at baz's "acquisition path," which will look at "bar" and "foo," and depending on what those objects do, the behavior of "baz" can be radically altered. Like "baz" could be some kind of administrative plugin object, and if you simply add "baz" into the acquisition path, and instead of getting the data-entry screen, it'll launch you into an administrative version of the screen that's still being sourced from the same place, and does extra authentication and stuff.It's really beyond the scope of a Slashdot post to fully go into, however. :) The OO stuff is just really wicked-cool to code in.
As for the speed thing, it is really difficult to compare just because of all that Zope's doing. For every web request you make into Zope, it'll be doing authentication, persisting changes in the Zodb, doing some version control stuff, talking to the relational database, adding up all the acquisition paths and so forth . . . It's doing a *lot,* and it makes it difficult to compare to other packages because when you get to that level of complexity it becomes harder to say which is "better." Like, something might be running faster, but you don't get all the cool benefits of Zope's object acquisition, or possibly the really fine-grained level of security and permissions that Zope has built in . . . And are the replacements in the competing package "better" or "worse?" It's really hard to say. There are things you can do in Zope, programming-wise, that would be nigh-impossible in other systems, just as there are probably things in other systems that would be nigh-impossible in Zope. So it's difficult to tell.
But I'm rambling now. :)
I do agree about documentation, however. I'm a total Zope freak; I think it's by far the best application server environment out there, but the documentation has always managed to be really boggling. There's this really bizarre learning curve involved, and for some reason they've never seemed able to get past it. Once you understand Zope, it's great, but if you don't it can be pretty hellish. At least the mailing lists are generally good sources of info if you make some effort to sound like you know *sort* of what you're doing. :)
As to benchmarks and stuff, I know that there were some tests done some time ago with Zope vs. Tomcat vs. something else, but I've long since lost the links. Search the mailing list archives, should be in there. (Of course, as the advocate, I should really be the one supplying the links, eh?)
Honestly, I enjoy Slashdot: The Website quite a bit. I also find the idea of Slashdot: The Convention to be utterly terrifying.