On 12-10-2011 8:03, Patrick Elliott wrote:
[snip]

> All I want is something to build meshes in, and has as many bloody ways
> to do that as possible, without all the other stuff getting in the way.
> Apparently, I am on the wrong planet to find that. lol

The only thing I use Blender for is to build meshes. That works great 
for me. My alternative would be something like Maya, but that has an 
even more complicated interface (from a GUI point of view).
In the next few weeks I will use it too to make meshes, so I'll keep you 
posted on the progress.

-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

On 12-10-2011 7:54, Patrick Elliott wrote:
> On 10/11/2011 12:01 PM, Orchid XP v8 wrote:
>>>> a product that you already have lying around and try to sell it to a
>>>> completely different audience...
>>>
>>> You'll notice that Blender is free, right?
>>
>> Sure. That doesn't mean it's well designed. ;-)
>>
> Often, if its like the first 10... or so versions after the "in house"
> version, its pretty much a given that it *won't be* well designed.
> Though, as the poor bastard that has to figure it out, and doesn't have
> the original company to "help them" do that, design isn't necessarily
> the problem so much as an inordinate need to know what drugs they where
> taking when they wrote it, so you can inform the local equivalent of the
> ATF, so they can keep an eye out for it on the streets.

I have used both the pre 2.5 versions and the post 2.5 versions (that is 
really completely redesigned) and although I know this common complaint 
I cannot confirm it.

-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

On 10/12/2011 13:31, andrel wrote:
> That is what 'surprises' me everytime. How can you design an OS where it is
> possible to prevent a task switch to a taskmanager. I assume it is because
> it wasn't designed but grown. Still, by now they should have solved that, I
> would assume.

It's really not too hard. Modern desktop OSes suck at scheduling disk I/O, 
so if you're locked up because of disk I/O and you launch a new program, 
you're going to be locked up.

Sit down at a Linux machine with 16G of RAM. Create a directory with 
1,000,000 one-block files, then type "sync", then type "rm -r xyz;sync" and 
watch Linux "lock up" for several minutes as anything that wants to touch 
the disk waits for the sync to finish.

Same thing can happen if you have a whole ton of data paged out when you 
terminate the application, as AFAICT both Windows and Linux will happily 
page everything back in as it terminates the job.

> BTW this is when reading a 1-2 million faces text file in into Blender. And
> when going into edit mode after that and...

Disk I/O sucks in every modern desktop OS. Android also "locks up" on 
occastion for several seconds at a time, as some random program launches a 
check for something online when you're in the middle of typing something, 
for example.

Contrast with CP/V, a mainframe OS from the late 1960s, that ran on a 
computer with *maybe* a 500KHz CPU running out of 256K of magnetic core that 
happily supported 40 or 50 users before you started to notice any slow-down. 
How? They had something like 30 or 40 different priority bumps depending on 
what you were waiting for and what woke you up. Waking up from waiting for 
free memory (i.e., someone else's page-out completing) vs waking up from 
waiting for pages to page in vs waking up from waiting for a directory entry 
to come from disk vs waking up when disk data has arrived vs etc all had 
different priority bumps, including on whether you're in core, out of core, 
finished your quantum last time, waited before your min-quantum expired last 
time, etc etc etc.

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

Post a reply to this message

On 12/10/2011 05:17 PM, Darren New wrote:
> On 10/12/2011 1:13, Invisible wrote:
>> Now given that the Amiga is a home computer, how
>> many homes have a VT100 just laying around?
>
> The VT100 is not the only serial terminal. Anything that talks RS232
> serial is sufficient. You know, like, another Amiga, say?

Oh, OK.

So what can you actually do with a "kernel debugger", anyway? Just look 
around the machine's memory or something?

Post a reply to this message

On 12/10/2011 05:19 PM, Darren New wrote:
> On 10/12/2011 1:27, Invisible wrote:
>> The "secret" part being that they didn't warn anybody "hey, we've
>> implemented a new feature to completely disable the security of your
>> network".
>
> It's no more disabling the security of your network than telnet or pop3
> or http is. You have to tunnel out before you can get any answers back.

OK. So how is my statement that "you cannot log in to it from outside 
the building" invalidated then?

Post a reply to this message

On 13/10/2011 12:47 AM, Darren New wrote:

> Same thing can happen if you have a whole ton of data paged out when you
> terminate the application, as AFAICT both Windows and Linux will happily
> page everything back in as it terminates the job.

What I can't figure out is why no matter how many billion bytes of 
physical RAM you have, Windows seems to swap stuff out to disk, even if 
it isn't short of physical memory. Like, if you start up Windows, open a 
few applications, walk away, and come back four hours later, as soon as 
you touch anything, it starts desperately paging all the data back into 
memory.

Um, why did it page it *out* in the first place?! I thought it was only 
supposed to swap stuff out if the space was needed for something else?

Post a reply to this message

Le 13/10/2011 10:21, Invisible a écrit :
> On 12/10/2011 05:19 PM, Darren New wrote:
>> On 10/12/2011 1:27, Invisible wrote:
>>> The "secret" part being that they didn't warn anybody "hey, we've
>>> implemented a new feature to completely disable the security of your
>>> network".
>>
>> It's no more disabling the security of your network than telnet or pop3
>> or http is. You have to tunnel out before you can get any answers back.
> 
> OK. So how is my statement that "you cannot log in to it from outside
> the building" invalidated then?

Because you assume that the firewall/Nat will protect you for that purpose.
Local teredo will send packets from inside to the outside, using UDP...
and most firewall/Nat will track that as "open a temporary route for the
UDP answer". Ergo, you will be exposed.
The nice thing, is that you are not aware that teredo might or might not
send some packets... whereas usually for telnet, you asked for the
application and the connection.

Of course, you can argue that your firewall setting is using the
explicit whitelist only approach. But usually, that does not work.
you often need whitelist + tracking of outgoing connection... and there,
you're stuck with teredo.

Have a nice day.

-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

On 13-10-2011 1:47, Darren New wrote:
> On 10/12/2011 13:31, andrel wrote:
>> That is what 'surprises' me everytime. How can you design an OS where
>> it is
>> possible to prevent a task switch to a taskmanager. I assume it is
>> because
>> it wasn't designed but grown. Still, by now they should have solved
>> that, I
>> would assume.
>
> It's really not too hard. Modern desktop OSes suck at scheduling disk
> I/O, so if you're locked up because of disk I/O and you launch a new
> program, you're going to be locked up.

Might be, but why design it this way? Why has cntrl-alt-del not a higher 
priority than disk-IO and indeed any other program/process? (and on 
really modern machines: why not dedicate one core to the OS and the OS 
alone?)

>
> Sit down at a Linux machine with 16G of RAM. Create a directory with
> 1,000,000 one-block files, then type "sync", then type "rm -r xyz;sync"
> and watch Linux "lock up" for several minutes as anything that wants to
> touch the disk waits for the sync to finish.
>
> Same thing can happen if you have a whole ton of data paged out when you
> terminate the application, as AFAICT both Windows and Linux will happily
> page everything back in as it terminates the job.
>
>> BTW this is when reading a 1-2 million faces text file in into
>> Blender. And
>> when going into edit mode after that and...
>
> Disk I/O sucks in every modern desktop OS. Android also "locks up" on
> occastion for several seconds at a time, as some random program launches
> a check for something online when you're in the middle of typing
> something, for example.
>
> Contrast with CP/V, a mainframe OS from the late 1960s, that ran on a
> computer with *maybe* a 500KHz CPU running out of 256K of magnetic core
> that happily supported 40 or 50 users before you started to notice any
> slow-down. How? They had something like 30 or 40 different priority
> bumps depending on what you were waiting for and what woke you up.
> Waking up from waiting for free memory (i.e., someone else's page-out
> completing) vs waking up from waiting for pages to page in vs waking up
> from waiting for a directory entry to come from disk vs waking up when
> disk data has arrived vs etc all had different priority bumps, including
> on whether you're in core, out of core, finished your quantum last time,
> waited before your min-quantum expired last time, etc etc etc.

IIRC also the Amiga did not suffer from virtual lock up (nor do I 
remember it so badly from earlier version of MS-DOS).


-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message

On 10/13/2011 1:28, Invisible wrote:
> Um, why did it page it *out* in the first place?! I thought it was only
> supposed to swap stuff out if the space was needed for something else?

Other stuff, like Windows Update or disk defragger, might have run in the 
background. Note that processes like Superfetch are supposed to minimize 
this effect. (I saw an interesting lecture on the changes they'd made to 
prevent "back from lunch syndrome.")

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

Post a reply to this message

On 10/13/2011 9:12, andrel wrote:
> Might be, but why design it this way? Why has cntrl-alt-del not a higher
> priority than disk-IO and indeed any other program/process?

Sure, but what's it going to do when it gets that keystroke? It has to fire 
up the code that handles it, presents the UI, etc.  *That* is what takes 
time to page in.

> modern machines: why not dedicate one core to the OS and the OS alone?)

The core isn't the problem. The disk is the problem, because rescheduling 
disk is slow. You can interrupt the CPU in a few hundred machine cycles. You 
can't really interrupt a disk seek.

Indeed, I suspect if Windows figured out your startup programs, figured out 
that you actually have more than enough RAM to load them all, and would just 
load the entire file sequentially instead of letting them page in on demand, 
you'd cut boot time tremendously.

> IIRC also the Amiga did not suffer from virtual lock up (nor do I remember
> it so badly from earlier version of MS-DOS).

The Amiga didn't have demand paging, so you only suffered a long shut-down 
time when you had allocated a lot of small chunks of memory and needed to 
deallocate them before exiting. That happened on occasion.

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

Post a reply to this message