Jim Henderson wrote:
> That would probably make more sense.  Or make it configurable via a GPO 
> but have the defaults be sane for the home user.

Actually, it's kind of weird to me that you can turn off the computer 
from a remote login without a UAC prompt, but you can't (say) change the 
clock.  Strange.

And it still takes two UAC prompts to change "advanced" power management 
settings. (Or maybe a different number if you're actually at the console 
and not logged in remotely? It's a bit weird, IIRC.)

>> Yah. You can do this just by logging in as administrator, for example.
>> Then you get no prompts at all.
> 
> On Vista? 

On my version, yes. Or go into Local Policies and set it up how you 
like. But on mine, by default, UAC is set to allow the actual 
"Administrator" account anything. (You have to actually turn on the 
ability to log in as administrator.)

Note I'm not talking "Member of the Administrators group", but the one 
actually called "Administrator".

> Right click the panel and select "Add to panel" - then filter to 
> "Menu".  :-)

Ah, thank you.  Yes, as I say, I probably could have solved it, but 
since the problem happened as I booted back from a full restore, I 
figured it was easier than actually trying to figure it out just then 
and there.

Vista, on the other hand, has apparently made it impossible to 
completely hide or reposition the task bar, or to pull toolbars off of 
it. Given how often I've seen someone want their start button in the top 
right corner vs how often I've seen it there, I can't fault this change. 
:-)


> I use the updater applet which is really clear.  

The thing in the "system tray" area? I never liked that. For one, it 
would take a long time every time you logged in to check for updates, 
preventing you from actually doing any package management or logging out 
cleanly or whatever. (As I said, probably fixed now that they don't suck 
down manifests every time.)

> thing is, Mono wasn't ready for prime time yet, 

This is a complaint? ;-)

> and using your updater app to showcase a new technology is just mind-
> bogglingly stupid IMNSHO) and replaced it with packagekit.  I've found 
> that to be MUCH better.

Cool. Maybe I'll turn it back on, when I get another job doing linux stuff.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> 
> I think I'm just f'ing unlucky. I seem to run into every weird problem
> that no other Linux user ever has trouble with. Must be my morphogenic
> field or something.
> 

I dare to challenge you with couple of really weird problems:

1) I have a Alphaserver ES40 as a toy. I installed Gentoo Linux on it
via very weird problem - keyboard didn't work on the local console. It
works on Debian's install CD, but not Gentoo's. I changed the kernel on
the install CD etc etc etc, but nothing helped. Eventually I created a
install-CD with DHCP client enabled, root passwd unscrambled and SSHD
enabled, so I could do the installation over the network.

2) I have Sun Netra X1, which I though I'd install as a firewall (it's a
cute 1U system, would make a nice firewall). I managed to install Gentoo
Linux on it, RAID-1 -setup etc. But after installing almost everything
and configuring the system I suddenly couldn't anymore copy files to
local disks over network. Scp, Rsync, simple cp from/to NFS, wget.. No,
just couldn't do it. I could transfer data nicely over network with no
problem to two directions, I could copy files from USB-stick to HD's,
but the path from NICs to HD just failed. No error, no reason, nothing -
the file just never appeared at the filesystem. I never actually solved
this.

-Aero

Post a reply to this message

On Mon, 17 Nov 2008 14:27:01 -0800, Darren New wrote:

> Jim Henderson wrote:
>> That would probably make more sense.  Or make it configurable via a GPO
>> but have the defaults be sane for the home user.
> 
> Actually, it's kind of weird to me that you can turn off the computer
> from a remote login without a UAC prompt, but you can't (say) change the
> clock.  Strange.
> 
> And it still takes two UAC prompts to change "advanced" power management
> settings. (Or maybe a different number if you're actually at the console
> and not logged in remotely? It's a bit weird, IIRC.)

That does seem unusual, yeah.  In both cases....

> 
>>> Yah. You can do this just by logging in as administrator, for example.
>>> Then you get no prompts at all.
>> 
>> On Vista?
> 
> On my version, yes. Or go into Local Policies and set it up how you
> like. But on mine, by default, UAC is set to allow the actual
> "Administrator" account anything. (You have to actually turn on the
> ability to log in as administrator.)

Ah, now I remember - I was logged in as the "owner" created during the 
OEM setup process, not as administrator.

> Note I'm not talking "Member of the Administrators group", but the one
> actually called "Administrator".

Yup.

>> Right click the panel and select "Add to panel" - then filter to
>> "Menu".  :-)
> 
> Ah, thank you.  Yes, as I say, I probably could have solved it, but
> since the problem happened as I booted back from a full restore, I
> figured it was easier than actually trying to figure it out just then
> and there.

Glad to help out. :-)

>> I use the updater applet which is really clear.
> 
> The thing in the "system tray" area? I never liked that. For one, it
> would take a long time every time you logged in to check for updates,
> preventing you from actually doing any package management or logging out
> cleanly or whatever. (As I said, probably fixed now that they don't suck
> down manifests every time.)

On 10.x it did take a long time to check for updates and would bury the 
processor as well.  My experience with it in 11.0 has been pretty good - 
I do wish they differentiated between a read-only access to the database, 
though, so you could launch package management while it was checking for 
updates.  It's a database, after all, it should be capable of allowing 
multiple processes to access it for read-only access.

>> thing is, Mono wasn't ready for prime time yet,
> 
> This is a complaint? ;-)

Well, like I said below:

>> and using your updater app to showcase a new technology is just mind-
>> bogglingly stupid IMNSHO) and replaced it with packagekit.  I've found
>> that to be MUCH better.
> 
> Cool. Maybe I'll turn it back on, when I get another job doing linux
> stuff.

Jim

Post a reply to this message

Jim Henderson wrote:
> On 10.x it did take a long time to check for updates and would bury the 
> processor as well.  My experience with it in 11.0 has been pretty good - 

Good to know.

> I do wish they differentiated between a read-only access to the database, 
> though, so you could launch package management while it was checking for 
> updates.  It's a database, after all, it should be capable of allowing
> multiple processes to access it for read-only access.

The linux file system isn't transactional, so you can't really work it 
that way. It isn't a database - it's a bunch of files, at least as I 
understand it.

>>> thing is, Mono wasn't ready for prime time yet,
>> This is a complaint? ;-)
> Well, like I said below:

That was unwarranted sarcasm, as in "isn't all of Linux not ready for 
prime time?" :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Wed, 19 Nov 2008 18:48:58 -0800, Darren New wrote:

> Jim Henderson wrote:
>> On 10.x it did take a long time to check for updates and would bury the
>> processor as well.  My experience with it in 11.0 has been pretty good
>> -
> 
> Good to know.
> 
>> I do wish they differentiated between a read-only access to the
>> database, though, so you could launch package management while it was
>> checking for updates.  It's a database, after all, it should be capable
>> of allowing multiple processes to access it for read-only access.
> 
> The linux file system isn't transactional, so you can't really work it
> that way. It isn't a database - it's a bunch of files, at least as I
> understand it.

Yes, but the information for RPM is stored in a database - or rather a 
series of databases - implemented using Berkeley DB (on my system, 
version 8).

>>>> thing is, Mono wasn't ready for prime time yet,
>>> This is a complaint? ;-)
>> Well, like I said below:
> 
> That was unwarranted sarcasm, as in "isn't all of Linux not ready for
> prime time?" :-)

Oh, I see.  Thhhhpt. ;-)

Jim

Post a reply to this message

Jim Henderson wrote:
> Yes, but the information for RPM is stored in a database - or rather a 
> series of databases - implemented using Berkeley DB (on my system, 
> version 8).

I guess if all the information you need to make that decision is stored 
in a transactional database, yah, you should be able to do that sort of 
thing. But then you wouldn't need a read-only version.

The problem with ACID is too many people stop too soon, thinking (for 
example) that "Consistent" means if the internal structure of the 
database storage isn't screwed up means that the database is consistent.

If you upgrade GCC from 2.3 to 2.4, and the /usr/bin/gcc file gets 
rewritten and then you crash out before committing the package manager, 
or you have permissions to write to libgcc and overwrite it but fail to 
upgrade /usr/bin/gcc properly, you have an inconsistency.

Out of curiousity, how do the package managers work when the packages 
are distributed over the network? If /usr/bin is a NFS mount, for 
example, does package management still work? Or are you back to 
tiptoeing around trying to figure out every file a package will touch? 
Can clients upgrade things, or do you have to try to lock it down at the 
NFS server?

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Fri, 21 Nov 2008 10:37:50 -0800, Darren New wrote:

> Jim Henderson wrote:
>> Yes, but the information for RPM is stored in a database - or rather a
>> series of databases - implemented using Berkeley DB (on my system,
>> version 8).
> 
> I guess if all the information you need to make that decision is stored
> in a transactional database, yah, you should be able to do that sort of
> thing. But then you wouldn't need a read-only version.
> 
> The problem with ACID is too many people stop too soon, thinking (for
> example) that "Consistent" means if the internal structure of the
> database storage isn't screwed up means that the database is consistent.
> 
> If you upgrade GCC from 2.3 to 2.4, and the /usr/bin/gcc file gets
> rewritten and then you crash out before committing the package manager,
> or you have permissions to write to libgcc and overwrite it but fail to
> upgrade /usr/bin/gcc properly, you have an inconsistency.

Yeah, and that sort of thing can happen - though the filesystem layer (on 
top of the actual filesystem at the kernel level - not sure what it's 
specifically called, probably some sort of abstraction layer) deals in 
inodes rather than files.  It's entirely possible to nuke a file that's 
open, along with its parent hierarchy; did that by mistake a few weeks 
ago when running pdfcrack before Eero suggested an alternative approach 
to my issue.  I even replaced the deleted directory with a second 
extracted copy of the source archive and a second copy of the PDF in 
question - but looking at the kernel level, the inodes are different.

> 
> Out of curiousity, how do the package managers work when the packages
> are distributed over the network? If /usr/bin is a NFS mount, for
> example, does package management still work? Or are you back to
> tiptoeing around trying to figure out every file a package will touch?
> Can clients upgrade things, or do you have to try to lock it down at the
> NFS server?

You know, I've never actually looked into that - I know in my Unix 
experience that mounting a remote /var partition wasn't uncommon, 
particularly with diskless workstations (obviously).  I may have to ask 
that question of some of the internal development folks.

Jim

Post a reply to this message

Jim Henderson wrote:
> Yeah, and that sort of thing can happen - though the filesystem layer (on 
> top of the actual filesystem at the kernel level - not sure what it's 
> specifically called, probably some sort of abstraction layer) deals in 
> inodes rather than files. 

I'm just saying that if you have (say) an executable and three related 
dynamically-linked .so files, or you have a .so and a .h file, there's 
no way in Linux to ensure that you can update them consistently, as far 
as I know. (I learn Linux tricks by telling people Linux can't do 
something, and then people correct me. ;-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

On Fri, 21 Nov 2008 13:40:49 -0800, Darren New wrote:

> Jim Henderson wrote:
>> Yeah, and that sort of thing can happen - though the filesystem layer
>> (on top of the actual filesystem at the kernel level - not sure what
>> it's specifically called, probably some sort of abstraction layer)
>> deals in inodes rather than files.
> 
> I'm just saying that if you have (say) an executable and three related
> dynamically-linked .so files, or you have a .so and a .h file, there's
> no way in Linux to ensure that you can update them consistently, as far
> as I know. (I learn Linux tricks by telling people Linux can't do
> something, and then people correct me. ;-)

I'm not quite sure what you mean by "ensure that you can update them 
consistently" - since a file that's open can be overwritten or deleted 
because of the nature of that filesystem abstraction layer, why would you 
not be able to update it consistently?

Jim

Post a reply to this message

Jim Henderson wrote:
> why would you not be able to update it consistently?

You write the .h file. While trying to write the .so file, you
A) don't have permissions to do so,
B) find that it's open by someone else as a shared text segment,
C) run out of disk space,
D) have your process killed,
E) have the power fail,
....

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message