On Thu, 15 Sep 2011 19:17:36 +0100, Orchid XP v8 wrote:

>>> As far as I know, getting X to actually work remotely is extremely
>>> difficult, whereas I know from experience that getting VNC to work
>>> remotely is trivial.
>>
>> VNC is also trivially compromised unless you tunnel it over ssh or wrap
>> it in ssl.
> 
> If the two machines are on the same LAN, this probably isn't a problem.
> (And presumably the same applies to X as well anyway...)

Yes, that's true, if you trust the LAN.

Jim

Post a reply to this message

On Thu, 15 Sep 2011 19:46:42 +0100, Orchid XP v8 wrote:

>> 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.

>>> Then again, sometimes the manpage just says "use info". And then you
>>> had /another/ problem...
>>
>> Well, no, it's not *another* problem - you just need to use the info
>> command instead.
> 
> Have /you/ tried navigating the thing?
> 
> 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.

>>> 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.

>>>>> I thought the host key is how the server identifies itself to you,
>>>>> not how you identify yourself to the server?
>>>>
>>>> Host keys aren't very commonly used AFAIK.
>>>
>>> All three of the SFTP systems we use commercially have them.
>>
>> 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.

> Then again, one of these systems is set up to use PK authentication, and
> the server administrators emailled /us/ with the private key to use to
> get access. *facepalm*
> 
> 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.

Jim

Post a reply to this message

On Thu, 15 Sep 2011 19:10:09 -0700, Darren New wrote:

> On 9/15/2011 18:19, Francois Labreque wrote:
>> Heathen! Linux machines do not need to be rebooted. Ever.
> 
> I'm pretty sure you're wrong on that one.

Yeah, kernel updates require a reboot.  Other than that, you usually 
don't have to (unless you're killing zombie processes), but sometimes 
"it's easier".

Jim

Post a reply to this message

On 9/15/2011 19:36, Jim Henderson wrote:
> Yeah, kernel updates require a reboot.  Other than that, you usually
> don't have to

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.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

>>> Did you at least refresh (aka reload) sshd when updating the
>>> configuration ?
>>
>> Is rebooting the machine sufficient to do that?
>>
>> If so, yes...
>>
>
> Heathen! Linux machines do not need to be rebooted. Ever.

It's not so much that I purposely rebooted it; more that it's a laptop 
that shuts down whenever the power is unplugged. So every time I moved 
it to a different location in the building, it was effectively rebooted.

> To quote Yoda: Unlearn everything you must.

If you're going to quote Yoda, do it right:

"Then you must /unlearn/ all that you have /learned/."

Not every sentence he utters is in object-subject-verb order. (At least, 
not in the original trilogy.)

If you really want to split hairs,

http://itre.cis.upenn.edu/~myl/languagelog/archives/002173.html

Post a reply to this message

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

On Thu, 15 Sep 2011 19:46:30 -0700, Darren New wrote:

> On 9/15/2011 19:36, Jim Henderson wrote:
>> Yeah, kernel updates require a reboot.  Other than that, you usually
>> don't have to
> 
> 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.

I don't see a need to regularly reboot Linux servers either, unless 
there's a kernel update.

Jim

Post a reply to this message

On Fri, 16 Sep 2011 09:34:42 +0100, Invisible wrote:

>> 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.

Tutorials exist, they're not included with the OS.  Do I really need to 
say (again) "GIYF"?

>>> 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...

I've managed to do that enough times that it generally isn't something I 
need to look up these days.  But if I did, a quick trip to my public 
library to use one of their computers to do the search will in fact solve 
that problem.

Or I could use my phone.

Or I could use another of my systems here.

>> 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.

That's certainly possible.

>>>> 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.

Statistics is a branch of mathematics. :P

>>> 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...

People who work in IT have not had to learn as much these days as they 
did 20 years ago.  That means they set up systems and often don't have 
the knowledge or skills to properly secure a system.

And the first thing to get cut from IT budgets is funding for training, 
usually.  Training that could actually resolve some of those security 
issues by having competent staff.

Jim

Post a reply to this message

On 9/16/2011 9:54, Jim Henderson wrote:
> I don't see a need to regularly reboot Linux servers either, unless
> there's a kernel update.

So when the memory leak in your Linux-based wireless access point crashes 
your machine, what do you do?  When your cable box no longer synchronizes 
with the cable provider, or you get a new configuration pushed to your cable 
modem from the head end, what do you do? When you update the PRL on your 
android phone, what happens after the new PRL is stored?

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 16/09/2011 5:57 PM, Jim Henderson wrote:
> Training that could actually resolve some of those security
> issues by having competent staff.

You're asking a lot there, Jim. ;-)

-- 
Regards
     Stephen

Post a reply to this message

Le 2011-09-15 22:10, Darren New a écrit :
> On 9/15/2011 18:19, Francois Labreque wrote:
>> Heathen! Linux machines do not need to be rebooted. Ever.
>
> I'm pretty sure you're wrong on that one.
>
A previous version of that post had a smiley at the end.  I guess it got 
lost during the vetting process.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On Fri, 16 Sep 2011 10:01:51 -0700, Darren New wrote:

> On 9/16/2011 9:54, Jim Henderson wrote:
>> I don't see a need to regularly reboot Linux servers either, unless
>> there's a kernel update.
> 
> So when the memory leak in your Linux-based wireless access point
> crashes your machine, what do you do?  

I report the bug with supporting data, build the latest version of the 
code, and try to fix it.  I don't just reboot it.

In fact, I went through something very similar to this not long ago - my 
wireless router/access point runs openWRT, and a recent update borked the 
atheros driver.  Rebuilt the older kernel, reported the bug, and applied 
the downgrade.

> When your cable box no longer
> synchronizes with the cable provider, or you get a new configuration
> pushed to your cable modem from the head end, what do you do? 

Well, I don't have cable any more (it was an expense we had to cut when I 
was laid off).  But that's an appliance, not the same as "running a Linux 
server" in my book.  If Comcast wants to reboot their box, they can 
reboot their box.

> When you
> update the PRL on your android phone, what happens after the new PRL is
> stored?

Again, not a Linux *server* - it's an appliance.  If Verizon decides the 
phone needs rebooted, then it gets rebooted.

There's probably a way to do this without rebooting the device 
(especially if it's rooted), but often times it's just simpler to reboot.

That doesn't mean a reboot is *necessary*, which is what we were 
discussing.

Jim

Post a reply to this message

On Fri, 16 Sep 2011 18:06:01 +0100, Stephen wrote:

> On 16/09/2011 5:57 PM, Jim Henderson wrote:
>> Training that could actually resolve some of those security issues by
>> having competent staff.
> 
> You're asking a lot there, Jim. ;-)

Indeed, I am - but things could get interesting here job-wise, as I've 
found a job where I might actually have to solve that one. :)

Jim

Post a reply to this message

On Fri, 16 Sep 2011 13:16:49 -0400, Jim Henderson wrote:

> On Fri, 16 Sep 2011 18:06:01 +0100, Stephen wrote:
> 
>> On 16/09/2011 5:57 PM, Jim Henderson wrote:
>>> Training that could actually resolve some of those security issues by
>>> having competent staff.
>> 
>> You're asking a lot there, Jim. ;-)
> 
> Indeed, I am - but things could get interesting here job-wise, as I've
> found a job where I might actually have to solve that one. :)

(Not as in "been given an offer for", rather I found a posting that I'm 
applying for)

Jim

Post a reply to this message

Le 2011-09-16 04:30, Invisible a écrit :
>
> With NAT, it can work perfectly well. At long as each endpoint knows the
> other only by its publicly routable IP address, anyway.

Correction: as long as both endpoints know each other by an address that 
works for them.

I know of customers who do inbound natting of third party servers as 
well, because they don't want to route the public IP range inside their 
network.

> There are probably web servers that run on RFC-1918 IP addresses.

I would wager that the vast majority of them do.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 2011-09-16 04:28, Invisible a écrit :
>>> 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...

Then it would take 2.5 nanoseconds for a hacker to steal your 
credentials and make those changes for you.  BLAM! total denial of service.

Some IDS/IPS vendors have programmed routines in their systems that can 
automatically change firewall rules in the event that they detect an 
attack, yet the majority of installations leave this feature turned off 
because people are afraid of false alerts blocking valid traffic, and 
having HAL in control of the pod bay doors.

I'm sure ISPs feel the same way about having their customers be able to 
play with their firewall configs.
-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 16/09/2011 6:17 PM, Jim Henderson wrote:
>>
>>> On 16/09/2011 5:57 PM, Jim Henderson wrote:
>>>> Training that could actually resolve some of those security issues by
>>>> having competent staff.
>>>
>>> You're asking a lot there, Jim. ;-)
>>
>> Indeed, I am - but things could get interesting here job-wise, as I've
>> found a job where I might actually have to solve that one. :)
>
> (Not as in "been given an offer for", rather I found a posting that I'm
> applying for)
>

Good luck with that one. I hope that you can deliver on time and in 
budget ;-)


-- 
Regards
     Stephen

Post a reply to this message

On 9/16/2011 10:15, Jim Henderson wrote:
>  not the same as "running a Linux server" in my book.

I agree. That's precisely my point.  Saying "you never have to reboot a 
Linux machine except for kernel upgrades" is incorrect. It assumes the box 
has all the tools it needs to manage it without rebooting, and it assumes 
your software environment isn't hardened against you manipulating it in the 
ways described.

> That doesn't mean a reboot is *necessary*, which is what we were
> discussing.

OK, so how do you upgrade your PRL without rebooting your phone? My point is 
that claiming "you don't have to" assumes a whole bunch of facts that 
aren't true just because you're running Linux.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Fri, 16 Sep 2011 12:00:28 -0700, Darren New wrote:

> On 9/16/2011 10:15, Jim Henderson wrote:
>>  not the same as "running a Linux server" in my book.
> 
> I agree. That's precisely my point.  Saying "you never have to reboot a
> Linux machine except for kernel upgrades" is incorrect. It assumes the
> box has all the tools it needs to manage it without rebooting, and it
> assumes your software environment isn't hardened against you
> manipulating it in the ways described.

You specified servers and desktops - not appliance devices.

I also never said "you never have to reboot a Linux machine except for 
kernel updates".  I said "you usually never have to reboot a Linux 
machine except for kernel updates".  There's a world of difference in 
those two statements.

I also very specifically stated that if you're dealing with zombie 
processes, a Linux system *requires* a reboot to the best of my knowledge.

>> That doesn't mean a reboot is *necessary*, which is what we were
>> discussing.
> 
> OK, so how do you upgrade your PRL without rebooting your phone? My
> point is that claiming "you don't have to" assumes a whole bunch of
> facts that aren't true just because you're running Linux.

I've never had a need to, so I don't know.  Presumably you could stop a 
service or unload/reload a driver, or drop to single user mode and then 
go back to the default runlevel.

Jim

Post a reply to this message

On Fri, 16 Sep 2011 19:10:30 +0100, Stephen wrote:

> On 16/09/2011 6:17 PM, Jim Henderson wrote:
>>>
>>>> On 16/09/2011 5:57 PM, Jim Henderson wrote:
>>>>> Training that could actually resolve some of those security issues
>>>>> by having competent staff.
>>>>
>>>> You're asking a lot there, Jim. ;-)
>>>
>>> Indeed, I am - but things could get interesting here job-wise, as I've
>>> found a job where I might actually have to solve that one. :)
>>
>> (Not as in "been given an offer for", rather I found a posting that I'm
>> applying for)
>>
>>
> Good luck with that one. I hope that you can deliver on time and in
> budget ;-)

A little late on the "on time" bit (I had wanted to be back to work about 
2 months ago - but only in a position that was right for me), but yeah, I 
think this could work out well once I get the resume into the right 
person's hands.  The trick is making sure it gets to the right person 
rather than going through "the front door".

Jim

Post a reply to this message

On 9/16/2011 12:57, Jim Henderson wrote:
> You specified servers and desktops - not appliance devices.

No I didn't.  I was responding to someone else's comment of

 >> Heathen! Linux machines do not need to be rebooted. Ever.

That didn't say "Linux machines with a full development environment 
installed and to which you have root access never have to be rebooted." 
That's my point here. :-)

> I've never had a need to, so I don't know.  Presumably you could stop a
> service or unload/reload a driver, or drop to single user mode and then
> go back to the default runlevel.

Cool. How do I drop to single-user mode on my cell phone?

Again, you're making assumptions that the linux in your phone (or your cable 
box or your credit card terminal) is like the linux in your desktop or 
server machine.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Am 16.09.2011 19:14, schrieb Francois Labreque:
> Le 2011-09-15 22:10, Darren New a écrit :
>> On 9/15/2011 18:19, Francois Labreque wrote:
>>> Heathen! Linux machines do not need to be rebooted. Ever.
>>
>> I'm pretty sure you're wrong on that one.
>>
> A previous version of that post had a smiley at the end. I guess it got
> lost during the vetting process.

Id didn't get lost - it just hid between the lines. I swear I can hear 
it chuckling.

Post a reply to this message

On Fri, 16 Sep 2011 13:22:55 -0700, Darren New wrote:

> On 9/16/2011 12:57, Jim Henderson wrote:
>> You specified servers and desktops - not appliance devices.
> 
> No I didn't.  I was responding to someone else's comment of
> 
>  >> Heathen! Linux machines do not need to be rebooted. Ever.
> 
> That didn't say "Linux machines with a full development environment
> installed and to which you have root access never have to be rebooted."
> That's my point here. :-)

That's fair.  You wrote your reply to a message I wrote, so clearly I 
thought you were responding to what I said.

>> I've never had a need to, so I don't know.  Presumably you could stop a
>> service or unload/reload a driver, or drop to single user mode and then
>> go back to the default runlevel.
> 
> Cool. How do I drop to single-user mode on my cell phone?

Probably depends on the phone.  Like I said, I've never needed to find 
out, so I don't know.

> Again, you're making assumptions that the linux in your phone (or your
> cable box or your credit card terminal) is like the linux in your
> desktop or server machine.

Linux is a kernel.  I'm not making assumptions about the kernel.

Jim

Post a reply to this message

On 9/16/2011 21:36, Jim Henderson wrote:
> That's fair.  You wrote your reply to a message I wrote, so clearly I
> thought you were responding to what I said.

I still never specified servers at all, and I only mentioned desktops in a 
disclaimer. :-)

-- 
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 21:36, Jim Henderson wrote:
 > Linux is a kernel.  I'm not making assumptions about the kernel.

Incidentally, in the real world, nobody cares about the kernel. If you have 
10,000 airline agents hitting your database from all around the world, and 
your database server takes 10 minutes to restart and recache its indexes 
after you upgrade the code, nobody really cares if the kernel survived the 
upgrade or not. :-)  That's what always amuses me about such discussions.

Indeed, people don't really even care if it was the database down or the 
router provided by your ISP.  A backhoe outside your door is going to screw 
up your uptime stats as much as a kernel upgrade will.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Sat, 17 Sep 2011 07:13:26 -0700, Darren New wrote:

> On 9/16/2011 21:36, Jim Henderson wrote:
>  > Linux is a kernel.  I'm not making assumptions about the kernel.
> 
> Incidentally, in the real world, nobody cares about the kernel. If you
> have 10,000 airline agents hitting your database from all around the
> world, and your database server takes 10 minutes to restart and recache
> its indexes after you upgrade the code, nobody really cares if the
> kernel survived the upgrade or not. :-)  That's what always amuses me
> about such discussions.

Certainly - and the question of whether it has to be rebooted or not is 
somewhat mooted by that point.  I can get a lot of things to restart 
properly by just going to single user mode and back to runlevel 3 or 5, 
but if services are offline, that's still downtime.

Server uptime isn't a great measure of availability.  Service uptime is 
more meaningful.

Just like the neverending debate about which Linux desktop environment is 
the "best".  I've used pretty much all of them, and have come to the 
conclusion that the DE is pretty irrelevant - if I am using a computer, 
I'm using it for the apps, not the DE.  If I'm focused on the DE so much 
that I "hate" KDE or GNOME or LXDE or whatever - then I'm obviously not 
using the computer as a tool to get actual work done.

> Indeed, people don't really even care if it was the database down or the
> router provided by your ISP.  A backhoe outside your door is going to
> screw up your uptime stats as much as a kernel upgrade will.

Absolutely.

Jim

Post a reply to this message

On Fri, 16 Sep 2011 22:37:00 -0700, Darren New wrote:

> On 9/16/2011 21:36, Jim Henderson wrote:
>> That's fair.  You wrote your reply to a message I wrote, so clearly I
>> thought you were responding to what I said.
> 
> I still never specified servers at all, and I only mentioned desktops in
> a disclaimer. :-)

"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."

That seems to be the source of the misunderstanding, because you did talk 
about servers there.

Jim

Post a reply to this message

On 9/17/2011 10:32, Jim Henderson wrote:
> On Fri, 16 Sep 2011 22:37:00 -0700, Darren New wrote:
>
>> On 9/16/2011 21:36, Jim Henderson wrote:
>>> That's fair.  You wrote your reply to a message I wrote, so clearly I
>>> thought you were responding to what I said.
>>
>> I still never specified servers at all, and I only mentioned desktops in
>> a disclaimer. :-)
>
> "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."
>
> That seems to be the source of the misunderstanding, because you did talk
> about servers there.

Fair enough. Plus that statement applies to any OS, not just Linux. :-)

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 9/17/2011 10:31, Jim Henderson wrote:
> that I "hate" KDE or GNOME or LXDE or whatever - then I'm obviously not
> using the computer as a tool to get actual work done.

Heh heh heh. I'm definitely going to steal that.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On Sun, 18 Sep 2011 09:14:28 -0700, Darren New wrote:

> On 9/17/2011 10:32, Jim Henderson wrote:
>> On Fri, 16 Sep 2011 22:37:00 -0700, Darren New wrote:
>>
>>> On 9/16/2011 21:36, Jim Henderson wrote:
>>>> That's fair.  You wrote your reply to a message I wrote, so clearly I
>>>> thought you were responding to what I said.
>>>
>>> I still never specified servers at all, and I only mentioned desktops
>>> in a disclaimer. :-)
>>
>> "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."
>>
>> That seems to be the source of the misunderstanding, because you did
>> talk about servers there.
> 
> Fair enough. Plus that statement applies to any OS, not just Linux. :-)

That's certainly true.

Jim

Post a reply to this message

On Sun, 18 Sep 2011 09:15:21 -0700, Darren New wrote:

> On 9/17/2011 10:31, Jim Henderson wrote:
>> that I "hate" KDE or GNOME or LXDE or whatever - then I'm obviously not
>> using the computer as a tool to get actual work done.
> 
> Heh heh heh. I'm definitely going to steal that.

Feel free. :)

Jim

Post a reply to this message

>>> VNC wasn't really designed for efficiency.
>>
>> The fail!
>
> Nope. It was just designed to be easy to implement instead of being
> efficient.

If you're designing a system to control other systems remotely, the 
efficiency of that system over a low network link ought to be the number 
one priority. If I'm remote-controlling a system, I don't really care 
how easy it is to implement the wire protocol; I care whether it *works* 
well.

> Show me X-Windows ported to a javascript client.

Why would you want to do that?

Post a reply to this message

>> 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...
>
> Then it would take 2.5 nanoseconds for a hacker to steal your
> credentials and make those changes for you. BLAM! total denial of service.

...or you could, you know, make it so the command interface is only 
accessible from the customer's side of the firewall? Then they have to 
actually hack the customer's system first.

> Some IDS/IPS vendors have programmed routines in their systems that can
> automatically change firewall rules in the event that they detect an
> attack, yet the majority of installations leave this feature turned off
> because people are afraid of false alerts blocking valid traffic, and
> having HAL in control of the pod bay doors.
>
> I'm sure ISPs feel the same way about having their customers be able to
> play with their firewall configs.

Well, yeah, you wouldn't want to give clueless users direct access to 
the actual firewall configuration. You'd want some higher-level way of 
allowing people to select "features" they want or don't want, and then 
have some software manage translating that into actual IP configuration 
changes. (For starters, there are going to be rules that the ISP don't 
want users to be able to turn off...)

Post a reply to this message

Le 2011-09-19 04:16, Invisible a écrit :
>>>> VNC wasn't really designed for efficiency.
>>>
>>> The fail!
>>
>> Nope. It was just designed to be easy to implement instead of being
>> efficient.
>
> If you're designing a system to control other systems remotely, the
> efficiency of that system over a low network link ought to be the number
> one priority. If I'm remote-controlling a system, I don't really care
> how easy it is to implement the wire protocol; I care whether it *works*
> well.
>
>> Show me X-Windows ported to a javascript client.
>
> Why would you want to do that?

Because it would be fully buzzword compliant.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 9/19/2011 1:16, Invisible wrote:
> efficiency of that system over a low network link ought to be the number one
> priority.

Uh, no.  VNC was *specifically* designed to be trivial to implement at both 
ends.

> If I'm remote-controlling a system, I don't really care how easy
> it is to implement the wire protocol; I care whether it *works* well.

Except you aren't the person who designed VNC. You're the person who should 
be using RDP or maybe X-Windows, or NeWS, or any of the other dozens of 
remote graphics solutions.

>> Show me X-Windows ported to a javascript client.
> Why would you want to do that?

Ask the guys who wrote VNC, which runs in a web browser too, you know.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 19/09/2011 06:49 PM, Darren New wrote:

> Uh, no. VNC was *specifically* designed to be trivial to implement at
> both ends.

And here I was thinking it was designed to, you know, allow you to 
remote control things. Because there aren't any other cross-platform 
solutions for doing that.

> Except you aren't the person who designed VNC. You're the person who
> should be using RDP or maybe X-Windows, or NeWS, or any of the other
> dozens of remote graphics solutions.

It's news to me that "dozens of remote graphics solutions" exist. It's 
certainly news to me that any of them work on more than one platform.

> Ask the guys who wrote VNC, which runs in a web browser too, you know.

In what universe is that useful?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Mon, 19 Sep 2011 19:25:40 +0100, Orchid XP v8 wrote:

> On 19/09/2011 06:49 PM, Darren New wrote:
> 
>> Uh, no. VNC was *specifically* designed to be trivial to implement at
>> both ends.
> 
> And here I was thinking it was designed to, you know, allow you to
> remote control things. Because there aren't any other cross-platform
> solutions for doing that.

Like RDP, for example?  Yes, I have an RDP client that runs on Linux.

>> Except you aren't the person who designed VNC. You're the person who
>> should be using RDP or maybe X-Windows, or NeWS, or any of the other
>> dozens of remote graphics solutions.
> 
> It's news to me that "dozens of remote graphics solutions" exist. It's
> certainly news to me that any of them work on more than one platform.

Teamviewer, VNC, NoMachine's NX client/server, XDMCP...I could go on.

>> Ask the guys who wrote VNC, which runs in a web browser too, you know.
> 
> In what universe is that useful?

In a universe where you don't have or want to install a full-blown client 
locally.

Say you need to remotely access a system from your public library's 
computer.  I'm sure they won't let you install arbitrary software on 
their system.  But they probably have Java installed for the browser.

Hell, the remote exams I used to run at Novell could be run in a browser 
- far easier to support in some ways than having to walk a non-technical 
person through installing a client and making sure the software 
functioned properly.

Jim

Post a reply to this message

On 9/19/2011 11:25, Orchid XP v8 wrote:
> And here I was thinking it was designed to, you know, allow you to remote
> control things.

Which it does.

> Because there aren't any other cross-platform solutions for
> doing that.

Nonsense.

> It's news to me that "dozens of remote graphics solutions" exist. It's
> certainly news to me that any of them work on more than one platform.

I'm not surprised. :-)

>> Ask the guys who wrote VNC, which runs in a web browser too, you know.
> In what universe is that useful?

In the universe where you may need to log into your machine remotely from a 
machine where you aren't allowed to install software?

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

Le 20/09/2011 03:08, Darren New a écrit :
>>> Ask the guys who wrote VNC, which runs in a web browser too, you know.
>> In what universe is that useful?
> 
> In the universe where you may need to log into your machine remotely
> from a machine where you aren't allowed to install software?

More specifically, in the universe where you are on a remote machine
where you aren't allowed to install software and which also lack basic
communication facilities like telnet, ftp and ssh client by default.
(Guess what, there is probably only one successfull OS provider which
still match both criteria).


That's a more tiny universe.

Post a reply to this message

On 9/19/2011 23:52, Le_Forgeron wrote:
> which also lack basic
> communication facilities like telnet, ftp and ssh client by default.

It has nothing to do with that. The presence of an FTP client is not going 
to get you a graphical interface into your machine.

-- 
Darren New, San Diego CA, USA (PST)
   How come I never get only one kudo?

Post a reply to this message

On 20/09/2011 07:52 AM, Le_Forgeron wrote:

> More specifically, in the universe where you are on a remote machine
> where you aren't allowed to install software and which also lack basic
> communication facilities like telnet, ftp and ssh client by default.
> (Guess what, there is probably only one successfull OS provider which
> still match both criteria).

Well, Windows ships with Telnet and FTP by default. The only one missing 
is SSH - and *clients* for SSH aren't hard to find.

Post a reply to this message