 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/09/2011 03:46 AM, Darren New wrote:
> Again, it depends on what you're doing and where the Linux is living.
> I'll grant that *desktop* linux systems rarely *need* rebooting. And I'd
> argue that if you have a server whose *only* job is being a web server,
> then restarting the web server after an upgrade is essentially the same
> as a reboot, except faster.
Actually Windows is getting better at not needing to be rebooted either.
You can quite often install or uninstall software, and it doesn't bother
asking for a reboot. It just /works/. (Indeed, lots of older software
asks for a reboot, but actually works fine without one.)
And - fortunately - it's becoming less common to need to reboot due to
resource leaks too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/09/2011 03:15 AM, Darren New wrote:
> On 9/15/2011 2:44, Le_Forgeron wrote:
>> try playing xonix via VNC... it's far easier with just a X server on the
>> windows system.
>
> VNC wasn't really designed for efficiency.
The fail!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Sometimes I think it would be nice if there was a widely-supported
>> standard for configuring the firewall at the /other end/ of the last
>> mile to drop certain packets. But anyway...
>
> A DDoS needs to be extremely big for an ISP to notice one of its
> customers is under attack. And you need a special business relationship
> to be able to call them up and ask that they block a certain type of
> traffic at the head end.
Quite. I did actually hear about a guy having to spend ages on the phone
to their ISP to ask for firewall configuration changes.
Now imagine if there were a standard, widely-implemented system for
letting the customer make those configuration changes themselves...
Let's face it, the ISP's routers are almost certainly remote-manageable
anyway. If the unwanted packets can be blocked at the entrance to the
ISP's network, they can save themselves the bother of having to route a
bunch of traffic. (Although the amount of data you can fire at one
customer is probably peanuts compared to the ISP network capacity.)
Ah well, dream on...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/09/2011 03:08 AM, Darren New wrote:
> On 9/12/2011 1:41, Invisible wrote:
>> After reading several dozen forum posts, it seems nobody has a really
>> good
>> solution for doing this.
>
> Actually, when you think about it, the two people in this situation are
> not unlikely using two computers both of which are using the same IP
> address, like 192.168.0.2. Hard to see how to make a TCP/IP transfer
> easy if both target machines have the same IP address, regardless of
> software installed or operating system in use.
With NAT, it can work perfectly well. At long as each endpoint knows the
other only by its publicly routable IP address, anyway.
There are probably web servers that run on RFC-1918 IP addresses. And
plenty of home users who do. And yet, they can still talk to each other...
The /problem/ happens when you want to route between two entire
/networks/ with the same network number.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Man pages are not intended to be tutorials. They're manual pages.
>>
>> ...which is the point I'm trying to make, yes.
>
> So then what's the problem? You're complaining that they're not
> tutorials, but they're not intended to be tutorials.
No, I'm complaining that tutorials don't exist. Only reference manuals.
>> Since I'm guessing the answer is probably "yes", then I don't need to
>> explain to you how hard it is...
>
> Yes, and I usually end up googling instead. I'm sure I could figure it
> out, but I don't need it that often.
Let's just hope you're not trying to look up how to configure Internet
access...
>>>> So even with this line, people can *still* authenticate by password.
>>>
>>> Not to the best of my knowledge.
>>
>> I'm fairly sure I tested it, and discovered that I needed to turn off
>> multiple things to stop it accepting my password as a valid login. But
>> since that was then and this is now, I guess I might be incorrect.
>
> It might be easier now, yes. Honestly, I've never even looked for a CHAP-
> based authentication mechanism for ssh.
No, I mean, I might be remembering this wrong.
>>> A sample size of 3 isn't exactly data supporting "commonly used".
>>
>> It's infinity times larger than a sample size of zero. ;-)
>
> Sure, but not mathematically significant.
Not /statistically/ significant, if you want to be picky.
>> Imagine it: Going to all the trouble of setting up a secure system, and
>> not even knowing how to secure it properly...
>
> I don't have to - I see it fairly regularly.
This is the real WTF...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 16/09/2011 10:24, Invisible a écrit :
> Actually Windows is getting better at not needing to be rebooted either.
Told me... this morning security update did insist on reboot.
As usual!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16/09/2011 11:03 AM, Le_Forgeron wrote:
> Le 16/09/2011 10:24, Invisible a écrit :
>> Actually Windows is getting better at not needing to be rebooted either.
>
> Told me... this morning security update did insist on reboot.
> As usual!
Sure. But that's because it's probably replacing bits of the OS kernel,
or at the very least it's replacing widely-used system libraries, and
the simplest way to handle that is to just reboot.
I can install an AV product and not need to reboot. (Very useful for
fileservers!) I can install .NET, or Office, or VisualStudio, and not
need to reboot. I can install all kinds of stuff, and mostly I don't
need to reboot. Sometimes you still do, but it used to be any installing
or uninstalling *anything* always required a reboot.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/16/2011 3:03, Le_Forgeron wrote:
> Told me... this morning security update did insist on reboot.
And, oddly enough, mine didn't. Possibly because I actually closed the
programs in the way before installing the updates.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/16/2011 1:25, Invisible wrote:
> On 16/09/2011 03:15 AM, Darren New wrote:
>> On 9/15/2011 2:44, Le_Forgeron wrote:
>>> try playing xonix via VNC... it's far easier with just a X server on the
>>> windows system.
>>
>> VNC wasn't really designed for efficiency.
>
> The fail!
Nope. It was just designed to be easy to implement instead of being
efficient. Show me X-Windows ported to a javascript client.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/16/2011 1:30, Invisible wrote:
> With NAT, it can work perfectly well. At long as each endpoint knows the
> other only by its publicly routable IP address, anyway.
Assuming you have configured at least one to *have* a publicly routable IP
address. That's kind of the point.
> There are probably web servers that run on RFC-1918 IP addresses. And plenty
> of home users who do. And yet, they can still talk to each other...
The problem comes when the person running the server doesn't know how to
route traffic from the public IP address to the private one.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
