People are just used to working on the client locally and connecting to a remote server. This is using a local server and a remote client. No big problem, unless you don't fully understand client/server relationships
Unless some of my very basic assumptions are wrong, this sort of cements the "active water cycle", doesn't it? I'm fairly certain that the Martian atmosphere won't tolerate something like methane snow, so what's left?
>The data loss and corruption that the parent is talking about is the fault of crap hardware. In almost every case, USB is involved
Ah, this must be the arrogance that the grandparent mentioned.
>USB and Firewire bridges are notorious for this. If you care about your data, you should run the other way if you happen upon one.
If I have to use a USB disk, I should expect to lose my data? What world do you live in?
Just call it an 'enterprise only' filesystem and people wouldn't get so riled about it. It's when it's compared to sliced bread that I get sick of hearing about it.
"On a redundant controller SAN with battery backups attached to independent power sources addressed by a fully redundant server with ECC memory, ZFS is a good filesystem". That's all you have to say.
You know, you don't/have/ to read it. It's not front page news.
Chances are if you do read it, it'll be because you received a link from someone else who thought a particular entry was interesting. Unless you subscribe, you'll never encounter it.
I mean, unless you click the link in my profile, but hey, my blog is geared toward a profession, not my cat barfing, as someone earlier alluded to.
Interestingly, I've found that the same thing that saves you plagues me.
If I'm trying to find support on a problem with a recent release of software that's been around longer than a year or two, I get results going back a very long time.
When you combine that tendency with a project that changes a lot, you've got to get very good with google to get pertinent information.
Try a generic search for redhat and pam and on the first page you get results from 9 years ago. It gets hairy.
I have found that sometimes appending the current year to a google search has helped me find relevant information.
I just can't agree with this. There's a difference between writing the passwords down on a sticky note under the keyboard and documenting the current (and previous, possibly) passwords in a well protected place.
I document the system passwords in Password Safe, and have been very happy with it.
The PAE kernel works fine in high-memory environments. Still, there's no real reason to not run 64bit software at this point if you've got the hardware.
Add in the lack of 64 bit support, and you have the reason that my entire infrastructure isn't based on Slack still.
I still subscribe to the CD sets, but I just do it to support Patrick. I don't actually use them, I just line them up and remember fondly the days of installing (and installing (and installing)) Slack onto my first machine, a 486DX2/66 with dual speed CD-ROM. Incidentally, I credit that CD-ROM with being the reason that I learned linux so well. I watched the install crawl by so many times that I pretty much memorized the packages and what they did.
Assuming you have a VPN client (or are using an SSL VPN which is "Clientless" (big lie)) then only that computer's traffic is sent over the VPN.
If, on the other hand, you have a VPN device that you plug in in front of (or behind) your broadband router, all of your connection's traffic will be going to the VPN. That's just as (if not more) insecure as a partial tunnel.
Actually, it shouldn't slow down the internal stuff at all, since it was going over the same link as before. His internet browsing will go a lot slower, but he can disconnect from the VPN for personal browsing.
Slashdot Mirror
At the very least, it would diverge far enough from Solaris to be an almost entirely different product.
OpenSolaris....OpenBSD...
Maybe the next version could be called NetSolaris. We could install it on very large toasters.
It manages flow of traffic, recognizing when one packet belongs with the others. This sounds wonderful, at least for people trying to inject packets.
I hope these things recognize the evil bit.
>The server runs on the machine you are sitting in front of
> the server runs on the client machine
I'm pretty sure you guys are saying the same thing...
People are just used to working on the client locally and connecting to a remote server. This is using a local server and a remote client. No big problem, unless you don't fully understand client/server relationships
Excellent. Something else for my old coworker to screw up when he tries to rsync / to another machine.
This time it should make for excellent visual fireworks as opposed to just going crazy like last time.
Unless some of my very basic assumptions are wrong, this sort of cements the "active water cycle", doesn't it? I'm fairly certain that the Martian atmosphere won't tolerate something like methane snow, so what's left?
Maybe you haven't been paying attention to the stuff put out by Square Enix lately...
If wishes were horses, we'd all be eating steak.
>The data loss and corruption that the parent is talking about is the fault of crap hardware. In almost every case, USB is involved
Ah, this must be the arrogance that the grandparent mentioned.
>USB and Firewire bridges are notorious for this. If you care about your data, you should run the other way if you happen upon one.
If I have to use a USB disk, I should expect to lose my data? What world do you live in?
Just call it an 'enterprise only' filesystem and people wouldn't get so riled about it. It's when it's compared to sliced bread that I get sick of hearing about it.
"On a redundant controller SAN with battery backups attached to independent power sources addressed by a fully redundant server with ECC memory, ZFS is a good filesystem". That's all you have to say.
Much in the same way that a bihedral die is a coin.
A unihedral die would be a ball.
You could argue that the lottery is a limited random sampling of a pool of 64 unihedral dice.
You know, you don't /have/ to read it. It's not front page news.
Chances are if you do read it, it'll be because you received a link from someone else who thought a particular entry was interesting. Unless you subscribe, you'll never encounter it.
I mean, unless you click the link in my profile, but hey, my blog is geared toward a profession, not my cat barfing, as someone earlier alluded to.
(that's why I have twitter)
Interestingly, I've found that the same thing that saves you plagues me.
If I'm trying to find support on a problem with a recent release of software that's been around longer than a year or two, I get results going back a very long time.
When you combine that tendency with a project that changes a lot, you've got to get very good with google to get pertinent information.
Try a generic search for redhat and pam and on the first page you get results from 9 years ago. It gets hairy.
I have found that sometimes appending the current year to a google search has helped me find relevant information.
I love it when moderation is actually funnier than the comments.
In case it changes, right now it reads
"Cockroaches survive nuclear explosions" = +5 Funny
- "and lawyers" = -1 Redundant
If you're talking about password documentation, I *heart* Password Safe. It's worked well for me so far.
That depends a great deal on what you mean by "builders".
I personally love building complex networks.
I just can't agree with this. There's a difference between writing the passwords down on a sticky note under the keyboard and documenting the current (and previous, possibly) passwords in a well protected place.
I document the system passwords in Password Safe, and have been very happy with it.
Snape kills Trinity with Rosebud?
http://xkcd.com/109/
The PAE kernel works fine in high-memory environments. Still, there's no real reason to not run 64bit software at this point if you've got the hardware.
wuss ;-)
Oh, I quit before that (with the 11.x release). What happened with the kernel in 12?
Add in the lack of 64 bit support, and you have the reason that my entire infrastructure isn't based on Slack still.
I still subscribe to the CD sets, but I just do it to support Patrick. I don't actually use them, I just line them up and remember fondly the days of installing (and installing (and installing)) Slack onto my first machine, a 486DX2/66 with dual speed CD-ROM. Incidentally, I credit that CD-ROM with being the reason that I learned linux so well. I watched the install crawl by so many times that I pretty much memorized the packages and what they did.
Assuming you have a VPN client (or are using an SSL VPN which is "Clientless" (big lie)) then only that computer's traffic is sent over the VPN.
If, on the other hand, you have a VPN device that you plug in in front of (or behind) your broadband router, all of your connection's traffic will be going to the VPN. That's just as (if not more) insecure as a partial tunnel.
That's true, but with a "secure" VPN connection, not being able to use local resources would be considered a plus.
Of course, "secure" is always a sliding scale.
Actually, it shouldn't slow down the internal stuff at all, since it was going over the same link as before. His internet browsing will go a lot slower, but he can disconnect from the VPN for personal browsing.