Ah yes, another day, another piece of stupidity to sort out.

We have some equipment in our lab. It needs a computer to control it. 
Unfortunately, the control software requires somebody to be logged in. 
As soon as you log out, it quits the control program, halting the machine.

But don't worry. There is a straight-forward way to solve this problem. 
We have some other software, which we are already using, which has the 
facility to control this equipment. And *this* software runs as a 
service, as it should, and has appropriate security access controls and 
auditing and so forth. This will make our job vastly easier - even 
easier than it is currently.

So we're _not_ going to use this feature. Why? Because the people at HQ 
don't use this feature. Currently all the sites work slightly 
differently, and the people in charge want to "harmonise" business 
practice across all sites. In English, they want everybody to do exactly 
what HQ does.

I should point out that when somebody asked HQ for the wiring diagram to 
connect up a certain piece of equipment, their senior lab expert sent 
back a diagram that includes, among other things, a paper clip to 
complete the circuit. (We won't be following this practice. We elected 
to use a junction block, like any half-sane person would...)

Getting back on track... How *are* we going to control this equipment 
then? Well, the solution dictated to us by HQ is to use a seperate 
laptop to run the control software. Which seems reasonable, if not 
particularly optimal.

Ah, but here's the fun part: The equipment is controlled by RS-232. Now, 
how many laptops do you know of which actually possess a serial port? 
Exactly.

But it's OK, it's not a problem. All we have to do is purchase a USB to 
serial converter and we're golden.

Except that the control software stubbornly, repeatedly *refuses* to 
believe me that the USB serial port actually exists. Every other piece 
of software I've tried can access it without issue. But not the one 
piece of software that we *need* to access it. No sir. Not interested. 
It can "see" the port, but it refuses to *select* that port. And nothing 
I've done so far seems to convince it to work.

I also got sent three laptops from HQ which have built-in serial ports. 
The reason for this is that they're ancient. One of them is already set 
up and running. One of them won't turn on. The charging indicator comes 
on when I plug it in, but it won't actually switch on. And the third... 
well, I was hoping to set that up today.

I became worried when I saw the big "Designed for Windows 98" sticker on 
it. The harddrive is a mess. It has every application, screensaver, game 
and utility imaginable installed. It has files everywhere. My plan was 
to erase everything and load Windows XP, except - and you can see the 
horrifying inevitability of where this is going - the laptop is powered 
by an AMD K6-II processor and sports 64MB of RAM.

Now there is no way in HELL that Windows XP is going to run like 
anything faster than a glacier with 64MB of RAM. Hell, Windows 98 crawls 
along on this PC!

Clearly improving the CPU is impossible, but maybe adding more RAM would 
speed it up? Except... what the hell kind of RAM does a K6 laptop take 
anyway? Wikipedia claims that the K6 has a 66MHz FSB, so... PC66 maybe? 
Of course, that's no longer on sale. But Wikipedia claims PC100 is 
backwards-compatible. Ah, but *that* isn't available either. But I can 
buy PC133. Wikipedia claims PC133 is backwards-compatible with PC100, 
but is that transitive? Will PC133 work in a PC66 laptop?

On top of that, PC133 is *very* expensive. Like, £80 for 128MB. And 
128MB is really not enough. But the biggest single-stick listing I can 
find is for 512MB (which should probably just about work). Then again, 
this is a *laptop*. How many tracks do you think Compaq bothered to 
connect up? Can it actually address half a gigabyte of RAM??

Still, I have until tomorrow to sort all this out... no biggie.

Post a reply to this message

In article <4a815b1f$1@news.povray.org>,
Invisible wrote:

> Ah yes, another day, another piece of stupidity to sort out.

[...] LOL! I mean, sorry.

You know, the whole idea of working somewhere and having to accept
tyranical measures is wrong. Work is far too important to leave it up
to others. It is the very foundation of one's life.

I do know what to do in my case, but I don't know what to do in
everyone's case. I don't think I ever will. But I do think that one
must think about saving oneself from the tyranny of companies.
Particularly because we can. Or can't we?

Post a reply to this message

The more I think about this, the more I'm losing the will to go on. All 
this effort to jump through hoops to hook up an elaborate jerry-rig of 
obsolete hardware to solve a problem which we ALREADY HAVE A PROPPER 
SOLUTION FOR. The correct solution is right in front of our eyes, so 
we're just going to ignore something and build something that's going to 
cause us problems for years to come instead. WHY?! >_<

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> So we're _not_ going to use this feature. Why? Because the people at HQ 
> don't use this feature.

  What happens if you use it anyways?

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Invisible <voi### [at] devnull> wrote:
> > So we're _not_ going to use this feature. Why? Because the people at HQ
> > don't use this feature.
>
>   What happens if you use it anyways?

HQ gets upset because you don't follow protocol.  You get upset because they
require an unreasonable solution.  They get more upset because you are now
deliberately disobeying orders.  You get more upset they don't listen to
reason.  They get upset because they can't simply apply one rule to all groups
and create a nice, perfect world.  Meanwhile, both groups think the other is a
collection of complete idiots, too stubborn to just do the reasonable thing,
solve the problem, and move on.

At least, that's how it works around here.  Now, it's an external contract so
it's a little different, but really it's basically the same.  They used
incorrect physics to redesign the prototype so it can use a little less power.
We know it won't work and don't want to go down that road.  We try to explain it
to them, but they just get upset that we refuse to help them.  And it goes back
and forth.

 - Ricky

Post a reply to this message

On 11-8-2009 18:38, Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> So we're _not_ going to use this feature. Why? Because the people at HQ 
>> don't use this feature.
> 
>   What happens if you use it anyways?
> 
Indeed, my advise would be to find an (obscure) british rule about 
quality control that could be interpreted to the effect that the HQ 
solution being illegal. There may be a rule about using an OS that is 
unsupported and therefore vulnerable to any new virus that comes out. 
OSLT. Andy, use your knowledge, you know more about legal requirements 
than HQ.

Post a reply to this message

In article <4A8### [at] hotmailcom>,
andrel wrote:

> On 11-8-2009 18:38, Warp wrote:
>> Invisible <voi### [at] devnull> wrote:
>>> So we're _not_ going to use this feature. Why? Because the people at HQ 
>>> don't use this feature.
>> 
>>   What happens if you use it anyways?
>> 
> Indeed, my advise would be to find an (obscure) british rule about 
> quality control that could be interpreted to the effect that the HQ 
> solution being illegal. There may be a rule about using an OS that is 
> unsupported and therefore vulnerable to any new virus that comes out. 
> OSLT. Andy, use your knowledge, you know more about legal requirements 
> than HQ.

That's good thinking. One could actually find in the law the support
needed to defend oneself from corporative despotism. I just hope you
can find something in the law... :-)

Also notice this can always get one fired. Disobedience is not at all
praised out there.

Post a reply to this message

On Tue, 11 Aug 2009 18:00:09 -0400, Daniel Bastos wrote:

> Disobedience is not at all
> praised out there.

Depends on the job and the company, and the reason why.  If a company is 
making you do something that could get you put in jail, disobedience is 
the right course of action.

Jim

Post a reply to this message

>> So we're _not_ going to use this feature. Why? Because the people at HQ 
>> don't use this feature.
> 
>   What happens if you use it anyways?

The MHRA gets upset with us for using a software feature which we 
haven't performed extensive formal testing on.

Now, we *could* devise and execute a test plan... but nobody here really 
has the necessary expertise. HQ does. And they can't be bothered to go 
down this route.

Post a reply to this message

What OS can the software run in? You might make use of virtualization 
(VMWare, VirtualPC, etc.) to solve your problem.

You should be able to control the properties of the virtual machine and 
tell it it has a serial port even if it doesn't. Running an old OS 
within a virtual machine on a modern laptop should still be faster than 
running the same OS on its native hardware.

-Mike

Post a reply to this message

SharkD wrote:
> What OS can the software run in? You might make use of virtualization 
> (VMWare, VirtualPC, etc.) to solve your problem.

Yeah, I've been thinking about that.

I have a laptop with a USB to serial adaptor, but the software 
stubbornly *refuses* to use it. If I were to set up a virtual machine, 
then the software would be unable to tell it's accessing a USB device; 
it would look like a native serial port.

OTOH, last time I tried to set up a virtual machine, it took two days 
just to install Windows XP and update to service pack 3. That's quite 
absurdly slow...

Post a reply to this message

On Thu, 13 Aug 2009 09:17:10 +0100, Invisible wrote:

> OTOH, last time I tried to set up a virtual machine, it took two days
> just to install Windows XP and update to service pack 3. That's quite
> absurdly slow...

You need better hardware.  It should never take that much time to install 
an OS - in my VMs, it never took that long....

What specs on the machine (including host OS)?

Post a reply to this message

Invisible wrote:
> OTOH, last time I tried to set up a virtual machine, it took two days
> just to install Windows XP and update to service pack 3. That's quite
> absurdly slow...

Was it VirtualBox 3.0 with multi-core (SMP) enabled?

When I tried that, it took several hours for Windows XP to install, on an
AMD 4200+ CPU. VBox SMP support still sucks.

Post a reply to this message

>> OTOH, last time I tried to set up a virtual machine, it took two days
>> just to install Windows XP and update to service pack 3. That's quite
>> absurdly slow...
> 
> You need better hardware.  It should never take that much time to install 
> an OS - in my VMs, it never took that long....
> 
> What specs on the machine (including host OS)?

 From memory, it was a 4 GHz Pentium IV with 512 MB RAM, running QEMU.

(The laptops I'm looking at using are this spec or worse.)

Post a reply to this message

On Fri, 14 Aug 2009 11:19:06 +0100, Invisible wrote:

>>> OTOH, last time I tried to set up a virtual machine, it took two days
>>> just to install Windows XP and update to service pack 3. That's quite
>>> absurdly slow...
>> 
>> You need better hardware.  It should never take that much time to
>> install an OS - in my VMs, it never took that long....
>> 
>> What specs on the machine (including host OS)?
> 
>  From memory, it was a 4 GHz Pentium IV with 512 MB RAM, running QEMU.
> 
> (The laptops I'm looking at using are this spec or worse.)

Memory would be the issue here, no wonder it took forever to install, it 
was probably swapping fiercely.

For good virtualization, you really need to have at least 1 or 2 GB of 
memory.  Insufficient host memory can lead to serious performance 
problems.

Jim

Post a reply to this message

>>>> OTOH, last time I tried to set up a virtual machine, it took two days
>>>> just to install Windows XP and update to service pack 3. That's quite
>>>> absurdly slow...
>>> You need better hardware.  It should never take that much time to
>>> install an OS - in my VMs, it never took that long....
>>>
>>> What specs on the machine (including host OS)?
>>  From memory, it was a 4 GHz Pentium IV with 512 MB RAM, running QEMU.
>>
>> (The laptops I'm looking at using are this spec or worse.)
> 
> Memory would be the issue here, no wonder it took forever to install, it 
> was probably swapping fiercely.
> 
> For good virtualization, you really need to have at least 1 or 2 GB of 
> memory.  Insufficient host memory can lead to serious performance 
> problems.

It didn't seem to be swapping *at all*. Hardly any HD activity. Just 
100% CPU, constantly.

I've heard people claim that the problem is QEMU - which is a user-mode 
hardware emulator rather than a virtualisation program that runs most 
code natively... but having never seen any other VM product, I don't 
know if it makes much difference.

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

Post a reply to this message

On Sat, 15 Aug 2009 07:13:56 +0100, Orchid XP v8 wrote:

>>>>> OTOH, last time I tried to set up a virtual machine, it took two
>>>>> days just to install Windows XP and update to service pack 3. That's
>>>>> quite absurdly slow...
>>>> You need better hardware.  It should never take that much time to
>>>> install an OS - in my VMs, it never took that long....
>>>>
>>>> What specs on the machine (including host OS)?
>>>  From memory, it was a 4 GHz Pentium IV with 512 MB RAM, running QEMU.
>>>
>>> (The laptops I'm looking at using are this spec or worse.)
>> 
>> Memory would be the issue here, no wonder it took forever to install,
>> it was probably swapping fiercely.
>> 
>> For good virtualization, you really need to have at least 1 or 2 GB of
>> memory.  Insufficient host memory can lead to serious performance
>> problems.
> 
> It didn't seem to be swapping *at all*. Hardly any HD activity. Just
> 100% CPU, constantly.

If for some reason the guest OS isn't relinquishing control to the host 
(which can happen), that also would explain it.  But if your host OS 
requires 256 MB to run and the guest requires 256 MB to run, there's no 
memory left for the actual virtualization software, so it has to get 
memory from somewhere.

512 MB is a fairly low spec for any system doing virtualization, 
regardless of the software.  My bet is still on memory.

> I've heard people claim that the problem is QEMU - which is a user-mode
> hardware emulator rather than a virtualisation program that runs most
> code natively... but having never seen any other VM product, I don't
> know if it makes much difference.

Grab VMware Server from http://www.vmware.com - it's free.  Not quite as 
easy to use as VMware Workstation, but WS is a pay-for product.

Jim

Post a reply to this message

> We have some equipment in our lab. It needs a computer to control it. 
> Unfortunately, the control software requires somebody to be logged in. As 
> soon as you log out, it quits the control program, halting the machine.

Can't you just lock the machine instead of logging off?

> Except that the control software stubbornly, repeatedly *refuses* to 
> believe me that the USB serial port actually exists. Every other piece of 
> software I've tried can access it without issue. But not the one piece of 
> software that we *need* to access it. No sir. Not interested. It can "see" 
> the port, but it refuses to *select* that port. And nothing I've done so 
> far seems to convince it to work.

OOC what COM port number is assigned to the USB COM port?  If it's higher 
than 4 then you might try changing it to 4 or below (you can usually do it 
from device manager under the properties of the USB-COM adapter).  Some 
older programs don't like working with things like COM7 which those USB 
converters typically come up as.

Post a reply to this message

>> We have some equipment in our lab. It needs a computer to control it. 
>> Unfortunately, the control software requires somebody to be logged in. 
>> As soon as you log out, it quits the control program, halting the 
>> machine.
> 
> Can't you just lock the machine instead of logging off?

The issue being that it is then impossible for anyone except the person 
logged on to discover if the machine is still running OK, how far it's 
got, etc.

If we used the other software, this problem would be 100% solved. The 
other software runs as a service, multiple people can access it, you can 
set up access controls and auditing... the whole nine yards. But the 
people at the top can't be bothered to put in the effort to test it, so 
we can't use it.

>> Except that the control software stubbornly, repeatedly *refuses* to 
>> believe me that the USB serial port actually exists. Every other piece 
>> of software I've tried can access it without issue. But not the one 
>> piece of software that we *need* to access it. No sir. Not interested. 
>> It can "see" the port, but it refuses to *select* that port. And 
>> nothing I've done so far seems to convince it to work.
> 
> OOC what COM port number is assigned to the USB COM port?  If it's 
> higher than 4 then you might try changing it to 4 or below (you can 
> usually do it from device manager under the properties of the USB-COM 
> adapter).  Some older programs don't like working with things like COM7 
> which those USB converters typically come up as.

Defaults to COM3. I've tried changing it to COM2 also. (COM1 is the 
built-in modem.)

However, today I obtained the latest version of the control software, 
and it now works perfectly with the USB adaptor. Go figure...

Post a reply to this message

>>> We have some equipment in our lab. It needs a computer to control it. 
>>> Unfortunately, the control software requires somebody to be logged in. 
>>> As soon as you log out, it quits the control program, halting the 
>>> machine.
>>
>> Can't you just lock the machine instead of logging off?
>
> The issue being that it is then impossible for anyone except the person 
> logged on to discover if the machine is still running OK, how far it's 
> got, etc.

Set up a "lab" user or some such that everyone knows the login for, we have 
that here to solve exactly that problem with our temperature logging 
software.  OOC, are normal applications required to carry on running if the 
user who started them logs off?  I have no idea.

Post a reply to this message

>>> Can't you just lock the machine instead of logging off?
>>
>> The issue being that it is then impossible for anyone except the 
>> person logged on to discover if the machine is still running OK, how 
>> far it's got, etc.
> 
> Set up a "lab" user or some such that everyone knows the login for

Then the *other* piece of software running on the computer wouldn't be 
able to log audit events under the correct username.

> OOC, are normal applications required to carry on 
> running if the user who started them logs off?  I have no idea.

Under Windows, any processes started by a user ordinarily get terminated 
when that user logs off. Unless they do something special to prevent this...

Post a reply to this message

> Then the *other* piece of software running on the computer wouldn't be 
> able to log audit events under the correct username.

Why not?  If it can log them under the correct username when nobody is 
logged on, why shouldn't it be able to do it when someone else is logged on?

> Under Windows, any processes started by a user ordinarily get terminated 
> when that user logs off. Unless they do something special to prevent 
> this...

Like what? Do most programs cope OK with running when nobody is logged on? 
I would have thought some get a bit screwed up what with there being no 
desktop or whatever.

Post a reply to this message

>> Then the *other* piece of software running on the computer wouldn't be 
>> able to log audit events under the correct username.
> 
> Why not?  If it can log them under the correct username when nobody is 
> logged on, why shouldn't it be able to do it when someone else is logged 
> on?

The program continues to run with nobody logged on, and continues to 
execute any instructions it has been given. However, to give it 
instructions, you have to log on, and it records the username of the 
person giving the instructions. If we had a single logon, there would be 
no record of who issued those instructions.

>> Under Windows, any processes started by a user ordinarily get 
>> terminated when that user logs off. Unless they do something special 
>> to prevent this...
> 
> Like what? Do most programs cope OK with running when nobody is logged 
> on? I would have thought some get a bit screwed up what with there being 
> no desktop or whatever.

No, I meant unless the *program* does something special to tell the OS 
it wants to keep running.

It sounds like the guys at HQ are looking at trying to run our problem 
software as a service somehow... We'll see if they can actually get it 
to work. (I rather suspect not.)

Post a reply to this message

> The program continues to run with nobody logged on, and continues to 
> execute any instructions it has been given. However, to give it 
> instructions, you have to log on, and it records the username of the 
> person giving the instructions. If we had a single logon, there would be 
> no record of who issued those instructions.

Just set it up so the program that you give commands to cannot be started as 
the lab user, and then do "Run As" the real user when you need to issue 
commands...

BTW I thought you could switch users on XP and Vista without the first 
user's programs being shut down.

Post a reply to this message

scott wrote:
>> The program continues to run with nobody logged on, and continues to 
>> execute any instructions it has been given. However, to give it 
>> instructions, you have to log on, and it records the username of the 
>> person giving the instructions. If we had a single logon, there would 
>> be no record of who issued those instructions.
> 
> Just set it up so the program that you give commands to cannot be 
> started as the lab user, and then do "Run As" the real user when you 
> need to issue commands...

That could work, I guess.

> BTW I thought you could switch users on XP and Vista without the first 
> user's programs being shut down.

Uh... yeah, possibly.

Post a reply to this message

Invisible wrote:
> Then the *other* piece of software running on the computer wouldn't be 
> able to log audit events under the correct username.

You do know you can have two people logged on at the same time, yes?

Start program one, lock the screen, log in as second user, start program 
two, lock the screen.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New wrote:
> You do know you can have two people logged on at the same time, yes?

Actually, that might be slightly harder with AD. You might have to log in 
remotely to have multiple accounts logged in at once.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

scott wrote:
> BTW I thought you could switch users on XP and Vista without the first
> user's programs being shut down.

In Windows XP, you cannot "switch users" like that if the computer is part
of a Windows domain. But it is supported since Vista.

Post a reply to this message

Nicolas Alvarez wrote:
> In Windows XP, you cannot "switch users" like that if the computer is part
> of a Windows domain. 

Is that true even if you log in remotely with RDP? I know we did that with 
Win2000, so I find it hard to believe XP can't?

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

>> In Windows XP, you cannot "switch users" like that if the computer is 
>> part
>> of a Windows domain. 
> 
> Is that true even if you log in remotely with RDP? I know we did that 
> with Win2000, so I find it hard to believe XP can't?

Windows XP Professional supports 1 user logging in via RDP (but only if 
nobody is logged in remotely). Windows 2003 Server supports multiple RDP 
sessions, but Windows XP supports only one at a time. As in, before 
anybody else can connect, you must disconnect (i.e., log out).

Post a reply to this message

Invisible wrote:
>>> In Windows XP, you cannot "switch users" like that if the computer is 
>>> part
>>> of a Windows domain. 
>>
>> Is that true even if you log in remotely with RDP? I know we did that 
>> with Win2000, so I find it hard to believe XP can't?
> 
> Windows XP Professional supports 1 user logging in via RDP (but only if 
> nobody is logged in remotely). Windows 2003 Server supports multiple RDP 
> sessions, but Windows XP supports only one at a time. As in, before 
> anybody else can connect, you must disconnect (i.e., log out).

Yes. Distinguish "logged in" from "connected". Just like you can only 
"switch users" on XP Pro by locking the screen, you can have multiple 
programs running concurrently under multiple user accounts by logging in 
remotely under different names and disconncting rather than logging out.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

>> Windows XP Professional supports 1 user logging in via RDP (but only 
>> if nobody is logged in remotely). Windows 2003 Server supports 
>> multiple RDP sessions, but Windows XP supports only one at a time. As 
>> in, before anybody else can connect, you must disconnect (i.e., log out).
> 
> Yes. Distinguish "logged in" from "connected". Just like you can only 
> "switch users" on XP Pro by locking the screen, you can have multiple 
> programs running concurrently under multiple user accounts by logging in 
> remotely under different names and disconncting rather than logging out.

It's an interesting theory. I don't think it works like that, but I 
don't have time to try right now.

(Of course, by default, only an administrator can log in via RDP in the 
first place...)

Post a reply to this message

Invisible wrote:
> It's an interesting theory. I don't think it works like that, but I 
> don't have time to try right now.

I can guarantee it works that way without AD.

> (Of course, by default, only an administrator can log in via RDP in the 
> first place...)

That's trivial to fix.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message