POV-Ray : Newsgroups : povray.off-topic : Adventures with digital painting Server Time
15 Nov 2024 06:16:30 EST (-0500)
  Adventures with digital painting (Message 111 to 120 of 197)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Jim Henderson
Subject: Re: Adventures with digital painting
Date: 11 Mar 2008 10:12:56
Message: <47d6a178$1@news.povray.org>
On Tue, 11 Mar 2008 09:24:29 +0000, Invisible wrote:

>>> Difference is, all the little bits and pieces that make up Windoze all
>>> come from one manufacturer, there's only one version of them, and
>>> they're all extensively tested together.
>>>
>>> Linux, OTOH... You don't often find two machines set up exactly the
>>> same way. And all the individual parts are from different people, and
>>> there are a myriad of possible versions and implementations.
>> 
>> You need to look at how the software checkins and testing are handled
>> for the kernel.
> 
> Who said anything about the kernel? I'm talking about the entire Linux
> OS. (Most of which is actually GNU, if you want to be technical about
> it...)

So yes, be technical about it, then - I don't know of any Linux distro 
that uses "standard" tools that aren't GNU, be it awk, sed, perl, bash, 
etc.

>> And you need to look up again the definition of "DLL Hell".
>> 
>> Not so different as you might think.
> 
> I have yet to experience "DLL Hell". I'm told it exists, and it's not
> fun, but I haven't seen it personally. (Don't ask me why...)

You've been lucky.  Last company I worked for had many applications with 
DLLs in common but requiring different versions.  We had a team of 
software deployment engineers who did testing to ensure the software 
would all work together and work around the issues of needing multiple 
versions of the same DLL.

Jim


Post a reply to this message

From: Invisible
Subject: Re: Adventures with digital painting
Date: 11 Mar 2008 10:34:29
Message: <47d6a685$1@news.povray.org>
>> Who said anything about the kernel? I'm talking about the entire Linux
>> OS. (Most of which is actually GNU, if you want to be technical about
>> it...)
> 
> So yes, be technical about it, then - I don't know of any Linux distro 
> that uses "standard" tools that aren't GNU, be it awk, sed, perl, bash, 
> etc.

Except that Unix /= Linux. There's also BSD and Solaris and random stuff 
like that... and autoconf works with all of them.

"Windoze" is more or less one product line. Binaries work unmodified on 
most versions of it. (Assuming the features they use are there.) "Unix" 
is not one product. It's not even close to being one product. It's a 
vast stew of different products all bolted together in a giant mess.

>> I have yet to experience "DLL Hell". I'm told it exists, and it's not
>> fun, but I haven't seen it personally. (Don't ask me why...)
> 
> You've been lucky.

Let's hope it stays that way...

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


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: Adventures with digital painting
Date: 11 Mar 2008 10:42:34
Message: <47d6a86a$1@news.povray.org>
Invisible escribió:
>>> Who said anything about the kernel? I'm talking about the entire Linux
>>> OS. (Most of which is actually GNU, if you want to be technical about
>>> it...)
>>
>> So yes, be technical about it, then - I don't know of any Linux distro 
>> that uses "standard" tools that aren't GNU, be it awk, sed, perl, 
>> bash, etc.
> 
> Except that Unix /= Linux. There's also BSD and Solaris and random stuff 
> like that... and autoconf works with all of them.
> 
> "Windoze" is more or less one product line. Binaries work unmodified on 
> most versions of it. (Assuming the features they use are there.) "Unix" 
> is not one product. It's not even close to being one product. It's a 
> vast stew of different products all bolted together in a giant mess.

I'm not sure if it's possible to put a non-GNU userland (like BSD) along 
with a Linux kernel, but it's definitely possible to have GNU userland 
on many kernels, like BSD.

Heck, the "BSD Subsystem" package for my iPod was based in BSD (duh), I 
removed it and installed Telesphoreo (much better package of unix tools) 
and it's based on GNU tools. Kernel is Mach for ARM processor. I have 
yet to try autoconf stuff there :) (somebody is struggling to get a 
native compiler working)


Post a reply to this message

From: Darren New
Subject: Re: Adventures with digital painting
Date: 11 Mar 2008 13:08:24
Message: <47d6ca98@news.povray.org>
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> In other words, if you completely bypass the shell, it can be made easy 
>> to work. Otherwise you get things like "no such user John.tmp" when you 
>> try to delete "~John.tmp".
> 
>   Only if you write "~John.tmp" by hand instead of letting the shell do
> the proper expansion.

Or if you pass it through another program that also tries to do the 
expansion. I.e., if it goes thru the shell more than once.

>   Well, if "rm *" works (ie. there aren't too many files), you don't.
> If there are too many files, I suppose you'll have to use the 'find'
> trick.

Yep. Then it gets very slow, or very complicated.

>   If you do a "scp *" it won't ask the password for each one.

Again, I tend to work with tens of thousands of files at once.

>> , so you either have to use xargs (with the -0 
>> switch, which is why that's there!) or manage to tar them up somehow, 
>> which has the same problems.
> 
>   What's the problem with tarring them? "tar -cvf . files.tar"

If you want to select a subset of files to tar up, then it becomes very 
difficult.

> However, I haven't seen any problems with special characters so far.

Well, clearly we work on different kinds of things. And yes, shells have 
gotten way better lately, but if you wind up doing multiple passes 
through a shell (i.e., a shell script looping and calling another shell 
script) it gets messy.

>   The only valid point you have presented is the too-many-files argument,

See above. If you have a shell script to process something, it takes 
magic escaping.

Explain the "-0" argument to find and xargs if it isn't otherwise a problem?

>> Having the shell doing your expansion has caught me other times, too...
> 
>> % cat a b c >d
>> Can't create d: permission denied
>> % sudo !!
>> Can't create d: permission denied
> 
>> Of course, the real line was much longer, so a simple "su" meant 
>> retyping the line (or using copy-and-paste to retype it for you) instead 
>> of just !! or up-arrow. :-)
> 
>   What's wrong with getting the command from the command history with
> the up cursor, going to the beginning of the line with ctrl-a and then
> adding the "sudo" there?

Because it still doesn't work. SUDO doesn't kick in until after the 
output redirection is done, so "sudo echo xyz >pdq" doesn't overwrite pdq.

>   Still many shell scripts fail to use the basic "$@" for the correct
> expansion of all the parameters (and instead use $*, which is wrong).

That too. And it still doesn't work when there are too many files.  I'm 
not really sure why it's even limited, given I've got 16 gig of real 
memory and twice that of virtual memory. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."


Post a reply to this message

From: Darren New
Subject: Re: Adventures with digital painting
Date: 11 Mar 2008 13:11:19
Message: <47d6cb47@news.povray.org>
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> (I work with big directories, and big files. Often I'll have a program 
>> that runs 3 hours, then takes half an hour to delete its input files. Or 
>> individual files that take 2 minutes of disk I/O to delete. Or empty 
>> directories that take several minutes to delete because they used to 
>> have six or seven million files in em.  And of course, the machine 
>> becomes completely unusable during any sort of operation like that.)
> 
>   Isn't that a clear sign that a re-design of your programs is in place?-)

Probably not. I don't know any other way of storing several weeks worth 
of CD-quality audio in a way that is easy to extract portions, then 
delete the beginning without affecting the end.

Now, if Linux supported the thing that NTFS supports where you can 
delete the beginning of a file, maybe I'd use that. But as it is, I have 
to chop the file up so I can delete parts of it.

Plus, of course, the device buffers on the audio device get upset if you 
tell it to try to accumulate a gig of audio data before handing it over 
to your software. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."


Post a reply to this message

From: Darren New
Subject: Re: Adventures with digital painting
Date: 11 Mar 2008 13:11:59
Message: <47d6cb6f$1@news.povray.org>
Jim Henderson wrote:
> But if I wanted it to work all the time, I'd write it in C and be done 
> with it - then the shell doesn't come into play. :-)

Yah, as I said, when it gets messy, I use Tcl. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."


Post a reply to this message

From: Darren New
Subject: Re: Adventures with digital painting
Date: 11 Mar 2008 13:12:30
Message: <47d6cb8e$1@news.povray.org>
Nicolas Alvarez wrote:
> Jim Henderson escribió:
>> But if I wanted it to work all the time, I'd write it in C and be done 
>> with it - then the shell doesn't come into play. :-)
> 
> Can filenames have null characters on them? :)

No. The only thing Linux (and most other unix) filesystems disallows is 
slash and NUL.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."


Post a reply to this message

From: Darren New
Subject: Re: Adventures with digital painting
Date: 11 Mar 2008 13:16:55
Message: <47d6cc97$1@news.povray.org>
Invisible wrote:
> The trouble with Windoze is that *everything* is one gigantic lump. (And 
> it's a very buggy, undocumented and unreliable lump at that.)

No, it's just a bunch of tightly-coupled pieces you have to be a 
programmer to get at. Instead of using files to pass around data, 
windows uses APIs. And it isn't especially undocumented. It just costs 
money to go to the classes that teach you the stuff properly, and there 
isn't source code available.

It's not like IIS is less documented than Apache, or the Windows 
graphics stuff is less documented than X-Windows.

> Why can't somebody build an OS with a *sane* level of granularity?? What 
> would be so hard about that?

Because one size doesn't fit all?

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."


Post a reply to this message

From: Darren New
Subject: Re: Adventures with digital painting
Date: 11 Mar 2008 13:33:41
Message: <47d6d085$1@news.povray.org>
Jim Henderson wrote:
> chkdsk

It's actually not even chkdsk at boot time. It's autochk, which is a 
different program to do the same thing. And the recovery console has yet 
a different version. Why they felt the need to implement it three times 
I don't understand. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."


Post a reply to this message

From: Jim Henderson
Subject: Re: Adventures with digital painting
Date: 11 Mar 2008 13:38:59
Message: <47d6d1c3$1@news.povray.org>
On Tue, 11 Mar 2008 11:11:59 -0700, Darren New wrote:

> Jim Henderson wrote:
>> But if I wanted it to work all the time, I'd write it in C and be done
>> with it - then the shell doesn't come into play. :-)
> 
> Yah, as I said, when it gets messy, I use Tcl. :-)

Really the best option - remove the shell. :-)

Jim


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.