Then came Symantec, and so far I'm not impressed with anything they've done. Have they done anything? Other than buy other companys' products and rebrand them?
Yeah, I'm mad, that's what they tell me. Actually, I'm just drunk right now (It is St. Patty's Day and all;). Anyway, RPM has the concept of dependencies, too, if you haven't noticed! And who the hell knows how well the shit packages other people put together are tested, either? At least they're self contained within the package and can be backed out easily. Tell me you can do that with ports... please, I'm begging you!
Good point, but this really doesn't address management of all the little bits of software you may or may not want to have on different machines. What would be nice, ideally, is something like RPM. I'd like to have an inventory of everything associated with a particular software package, as well as an easy way to upgrade it, remove it, verify that it hasn't been modified, etc. For one system, ports are fine. For a few, identically configured servers, site.tgz might work. But if you've got lots of boxes doing different things, there should be a better way of keeping track of things.
That said, *BSD is otherwise well put together, for the most part. Bugs are well documented and addressed quickly. My first foray into kernel hacking was on FreeBSD, and the source code was very approachable, for someone just starting out with such things. I guess this could be attributed to the straightforward, succinct way in which most of the code is written.
Oops... Err... Microsoft Galaxy, that is. To this, the book version adds, "Every planet will take on the corporate identity of whoever rapes it first."
"When deep space exploration ramps up, it will be the corporations that name everything: the IBM Stellar Sphere, the Microsoft Gallery, the planet Starbucks."
I'm not a wireless engineer, but I took a class on this stuff in college. This is how I understand it... I think they're concerned that using cell phones at altitude will cause interference with the cell system, which is why they tell people it can mess up the plane's instruments. Since radio waves are line of sight, your phone can potentially reach multiple cells on the same frequency. Remember that the distiction between cells in most systems is at least partially FDMA (Frequency Division Multiple Access), and the cells on the same frequencies are non-adjoining so they don't interfere. The system most likely is still able to discern which tower to use from signal strength, and since FM is so selective, the weak signals from the air are probably not that big of a deal for other users on the ground. Telling people they'll crash the plane as opposed to just causing some interference to a few cell towers is a more effective way of convining people to comply, though.;)
Plumbing? Other infrastructure? Who needs it? When I moved into my new apartment, I didn't even have the gas turned on, but you can bet your ass I had my high-speed Internet access!!
I don't think Samba should live long as you say (although it probably will). As a protocol, SMB was horribly designed from the outset, and the only reason for Samba therefore is interoperability with M$ systems. I think everyone, Samba team included, would probably hope that SMB would go away and that we'll no longer need to use Samba. Come on, even M$ could come up with something better than the current SMB design.
Speaking of having office applications for Linux on other architectures, I'm surprised that now that Sun owns StarOffice, they haven't bothered releasing binaries for SPARC Linux. Definitely, opening up the source for StarOffice (and others) would make this possible not only on the SPARC/UltraSPARC, but other CPU architectures as well. I haven't tried out KOffice yet, so maybe that's a good route to go for those of us with non-Intel machines. As an alternative, maybe I'll see if I can get the StarOffice Solaris SPARC version going under Solaris emulation today.
Slashdot Mirror
#include "scifi_geek.h"
extern void * eccleston;
int dr_who () {
return 0;
}
The Moon is a fascinating place, but it gets progressively less interesting as your oxygen runs out.
;)
I beg to differ... I would think things would become far _more_ interesting. Comfortable is a different thing altogether, though.
Then came Symantec, and so far I'm not impressed with anything they've done. Have they done anything? Other than buy other companys' products and rebrand them?
;)
Well, there is ESM, er- Oh wait...
Mediocre seems to be their watchword.
I think you're being too kind.
Why the hell was this ever modded up, anyway?
Slashdot requires you to wait 20 seconds between hitting 'reply' and submitting a comment.
It's been 17 seconds since you hit 'reply'!
OK, I'll take a wiz and try again...
Yeah, they figured this out on other OS's (open source and otherwise) a couple of years ago.
Yeah, I'm mad, that's what they tell me. Actually, I'm just drunk right now (It is St. Patty's Day and all ;). Anyway, RPM has the concept of dependencies, too, if you haven't noticed! And who the hell knows how well the shit packages other people put together are tested, either? At least they're self contained within the package and can be backed out easily. Tell me you can do that with ports... please, I'm begging you!
Good point, but this really doesn't address management of all the little bits of software you may or may not want to have on different machines. What would be nice, ideally, is something like RPM. I'd like to have an inventory of everything associated with a particular software package, as well as an easy way to upgrade it, remove it, verify that it hasn't been modified, etc. For one system, ports are fine. For a few, identically configured servers, site.tgz might work. But if you've got lots of boxes doing different things, there should be a better way of keeping track of things.
That said, *BSD is otherwise well put together, for the most part. Bugs are well documented and addressed quickly. My first foray into kernel hacking was on FreeBSD, and the source code was very approachable, for someone just starting out with such things. I guess this could be attributed to the straightforward, succinct way in which most of the code is written.
Oops... Err... Microsoft Galaxy, that is. To this, the book version adds, "Every planet will take on the corporate identity of whoever rapes it first."
"When deep space exploration ramps up, it will be the corporations that name everything: the IBM Stellar Sphere, the Microsoft Gallery, the planet Starbucks."
I'm not a wireless engineer, but I took a class on this stuff in college. This is how I understand it... I think they're concerned that using cell phones at altitude will cause interference with the cell system, which is why they tell people it can mess up the plane's instruments. Since radio waves are line of sight, your phone can potentially reach multiple cells on the same frequency. Remember that the distiction between cells in most systems is at least partially FDMA (Frequency Division Multiple Access), and the cells on the same frequencies are non-adjoining so they don't interfere. The system most likely is still able to discern which tower to use from signal strength, and since FM is so selective, the weak signals from the air are probably not that big of a deal for other users on the ground. Telling people they'll crash the plane as opposed to just causing some interference to a few cell towers is a more effective way of convining people to comply, though. ;)
Aren't the chipsets for Sun's serial ports made by Zilog? If so, I wonder how this will affect Sun.
Plumbing? Other infrastructure? Who needs it? When I moved into my new apartment, I didn't even have the gas turned on, but you can bet your ass I had my high-speed Internet access!!
I don't think Samba should live long as you say (although it probably will). As a protocol, SMB was horribly designed from the outset, and the only reason for Samba therefore is interoperability with M$ systems. I think everyone, Samba team included, would probably hope that SMB would go away and that we'll no longer need to use Samba. Come on, even M$ could come up with something better than the current SMB design.
Speaking of having office applications for Linux on other architectures, I'm surprised that now that Sun owns StarOffice, they haven't bothered releasing binaries for SPARC Linux. Definitely, opening up the source for StarOffice (and others) would make this possible not only on the SPARC/UltraSPARC, but other CPU architectures as well. I haven't tried out KOffice yet, so maybe that's a good route to go for those of us with non-Intel machines. As an alternative, maybe I'll see if I can get the StarOffice Solaris SPARC version going under Solaris emulation today.
I really hope the Chinese embarass US politicians into ramping up funding for the space program.
http://realaroma.com/
Ahh, the smell of feet. Kinda reminds me of my college dorm...
http://www.beakman.com/feet/feet-smell.html