Slashdot Mirror

← Back to Stories (view on slashdot.org)

Desktop FreeBSD Part 4: Printing

Posted by michael on from the in-the-beginning-was-the-teletype dept.

uninet writes "As a writer, the only reason Ed Hurst ever got his first computer was because it was far more efficient than a typewriter, and certainly more readable than his own handwriting. To enjoy that efficiency, however, you need a working printer, and Ed explores accomplishing just that with FreeBSD in this piece."

3 of 51 comments (clear)

  1. bad advice by Anonymous Coward · · Score: 5, Informative
    Right off the bat...

    life is much simpler if you login as root and run your desktop by typing startx at the command line

    Uh huh, run X as root. *PLONK*

    1. Re:bad advice by Homology · · Score: 5, Informative
      You run X as root regardless. It's SETUID.

      That depends. OpenBSD has patched XFree86 to make it more secure. Among things they have done is to use privilege separation for X, so not the entire X needs to run as root. They also made a ptm device that allows non-privileged processes to allocate a properly-permissioned pty, so the suid bit is removed from xterm and xconsole. Recently, OpenBSD made X work after enabling ProPolice for it, thus making buffer overflows less of a danger.

  2. Re:Does BSD have a pre-emptive kernel? by torstenvl · · Score: 3, Informative

    Yes, "BSD" has a pre-emptive kernel. BSD/OS has a pre-emptive kernel. BSDi was bought by Walnut Creek and they are providing a snapshot of their code to the FreeBSD team who is using some of the BSDi team's work to make their own kernel pre-emptive, as well. Please see "Revamping the BSD multiprocessor code" at http://www.daemonnews.org/200008/dadvocate.html

    You can also see a good argument against it, dating back to 2000 from Matt Dillon:
    "I would not characterize this as 'biting the bullet'. Having a preemptive kernel is unlikely to improve performance. The only reason there might be preemption at all is to deal wth interrupts. Interrupts currently preempt supervisor code. If interrupts are moved to interrupt threads then interrupt threads would need to be able to preempt supervisor code. In this fashion the supervisor thread would be preempted, but that is very different from having supervisor threads preempt other supervisor threads (something we probably will not do)."
    See http://docs.freebsd.org/cgi/getmsg.cgi?fetch=65989 +0+archive/2000/freebsd-arch/20000528.freebsd-arch

    Actually, the whole discussion is very interesting and I have learned a lot this morning about SMP and preemption and so on from reading. Thanks for bringing this up. :)