On 10/21/2011 1:09, Invisible wrote:
> I'd just feel kinda bad about making them go to all the trouble of
> interviewing me, going through a long elaborate selection process, finally
> getting a job offer, and then after all that saying "oh, you want me to work
> in London? OK, forget it, I'm not interested", and them being all like "WTF?
> Why did you even apply?!" I'd feel like I wasted everybody's time.

What if they said "We'll give you $150,000 more each year to move to London"?

> It's impossible to commute to London by car. (Well, no, it's theoretically
> possible, but you'd be insane to try.) More to the point, I absolutely hate
> London, so unless they're going to pay me 10x what I get now, it wouldn't be
> worth it.

Can it hurt to try? Trust me, you'd not be wasting anyone's time. If nothing 
else, if you're 100% dead set against setting foot in london, tell the 
interviewer that. I have no idea where all the offices are.

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

On Thu, 20 Oct 2011 10:18:07 +0100, Invisible wrote:

>>>> Or if you've got the yast http module installed, you can try yast2
>>>> http- server longhelp for command-line help.
>>>
>>> Which presumable again just tells you about command switches, not how
>>> to configure Apache using YaST.
>>
>> Try it.
> 
> Not easily feasible. I don't have access to a SUSE box right this
> minute.

Well, I did mean the next time the opportunity presents itself.

> Well, you know, that's what manpages do. They give you a terse reference
> to the bare essentials of what a tool does. That doesn't seem like much
> of an "assumption" to me.

I learned to script in bash using the manpage.  That's not exactly a 
terse one - again, hard to generalise about this kind of thing.

>> I accept that your experience has not been so good.  I'm telling you it
>> isn't always that way and that you could certainly try over in the
>> openSUSE forums when you have questions about openSUSE.
> 
> OK, well like I say, I'm about to try to set up a new OpenSUSE
> installation. If it doesn't work out, I'll give it a try.

That's all I'm saying. :)

>> Just like searching for a job - if you stop searching, nobody's ever
>> going to offer you something better.
> 
> Clearly I'm searching in the wrong places. You know, given that I never
> find anything worth even applying for... I still need to look at that,
> actually.

Well, I happen to be in a similar boat.  The trick is not to care about 
the offers you don't get (and yes, that is hard - I've had a couple 
places I really wanted to find work at that didn't work out for various 
reasons), but to get to the one that *does* offer it to you.

5 months and counting for me.  At least I've found some short-term 
contract work to do.

Jim

Post a reply to this message

On Fri, 21 Oct 2011 09:09:34 +0100, Invisible wrote:

> It's impossible to commute to London by car. (Well, no, it's
> theoretically possible, but you'd be insane to try.) More to the point,
> I absolutely hate London, so unless they're going to pay me 10x what I
> get now, it wouldn't be worth it.

I know perfectly sane people who have done (and IIRC currently do) 
exactly that.

Jim

Post a reply to this message

On Wed, 19 Oct 2011 21:48:38 -0700, Darren New wrote:

> On 10/19/2011 12:04, Jim Henderson wrote:
>> Well, sure, you'd have to put them someplace where IIS won't look at
>> it. With Apache, the same holds true - if you want to put it someplace
>> where Apache won't care, don't put it in /etc/apache2. :)
> 
> Does Apache load all configuration files in /etc/apache2? I thought
> there were like include directives or something.

Honestly I don't know - the newer versions use a conf.d directory that 
load everything with a .conf extension in that directory, regardless of 
name.  That seems to be becoming more common (indeed, I'm contracting to 
do some documentation for a company that's got daemons that are being 
converted to work in this manner).

Jim

Post a reply to this message

On Wed, 19 Oct 2011 21:08:19 -0700, Darren New wrote:

> On 10/19/2011 18:30, Jim Henderson wrote:
>> Oh, I see. :)  That's what I get for being overtired for the past week
> 
> Yeah, no problem. Lots of people *try* to turn conversations into
> debates. Certainly I'm not going to mind that you thought I was doing
> that. :-)

LOL

>> Ah, *that* thing.  I hadn't heard it called that, just heard about the
>> MS extensions being installed without the user being asked. :)
> 
> Yeah. It's their package manager for applications you install and update
> over the web. I'm honestly not sure why they felt the need to add
> support in firefox, but there you have it.

Probably to avoid accusations of acting in a non-competitive manner or 
something like that.

Jim

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> > Well, you know, that's what manpages do. They give you a terse reference
> > to the bare essentials of what a tool does. That doesn't seem like much
> > of an "assumption" to me.

> I learned to script in bash using the manpage.  That's not exactly a 
> terse one - again, hard to generalise about this kind of thing.

  Ever checked zsh's manpage(s)? It's actually divided into 16 man pages,
each dealing with a subset of the features, and most of them aren't exactly
short (for example the manpage for 'zshexpn' is over 1900 lines long).

-- 
                                                          - Warp

Post a reply to this message

On Thu, 20 Oct 2011 10:11:22 +0100, Invisible wrote:

>>> Either that or I just failed to get hired - again...
>>
>> That is a legitimate answer.  It isn't the only answer, though -
>> because one could ask people with more experience.  They could get in
>> touch with teammates who know the systems better, or with people they
>> know from other companies.  They could ask at a user group meeting (if
>> it's not a critical system-down issue, obviously - waiting until your
>> next LUG meeting isn't really good if the users can't work).
>>
>> Point is, there are many options.
> 
> I keep forgetting that other people actually work in teams.
> 
> If I were to ask someone from my team for a solution, their first answer
> would be "did you try rebooting it?", followed by "hold on, let me check
> Google..."

Which also is perfectly fine.  As I mentioned elsewhere, people tend now 
to learn how to find things rather than how to do things.

>> Yes, your experience varies from mine.  I'm telling you that it needn't
>> be that way.
> 
> Well, like I say, short of spending 10 years using Linux and seeing if
> anything is different this time, there's not really any way for me to
> verify your claim objectively. Either I believe you or I don't.

Well, if you don't believe me, then you're telling me my experience 
didn't happen.  So I'd suggest belief is the appropriate course of 
action. ;)

>> Now, did I waste my time?  You tell me.  Remember that it's beta and
>> the fix is in progress, though, before you answer that question.
> 
> Now, again, I wouldn't have even attempted to use a beta version in the
> first place. (But then, that's why they label it as beta. If you don't
> want the risk, you don't use it. If the risk is acceptable, you try it
> out...)

Right.

>> But if you're having difficulty with dependency resolution, you ask a
>> question about it and then perhaps someone builds the package for you.
> 
> I couldn't get anybody to tell me the command name to turn off the
> firewall [which would have taken then 3 to 4 seconds], and you expect
> that somebody is going to build a custom package just for me? [Which
> would presumably take several hours if not days.]

If it was openSUSE, then it's 

/etc/init.d/SuSEfirewall2_setup stop; /etc/init.d/SuSEfirewall2_init stop

And yes, if you had a package that wasn't in the standard repositories, 
malcolmlewis would likely build it for you using the build service, 
because it *doesn't* actually take hours/days to do so for someone versed 
in how OBS works.

> Can you see why I might be reluctant to believe this?

I can see that you might be reluctant to believe this, yes - but your 
stubbornness about it is approaching legendary levels.

>>> How do you know which part is the stack? How do you know which parts
>>> are code and which parts are data? How do you know where in the
>>> program the processor was executing?
>>
>> The debugger tells you those things, especially if you are in a live
>> kernel debugging session.
> 
> OK, so how the heck does the debugger know which chunk of unformatted
> data is the stack?

Various and sundry registers contain that information.  The debugger can 
ask the kernel for information about that - after all, the kernel *must* 
know these things in order to actually execute the program.

So finding these things out is a matter of asking the kernel what it 
knows about the running processes.

>>> You say "the format of a stack dump is known", except that... no, it
>>> isn't. The stack holds whatever arbitrary data the program decides to
>>> write to it. Without knowing how the program works, how can you get
>>> anything useful out of that?
>>
>> Well, yes, it is.  Because you have structural elements from the
>> software known to the debugger.
> 
> I don't follow. What do you mean by "structural elements"?

A program follows a certain structure.  When compiled, a program stores 
variable data in a certain space, code in a certain space, and the 
references to those addresses are all known to the kernel, and a debugger 
can learn them by asking the kernel.

>> A kernel debugger just gives you the tools to ask the CPU what it's
>> doing in a particular stack frame.
> 
> Wait - you mean the debugger can actually see what the processor is
> doing, not just what's in memory?

Yes.  A debugger can even execute instructions one by one (on the 
processor) to do single-step debugging.

> I can see how that might be possible for a live debugger session. (I
> mean, assuming the debugger can take over control of the CPU somehow.)
> I'm not sure how that would be possible for a raw memory dump.

You've used virtual machines and emulators, haven't you?  Similar 
principles are at play in a debugger.

>> You seem to be saying "it's a pain" and assuming that it's expected to
>> be that way.  There may actually be an underlying problem that needs to
>> be fixed that would make it less of a pain for you.  But you'd rather
>> complain, apparently, that it's a pain.
>>
>> That's what's frustrating me in this conversation.
> 
> Managing packages in Linux has *always* been a pain. It's gradually
> improved over the years, but sometimes it still falls down. What I can't
> figure out is why you seem to be denying that there's anything wrong
> with it.

Sometimes managing packages on Windows also falls down. <shrug>

I've not said "there's nothing wrong with it" - there's *always* room for 
improvement.  What I have said is "it's not as bad as you make it out to 
be", which is true.

>>> Every distro manages their stuff in a slightly different way. I seem
>>> to recall that if you installed POV-Ray under Debian, it used to
>>> insist on installing PVM, because the Debian POV-Ray package was a
>>> heavily modified PVM-patch of the official POV-Ray sources or
>>> something weird like that. (I presume this has been fixed now...)
>>
>> It may have been.  Or you could install povray from the sources or a
>> binary package here.  Then you get the latest version that Chris&  team
>> have put together, and you don't have to deal with the Debian
>> dependency issues.
> 
> I would have presumed that building POV-Ray from source would simply be
> intractably difficult. It would probably be simpler to find a binary
> package from somewhere else and try to convince that to install somehow.

Yeah, because nobody on the planet can build POV-Ray or any other 
software package.  Ever.  It's just impossible. *sigh*

> Regardless, hopefully Debian fixed this particular stupidity long ago.
> (I seem to recall POV-Ray doesn't comply with Debian's definition of
> "free" either, so it's in non-free or something...)

Right.  It's not GPL or under a OSI-approved license, which makes it "non-
free" according to the FSF.  I gather that's supposed to change in POV-
Ray 4.0, or it's planned to.

>> Sometimes that happens.  It depends on the severity of the bug and how
>> frequently it happens or is reported.
>>
>> A bug that one person once saw a couple years ago but nobody else has
>> reported an issue with isn't likely to get attention.
> 
> In fairness, looking back at the ticket, the actual issue was that
> such-and-such a package doesn't work properly on AMD64. The issue
> presumably was upstream (i.e., it isn't Gentoo's fault that SmartEiffel
> doesn't run correctly on AMD64). That probably doesn't help. Plus I
> doubt SmartEiffel is insanely popular.

Now you're understanding it.

>>> All I'm saying, people say "well it's open source, if you don't like
>>> it, you can fix it". Erm, no. No you can't. Unless you're very
>>> fortunate.
>>
>> You can always write a patch for the code you're running and submit it
>> upstream.
> 
>> So yes, you can fix it if you don't like it.
> 
> Not if you don't speak C you can't. :-P

You're missing the point, but I gather you know what I'm saying.

>>>> Which is why there's a community to help you out when you have
>>>> issues.
>>>
>>> In my experience, the "community" is absolutely useless.
>>
>> I can't see that you've asked any questions in the openSUSE or SUSE
>> communities about your upgrade woes.
> 
> I didn't mean any specific Linux community. I just offhandedly meant
> "every one that I've tried".

You've not tried the ones I'm in, and my experience in those communities 
has been quite good.

> Did you know I used to be a member of the local Linux User Group? Went
> to all the physical meetings and everything. I even brought my Amiga
> 1200 with me, running Debian "potato". I was rather surprised that this
> turned out to be *drastically* slower than AmigaOS. Like, it took 20
> minutes for GNOME to start. (!!)

So you were a member in what, 1957?  ;)

> The guys in the LUG were very friendly and everything. It's just that
> they never had the slightest clue how to fix my problems, or even where
> to start looking. Every suggestion I got from them always started with
> "man" followed by a command name...

So if you were a member of a LUG in 1957, it's possible, just possible, 
that things have changed since then.

Note that "1957" is actually facetious - I do know Linux is only 20 years 
old. ;)

>> Point is, if you use it and don't report the problem, unless someone
>> else has the issue and reports it, it's guaranteed not to get looked
>> at.
> 
> Again, if a video driver for a very common video card doesn't work, I
> would assume this has already been reported multiple times over.

But worth asking just in case it's a problem unique to your setup.  
That's why I asked.  If it wasn't reported, I would have reported it and 
provided information to help debug it.

As it happens, the bug has now been closed as fixed - so I get to try 
again this weekend if time permits. :)

>>> I don't suppose you happen to know of a distro that's particularly
>>> optimised for running in a VM?
>>
>> Depends on what you want to do with it.  Custom SUSE builds done in
>> Studio can be built as a VMDK or OVM (I think is the extension) format
>> for use in virtual environments.
> 
> I'm thinking more about the fact that if you do a default install of
> [any distro you care to mention], it installs power management
> utilities, firmware updates, scanner and webcame capture software, and
> all sorts of other hardware-related stuff which is simply useless on a
> VM. So first you have to wait for all this lot to download, and then you
> have to spend time uninstalling it again.
> 
> I'm just wondering if anybody has packaged up a set of stuff more
> appropriate to running a VM. But yeah, I guess it's going to vary
> depending on what you want the VM for...

Just like a real machine.  Check out Studio, lots of customisation 
options there.

> Some of the stuff written my MVPs is quite enlightening. For example, I
> once found [and will probably never find again] a website dedicated to
> MS Word glitches. It actually explains several interesting points which
> aren't mentioned in the documentation anywhere. Very useful stuff.

Yep.

> Replies to specific issues that I desperately want to fix tend to be
> less helpful. It seems the experts have no more idea what to try than I
> do. (Of course, with most of these things there's always the potential
> for the problem being some 3rd party software that a Microsoft expert
> isn't going to know anything about...)

I find it does depend on how one asks the question, too.

>> Of course, going in there and saying "this piece of crap just sucks and
>> doesn't work right" isn't likely to get you an answer, either.
> 
> Sure. But "this one specific printer doesn't print through Terminal
> Services" got me little to no replies either.

Then it might be worth generalising the question.  Try with a different 
kind of printer, if that doesn't work, then it's not that specific 
printer, but a more general issue.  If it does work, then it may be 
necessary to - instead of talking to Microsoft or MVPs about it - ask the 
printer manufacturer.

>>> So you've never had the package manager try to replace glibc and
>>> utterly break your install to the point where you have to replace the
>>> entire OS?
>>
>> Nope, I haven't.
> 
> That's pretty impressive.

I've only been doing Linux for 10-15 years or so. ;)

>>>> Well, it irritates several of us when you say "it's f-ing
>>>> impossible!@!!@! @!!" when in fact it's not, and you just haven't
>>>> asked for help.
>>>
>>> It irritates me when people say something is possible when it damned
>>> well isn't. :-P
>>
>> Except that it *is*, otherwise, how is it that millions of people use
>> Linux every single stinking day?
> 
> I didn't say it's impossible to use Linux. Heck *I* do that! I said in
> certain situations it's impossible to make the package manager do what
> you want.

And those millions of people using Linux don't use package management?  
No, actually, they do.  So we've come full circle.

>>> Like I said, when I ask, nobody helps.
>>
>> Come over to the openSUSE forums and ask for help when you're next
>> using openSUSE.  You'll *probably* be pleasantly surprised.
> 
> As it happens, I've just upgraded my work PC, and I was just about to
> set up a couple of Linux VMs. One of them will probably be OpenSUSE. I
> may or may not be able to get VMware Tools to work on it... so I may
> have to take you up on that one.

Feel free to.  There are some existing discussions over on 
forums.opensuse.org about using VMware and openSUSE together.

> (OTOH, I'm not looking forward to setting up yet *another* account on
> yet *another* forum... Like I don't have enough of those yet!)

One thing I've wanted to push for is using openID for authentication on 
OSF.  Not sure if vBulletin can support that, though - but if you post 
using NNTP, you'll find it's just a matter of pointing at 
forums.opensuse.org:119 and pulling a list of newsgroups.

>> It's like the old joke about playing the lottery - you have to play to
>> win.
> 
> Except that if you don't play, the probability of winning is zero, and
> if you do play, the probability of winning is so close to zero as to be
> effectively zero for all practical purposes.

Of course, that's why I added the bit that you didn't quote. ;)

> Can you tell why I don't play the lottery?

Same reason I don't.  Well, that, and there's no lottery in Utah. ;)

Jim

Post a reply to this message

On Fri, 21 Oct 2011 18:42:05 -0400, Warp wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> > Well, you know, that's what manpages do. They give you a terse
>> > reference to the bare essentials of what a tool does. That doesn't
>> > seem like much of an "assumption" to me.
> 
>> I learned to script in bash using the manpage.  That's not exactly a
>> terse one - again, hard to generalise about this kind of thing.
> 
>   Ever checked zsh's manpage(s)? It's actually divided into 16 man
>   pages,
> each dealing with a subset of the features, and most of them aren't
> exactly short (for example the manpage for 'zshexpn' is over 1900 lines
> long).

I haven't looked at it myself, but it doesn't surprise me that there are 
manpages that have a lot of documentation in them.

Jim

Post a reply to this message

On 10/21/2011 3:29 PM, Jim Henderson wrote:
> On Wed, 19 Oct 2011 21:08:19 -0700, Darren New wrote:
>
>> On 10/19/2011 18:30, Jim Henderson wrote:
>>> Oh, I see. :)  That's what I get for being overtired for the past week
>>
>> Yeah, no problem. Lots of people *try* to turn conversations into
>> debates. Certainly I'm not going to mind that you thought I was doing
>> that. :-)
>
> LOL
>
>>> Ah, *that* thing.  I hadn't heard it called that, just heard about the
>>> MS extensions being installed without the user being asked. :)
>>
>> Yeah. It's their package manager for applications you install and update
>> over the web. I'm honestly not sure why they felt the need to add
>> support in firefox, but there you have it.
>
> Probably to avoid accusations of acting in a non-competitive manner or
> something like that.
>
> Jim
Snort.. Yeah, which is I suppose why those things are usually "disabled" 
automatically by Firefox, as a) security threats, and b) prone to cause 
instability. lol

Post a reply to this message

>> Well, you know, that's what manpages do. They give you a terse reference
>> to the bare essentials of what a tool does. That doesn't seem like much
>> of an "assumption" to me.
>
> I learned to script in bash using the manpage.  That's not exactly a
> terse one - again, hard to generalise about this kind of thing.

 From what I recall, the manpage for Bash practically lists the entire 
BNF grammar for the scripting language. Great if you're trying to 
reimplement Bash for some reason, almost useless if you want to actually 
LEARN HOW TO USE IT.

A reference manual is no substitute for an introduction.

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

Post a reply to this message