On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote:
On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki atte.peltom...@iki.fi wrote:
On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote:
Also, I am certain that the OpenRC developers would be thrilled if
FreeBSD adopted OpenRC.
Replacing rc(8) has a lot of risks and not many benefits. Current system
if you make single-use system (for eg. X11 terminal) just delete most of
files from /etc including /etc/rc and write your own - the simplest
possibe, just put command to run all needed things. that's all.
Hi all,
Summary of below. I have started an effort to get TeXLive into the FreeBSD
ports. See github.com/DragonSA/texlive for details. Volunteers welcome.
On Sunday, 17 June 2012 22:04:15 David Schultz wrote:
On Sun, Jun 17, 2012, Jan Henrik Sylvester wrote:
Even with a knob instead of
a lot of CPU or hardware compression. Decoding either takes a lot of CPU
(or hardware decoding which AFAIK FreeBSD doesn't have). You can use
watching SDTV movie takes very little part of one core of any modern CPU
including intel atom. encoding SDTV will take more but still not much.
OK, but I wanted to have most of the space of the 4 GB SSD encrypted
with geli(8); so I should make there some slice containing /boot
(unencrypted) and a second slice which later will contain my HOME and
encrypted; wrong?
right.
but do not forget bootloader requires things to be in /boot
On Sun, Jun 17, 2012 at 6:31 PM, Dieter BSD dieter...@engineer.com wrote:
[ Added multimedia@ as that is a more appropriate list than hackers ]
I just moved into a very cramped apartment
we are using a broadcast signal only [current US {NYC} standards]
Recording ATSC takes very little CPU.
On 18/06/2012 09:11, Atte Peltomäki wrote:
On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote:
On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki atte.peltom...@iki.fi
wrote:
On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote:
Also, I am certain that the OpenRC developers
user.vdr writes:
Recording doesn't require any compression unless you are transcoding
in real-time. There's no difference between recording ATSC, NTSC, PAL,
etc, and it's actually irrelevant what the stream is.
This is incorrect. ATSC is compressed before broadcast, so
you receive the data
This is a known issue, and had been around for a long time.
You can't reliably build 32 bit binaries (what the -m32 flag specifies)
on a 64 bit system. The header files (and possibly other things) are wrong.
People build 32 bit binaries on 64 bit systems all the time.
It is called
On 06/18/2012 01:12 PM, Vincent Hoffman wrote:
On 18/06/2012 09:11, Atte Peltomäki wrote:
On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote:
On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki atte.peltom...@iki.fi
wrote:
On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote:
where can i find description of field of files /proc/*/map
?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
On 06/17/12 19:43, Mike Meyer wrote:
Eric McCorklee...@shadowsun.net wrote:
The -m32 flag seems to be the culprit; removing it fixes the problem.
This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE
were wrong.
In any case, this is a pretty serious error, and someone
On Mon, Jun 18, 2012 at 10:21 AM, Dieter BSD dieter...@engineer.com wrote:
user.vdr writes:
Recording doesn't require any compression unless you are transcoding
in real-time. There's no difference between recording ATSC, NTSC, PAL,
etc, and it's actually irrelevant what the stream is.
This
Hi!
I am trying to continue the work started by DavidXu on implemention of fast
syscalls via sysenter/sysexit.
http://people.freebsd.org/~davidxu/sysenter/kernel/
I have ported it on FreeBSD9. It looks like it works. Unfortunately I am a
beginner in kernel so I have some questions:
1. see
On 6/18/12 10:31 PM, Wojciech Puchar wrote:
where can i find description of field of files /proc/*/map
?
Use procstat -v instead. All fields are documented in procstat(1).
--
Andrey Zonov
___
freebsd-hackers@freebsd.org mailing list
On Mon, 18 Jun 2012 13:42:27 -0500
Nathan Whitehorn nwhiteh...@freebsd.org wrote:
On 06/17/12 19:43, Mike Meyer wrote:
Eric McCorklee...@shadowsun.net wrote:
The -m32 flag seems to be the culprit; removing it fixes the problem.
This is why I was having problems, as the offsets in
It's unfortunate that this thread evolved into a discussion about
replacing rc.d, since that's almost certainly not relevant to the
original topic of improving the overall boot time.
If you analyze the boot process thoroughly you should see that out of
the total time taken to boot, nearly 0 is
As the original poster of this thread, I can also say that Doug is
correct. The issue is not rc, it is the actual kernel boot process.
Maybe I could see rc becoming an issue in a massive server environment
where there are a lot of userland processes to start, but that delay
would most likely
On 06/18/2012 06:53 PM, Doug Barton wrote:
It's unfortunate that this thread evolved into a discussion about
replacing rc.d, since that's almost certainly not relevant to the
original topic of improving the overall boot time.
If you analyze the boot process thoroughly you should see that out
replacing rc.d, since that's almost certainly not relevant to the
original topic of improving the overall boot time.
indeed.
If you analyze the boot process thoroughly you should see that out of
the total time taken to boot, nearly 0 is spent by rc.d actually doing
something. Almost all of
that is what i need.
but still need some explanation after using it and reading manual
say:
PID STARTEND PRT RES PRES REF SHD FL TP PATH
1378 0x40 0x5ac000 r-x 385 415 2 1 CN- vn
/usr/local/bin/Xorg
1378 0x7ab000
On Tue, Jun 19, 2012 at 6:39 AM, Wojciech Puchar
woj...@wojtek.tensor.gdynia.pl wrote:
replacing rc.d, since that's almost certainly not relevant to the
original topic of improving the overall boot time.
indeed.
If you analyze the boot process thoroughly you should see that out of
the
22 matches
Mail list logo