Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 39

Thread: Linux is a cancer...

  1. #21
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,424
    One time i wrote a self-spawning program, and had like,
    100000 processes running or somthing crazy like that,
    and my box was fine. You can DOS your box, send the CPU
    to 100%, and still use it fine.
    I dare any of you to run 100000 processes on
    a windows box, haha, itd practically explode.
    Yeah, yeah, yeah... 100.000 processes? What system are you on? The Asci White? A Cray? I know what you mean, but can you please keep it a little more realistic? I'm pretty sure the number of processes you can run on any box depends on the processor, more than on the OS...

  2. #22
    Actually,
    The multitasking is controlled by the OS, not the processor. Hence making it the fault of the OS if resource exaustion occurs. The OS can deny resources to processes deemed redundant, while maintaining higher-priority processes such as a root prompt.


    -8trak

  3. #23
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,424
    I didn't say the multitasking is controlled by the processor, I said the number of processes you can run on any box depends on the processor, more than on the OS. What I meant by that is the simple fact that a faster processor gets more work done in the same time...

    And multitasking...
    Multitasking means that processes are carried out at the same time. That of course is not possible with only one processor. It may look like multitasking, but it isn't, I hope you can agree on that one. So if the OS wants to 'pretend' it's multitasking, it has to call in its processor management to tell the processor to switch between processes.
    WinNT uses pre-emptive switching, meaning one process being carried out is forced to leave the processor for another process. Unix also uses pre-emptive switching. This in condradiction to co-operative switching, where a process being carried out voluntary leaves the processor for another task (Win 9x, OS2).

    Then there's the problem of scheduling: which process first? There are two things that are desirable from a good scheduling system: make sure each process gets a share of the CPU and
    keep the CPU busy 100% of the time.

    Scheduling in DOS isn't even an option, since each process has to run to completion before another task can resume.

    A Windows 3.1 application can take out another task, but it can only bring down the other Windows 3.1 applications that are running. That's not that bad, but it could be better.

    Then there's the Windows 32-bit applications. They each run in their own protected memory space. No Windows 32-bit application can crash another because it does not have access to that other application's memory (of course, there are 'applications' that deliberately violate this). There's also the problem called 'trashing', meaning the system is using more CPU cycles to swap between processes rather than actually running those processes.

    And *nix? There's a scheduler that periodically looks at what processes are doing and adjusts the priority of those processes: the longer a process runs, the lower its priority becomes, and processes that have been denied the use of the CPU for a long time become priority.

    I agree with you when you say that it's the fault of the OS if resource exaustion occurs. Win32bit has its flaws, but so does *nix: *nix doesn't maintain processes because they have higher priority, it actually 'punishes' long-running processes. And that's its strength, I guess.


    Hehe, you made me stay up until 5 am, but that's ok: I actually learned something tonight!

  4. #24
    I believe ....and i am seldom wrong...if ever...that the maximum number of processes able to run on most if not all *nix boxes is 65,535.
    After that, without the patch to handle it, the system crashes. With the patch it still can only run 65,535 processes at any time.

  5. #25
    Alright,

    It was already established that i was exagerating when i said 100000 processes, i dont know why you would bring that up again.

    The fact of the matter is that It is much harder to cause a windows system to lock up, or become sluggish then it is to do the same to a linux box.

    Try using a DoS that works on any os, like any type of fragmentation re-assembly problem. On a windows box your mouse can freeze in place, while your mp3's continue playing for some retarded reason. There's priorities for ya!

    However, the same attack on a linux box, (assuming that it's not a total peice of trash) wont give the same effect.
    I tried just this, over a network, and found that while my windows box froze in place until the attack was halted, the linux side of the same computer was quite alright, the cpu utilization went to 100, and the drives seemed to be randomly seeking for some possibly un-related reason, but i remained quite in control of my box.

    -8trak

    P.S. The EDVAC that i used to do that test could run more then 66536 processes,
    haha, im only kidding for those of you that cant tell.

  6. #26
    Senior Member
    Join Date
    Sep 2001
    Posts
    412
    I generally avoid picking holes in other peoples statements, it usually serves no purpose, but i thought the number of processes on a linux box was limited by the task vector, which is, by default, set to 512.
    Is this not the case?

  7. #27
    Ah yes,

    Take a look at FAT!!!!
    Fat12, 16, 32, whatever one, i dont care!
    know why?! because they all suck!

    How often do you have to defrag your linux drive!?
    NEVER!!! why??! because EXT2FS is written properly!

    Windows is tied to a single company which could fail, look at Union Carbide!
    Linux doesnt have that problem!

    In windows, you cannot pipe data between the graphical programs. for example, tryto make windows find files starting with T, sort them chronologically and have it all done on wednesday morning at 3:00.
    Do it without writing a new program.

    In linux it would be rather easy by comparison.

    And Processes dont get punished by how long they have been running!!! They get punished by how long they have been idle!
    Which makes complete sence!

    Linux can be set up with routing! Enough said!

    Windows is restricted completely by legacy dos hardware emulation. Linux of course is not.

    Linux is open-source, this is just self-explanitory, it allows you to
    modify the operating system as you choose.

    Linux allows you to directly control the hardware, you can
    ls > /dev/dsp and your current directory will come out your speakers, this illustrates full control.

    You dont have to wait months and months for bug fixes, and you defiently wont have to pay for them with linux.

    And to the multiprocessing comment,

    Multitasking is defined as quickly switching between tasks to concurrently perform operations. It has nothing to do with the amount of processors.

    Multiprocessing has nothing to do with multitasking, infact, if your running 2 processes on a dual processor system, then your actually not multi-tasking, your multi processing.

    If you think that multitasking means that, then you must not understand how processors actually work.
    Processors have to run serially, they have no idea where the data is destined, they only know what order the processes lay in the stack.


    -8trak

  8. #28
    No, the 65536 task limit is a programming decision,
    only 16 bits are assigned to the PID,
    hence the problem.

    you should never want more tasks then that,



    -8trak

  9. #29
    Banned
    Join Date
    Aug 2001
    Location
    Yes
    Posts
    4,424
    Multitasking is defined as quickly switching between tasks to concurrently perform operations. It has nothing to do with the amount of processors.
    Guess the multitasking definition depends on the source you're quoting from. From your point of view, of course you're right... I've had lots of discussions about 'multitasking' on several newsgroups: lots of people agreed with me, lots of people agreed with you... But I can live with your point of view...

  10. #30
    I sourced that definiton from my head,
    but it appears that Webster.com, whatis.com, search solaris, and
    yes, this website's definition under hacker jargon say that multitasking is simply the process of performing multiple tasks at one given time.

    By your definition, you can only have as many concurrent tasks as you have processors, but there is a problem with this as well, because multiple processors multitask exactly the same as one processor does.

    Lets consider that having two processors is no different then having a single processor of twice the complexity. (this is not true in actuality, but only in theory) One processor performing a 64 bit calculation is EXACTLY the same as two processors makng two seperate 32 bit calculations. This only applies if code was actually compiled this way, but it makes sence to think this way because definitions of terms are completely theoretical as well.

    So what does it mean to have two processors?
    Do they have to be in seperate packages?
    I think not. In fact. I think it is completely accurate to say that
    a 8 bit 8088 is actually two 4 bit processors that happen to be connected in the same die and package.

    By this method of thinking, it cant be possible that two processors is required to multitask, because two processors is truly not different then 1 of double the bus width.

    Multitasking is simply the process of saving the state of the processor, and switching it between several other saved states to provide concurrent operation of un-related tasks.

    On a slightly un-realated but still interesting topic,
    It is because of this that having large amounts of cache no longer makes any sence, because during multi-tasking the stack is dumped, and hence, the entire cache is lost. Therefore, if the processor cannot completely empty it's cache before the tasks are switched, then you have more cache memory then makes sence, and will get no performance increase while multitasking.


    -8 trak

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •