Re: Call For Testers: Synaptics touchpads
Le 08/04/2015 09:19, Rui Paulo a écrit : Hi, The attached patch adds support for newer touchpad features and implements two finger scrolling. This is such a common feature these days that I think we should enable it by default and disable edge scrolling. I've implemented some detection code to keep edge scrolling enabled when the touchpad has a dedicated area for scrolling. Thank you very much, I always wondered why this was not supported in FreeBSD. I also wonder if it will be tunable with the appropriate GNOME/KDE (or just the synclient tool) settings to disable this two-finger scroll at runtime. Please test it and report back your experience. To enable synaptics support, you need: hw.psm.synaptics_support=1 I strongly suggest to enable this by default, it will prevent lot of users having headaches seeking why their touchpads do not work by default. We also added sound support by default, why not the touchpad ? :-). David. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: msk0 watchdog timeout Marvel 88E8071
Le 21/02/2015 23:46, Roosevelt Littleton a écrit : My msk0 is not even functional and my wifi is my only usable connection to the internet. I have this in my loader.conf: hw.msk.msi_disable=1 hw.pci.enable_msix=0 and this in my sysctl.conf net.inet.tcp.tso=0 vmstat -i interrupt total rate irq1: atkbd0 552 1 irq9: acpi0 2561 3 irq12: psm0 2322 3 irq16: mskc0 2104711 2572 irq20: hpet0 uhci0* 133497163 irq256: vgapci0 970 1 irq257: hdac0 7680 9 irq259: ahci0:ch0526 1 irq260: ahci0:ch1 100128122 irq264: ahci0:ch5 1739 2 Total2354686 2878 dmesg Copyright (c) 1992-2015 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r279013: Thu Feb 19 22:30:02 EST 2015 root@Mizraim:/usr/obj/usr/src/sys/ZENNLA amd64 FreeBSD clang version 3.5.1 (tags/RELEASE_351/final 225668) 20150115 VT: running with driver "vga". module_register: module pci/mskc already exists! Module pci/mskc failed to register: 17 module_register: module mskc/msk already exists! Module mskc/msk failed to register: 17 module_register: module msk/miibus already exists! Module msk/miibus failed to register: 17 CPU: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz (2261.05-MHz K8-class CPU) Origin="GenuineIntel" Id=0x10676 Family=0x6 Model=0x17 Stepping=6 Features=0xbfebfbff Features2=0x8e3fd AMD Features=0x20100800 AMD Features2=0x1 VT-x: HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4076457984 (3887 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0x80e77bc0, 0) error 19 netmap: loaded module random: SOFT: yarrow init() random: selecting highest priority adaptor vtvga0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x207f mem 0xf200-0xf2ff,0xd000-0xdfff,0xf000-0xf1ff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io vgapci0: Boot video device uhci0: port 0x1800-0x181f irq 20 at device 26.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 20 at device 26.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 20 at device 26.2 on pci0 usbus2 on uhci2 ehci0: mem 0xf3504800-0xf3504bff irq 20 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 hdac0: mem 0xf350-0xf3503fff irq 21 at device 27.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 mskc0: port 0x3000-0x30ff mem 0xf300-0xf3003fff irq 16 at device 0.0 on pci2 msk0: on mskc0 msk0: Using defaults for TSO: 65518/35/2048 msk0: Ethernet address: 00:1d:72:ed:56:80 miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci4: on pcib4 iwn0: mem 0xf310-0xf3101fff irq 18 at device 0.0 on pci4 pcib5: irq 16 at device 28.4 on pci0 pci5: on pcib5 uhci3: port 0x1860-0x187f irq 23 at device 29.0 on pci0 usbus4 on uhci3 uhci4: port 0x1880-0x189f irq 17 at device 29.1 on pci0 usbus5 on uhci4 uhci5: port 0x18a0-0x18bf irq 18 at device 29.2 on pci0 usbus6 on uhci5 ehci1: mem 0xf3504c00-0xf3504fff
Re: Questions and *little* bugs in new vt(9)
On 08/05/2014 17:09, Ed Maste wrote: On 8 May 2014 04:16, David Demelier wrote: Hi there, I'm currently trying vt(9) on a CURRENT kernel (only the kernel not the base). I have very small bugs, not really serious. I'm currently using the radeon KMS driver. * When I switch from a tty to X I can see the mouse appearing but the tty is still displayed until I move the mouse. Or until I wait something like 3 seconds. It sounds like a small refresh trouble. Interesting. On my stable/9 desktop with i915kms I can't reproduce this; after switching back to X the previous display is restored, and then a redraw happens, within a few hundred mS. I do see it on my laptop, which also has i915kms but newer software (recent CURRENT, and newer xorg packages). I'll see if I can gather more information at BSDCan next week. Funny, I can't reproduce the bug neither. I've removed some parts from my xorg.conf, maybe the problem came from here. * When I don't use the native resolution (i.e the radeon firmwares are not loaded) switching from a tty to another results sometimes in a black screen when only some colors are displayed. This does not seems to appear when the native resolution is set. Can you describe the corruption in some more detail, or share a picture of it? I haven't observed something like this with stock vt, and the vt_vga driver. Yes, I've recorded a video [1]. Please note again that I can reproduce this bug only when I don't have any firmware loaded / KMS enabled. I just boot with stock vt and vt_vga enabled. In the video I've successfully reproduced the bug two times by switching ttys at around 0:25 when you can see just the cursor shown and also at 0:40 where you can see some garbage colors which came from vim. You can also notice that sometimes switching from one to other displays some artifacts until it is refreshed. And some questions: * Will you add support for dead keys? I have a UK keyboard and when I want to write french characters like à ô ê I usually press the ` character then a. This isn't currently planned, but I'll keep it in mind if I look into future work on the keyboard input path. I hope for :-). [1] http://www.demelierdavid.fr/files/vt.mp4 Regards, David. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Questions and *little* bugs in new vt(9)
Hi there, I'm currently trying vt(9) on a CURRENT kernel (only the kernel not the base). I have very small bugs, not really serious. I'm currently using the radeon KMS driver. * When I switch from a tty to X I can see the mouse appearing but the tty is still displayed until I move the mouse. Or until I wait something like 3 seconds. It sounds like a small refresh trouble. * When I don't use the native resolution (i.e the radeon firmwares are not loaded) switching from a tty to another results sometimes in a black screen when only some colors are displayed. This does not seems to appear when the native resolution is set. And some questions: * Will you add support for dead keys? I have a UK keyboard and when I want to write french characters like à ô ê I usually press the ` character then a. Same for ^ then o and e. To accomplish this, I use the extd variant in Xorg. This let me to press the dead ` character before a. It would be great to add this support to the vt (or maybe it is already done but I was not able to modify .kdb files to support that). Thanks for your great work on vt(9) and I'm very happy to have full unicode support and a quick tty switch :-). PS: this is more a personal opinion, but I really prefer the syscons font rather than the vt(9)'s one. Regards, David. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Light humour
2013/4/28 Paul Webster : > Just got this link on IRC, (freenode/##freebsd) was so funny I thought > I would see if I could get any of you guys to spit out you're coffee > :) > > http://antibsd.wordpress.com/ Do not post any comment on that website ! The user will replace any content you write by something like "You're article is excellent, pointing exactly the facts". All of the comments are probably edited by the maintainer -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipfilter(4) needs maintainer
2013/4/14 Gary Palmer : > On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: >> Is it possible to move ipfilter into a port? > > That may work short term, but the ENOMAINTAINER problem will quickly creep > up again as kernel APIs change. If the author has lost interest in > maintaining the FreeBSD port of ipfilter then unless someone steps forward > to carry on the work, I don't see much of a future for ipfilter in > FreeBSD > > Do we honestly need three packet filters? > No, for me only one should be present. I completely understand that some users still use IPFilter and IPFW but why providing three packet filters? The answer should be: use one and document only one. If at the beginning we started documenting only one all users should have used the only one present. Now we really need to remove the ancestral ipfilter and tell people switching to pf(4). Everything in life change, if we need to maintain all code from the past we will have a lot of compat code that pollute the full source tree and we will never improve the code just because of old bits My $0.02, Regards -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mbstowcs(3) may not return -1
On 21/06/2012 14:55, Sergey Kandaurov wrote: On 21 June 2012 16:38, David Demelier wrote: Hello, While reading the manpage of mbstowcs I noticed an error in the RETURN VALUES : The mbstowcs() function returns the number of wide characters converted, not counting any terminating null wide character, or -1 if an invalid multibyte character was encountered. Since size_t is unsigned, it can't returns -1. It returns (size_t)(-1). I don't know how is it correct, but this conforms to C spec. Yes that is very strange, iconv(3) do it too. -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: mbstowcs(3) may not return -1
On 21/06/2012 14:55, Sergey Kandaurov wrote: On 21 June 2012 16:38, David Demelier wrote: Hello, While reading the manpage of mbstowcs I noticed an error in the RETURN VALUES : The mbstowcs() function returns the number of wide characters converted, not counting any terminating null wide character, or -1 if an invalid multibyte character was encountered. Since size_t is unsigned, it can't returns -1. It returns (size_t)(-1). I don't know how is it correct, but this conforms to C spec. Mm, if I understand well, since it is cast to size_t, I think the return value will be SIZE_MAX - 1 then, right? -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
mbstowcs(3) may not return -1
Hello, While reading the manpage of mbstowcs I noticed an error in the RETURN VALUES : The mbstowcs() function returns the number of wide characters converted, not counting any terminating null wide character, or -1 if an invalid multibyte character was encountered. Since size_t is unsigned, it can't returns -1. Cheers, -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Status of newcons / vt(4)
Hello, I don't user -CURRENT so I'm just guessing the status of the vt(4) driver http://wiki.freebsd.org/Newcons. The wiki page has not been updated since 2009 so I hope the project is not dead. I'm very sad about the lack of UTF-8 in syscons and more because I remember a couple of years ago it was planned for FreeBSD 8 and it is completely not supported right now. Cheers, -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: snd_hda : sometimes sound sometimes not
On 28/05/2011 15:46, Jeremy Chadwick wrote: On Sat, May 28, 2011 at 03:30:26PM +0200, David Demelier wrote: On 12/05/2011 08:47, David Demelier wrote: Hello, I don't know if there is a lot of changes in the snd_hda driver in the -STABLE branch but since I upgraded to it sometimes I have sound and sometimes not. The mixer are exactly the same when these event occurs. This happened this morning. After booting I do not have any sound. I rebooted and suddenly I've got sound again... I only tweak snd_hda(4) for a pin sense on the front panel (it has no sound neither) So I added in /boot/devices.hints : hint.hdac.1.cad0.nid27.config="as=1 seq=15" And there's the both dmesg ok.txt when sound is here and not.txt when there isn't as you can see there is no difference related to the hda driver. http://markand.malikania.fr/ok.txt http://markand.malikania.fr/nok.txt I'm guessing something. My laptop has a mute shortcut, if I press it at the BIOS stage I will not have sound neither thus is it possible that my chipset is muted from anything? Cheers, Sorry to cross-post again, but I just wanted to tell you that the problem disappeared in -CURRENT so now I just how the unknown bogus code will be MFC before 8.3-RELEASE Unless someone can chime in with details of the commits which changed, assuming "the magic change" will be MFC'd is a bad one. It's safe to say that when 8.3-RELEASE comes out if this problem haunts you again, you will be mailing the list about it, and this cycle will continue until 9.0-RELEASE comes out. Does any developer/committer have familiarity with this issue and have some ideas as to what may have changed in CURRENT that addresses David's issue? And if so, can that code be MFC'd safely or patches provided to David for RELENG_8 that he can try out? I'm CC'ing mav@ here (snd_hda(4) says he's one of the authors), although he may not have any knowledge of the code which may need to be MFC'd. He may be able to point us to who has a better idea though. No worries Jeremy but thanks for your interest you seems to be the only one who believed my problem. The problem has been fixed in -STABLE, I don't know where but it works now -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: snd_hda : sometimes sound sometimes not
On 12/05/2011 08:47, David Demelier wrote: Hello, I don't know if there is a lot of changes in the snd_hda driver in the -STABLE branch but since I upgraded to it sometimes I have sound and sometimes not. The mixer are exactly the same when these event occurs. This happened this morning. After booting I do not have any sound. I rebooted and suddenly I've got sound again... I only tweak snd_hda(4) for a pin sense on the front panel (it has no sound neither) So I added in /boot/devices.hints : hint.hdac.1.cad0.nid27.config="as=1 seq=15" And there's the both dmesg ok.txt when sound is here and not.txt when there isn't as you can see there is no difference related to the hda driver. http://markand.malikania.fr/ok.txt http://markand.malikania.fr/nok.txt I'm guessing something. My laptop has a mute shortcut, if I press it at the BIOS stage I will not have sound neither thus is it possible that my chipset is muted from anything? Cheers, Sorry to cross-post again, but I just wanted to tell you that the problem disappeared in -CURRENT so now I just how the unknown bogus code will be MFC before 8.3-RELEASE Cheers, -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Fwd: snd_hda, codec attaching randomly?
Hello, I've setup a brand new computer from scratch, it has two HDMI output (via the on board and via the ati graphic card) with one codec for the main board. Usually I have these pcm : pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac1 pcm2: at cad 0 nid 1 on hdac1 pcm3: at cad 0 nid 1 on hdac1 pcm4: at cad 3 nid 1 on hdac1 But sometime when I boot the pcm4 disappear, with a lot of : hdac1: hdac_widget_connection_parse: nid=2 WARNING: zero cnid entnum=4 j=0 index=0 entries=17 found=0 res=0x hdac1: hdac_widget_connection_parse: nid=2 WARNING: zero cnid entnum=4 j=1 index=0 entries=17 found=1 res=0x hdac1: hdac_widget_connection_parse: nid=2 WARNING: zero cnid entnum=4 j=2 index=0 entries=17 found=2 res=0x hdac1: hdac_widget_connection_parse: nid=2 WARNING: zero cnid entnum=4 j=3 index=0 entries=17 found=3 res=0x [.. snip ..] Here you can see the normal dmesg file : http://files.malikania.fr/normal.txt And here when the pcm disappear : http://files.malikania.fr/notnormal.txt A simple diff from the files show some weird things: diff -ub normal.txt notnormal.txt --- normal.txt 2011-03-10 08:06:14.0 +0100 +++ notnormal.txt2011-03-10 08:06:18.0 +0100 @@ -116,24 +116,90 @@ hdac0: HDA Codec #0: ATI R6xx HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC888 -hdac1: HDA Codec #3: Intel G45 HDMI +hdac1: HDA Codec #3: Intel Q57 HDMI +hdac1: hdac_widget_connection_parse: nid=2 WARNING: zero cnid entnum=4 j=0 index=0 entries=17 found=0 res=0x +hdac1: hdac_widget_connection_parse: nid=2 WARNING: zero cnid entnum=4 j=1 index=0 entries=17 found=1 res=0x [... message repeated a lot of time ...] pcm1: at cad 0 nid 1 on hdac1 pcm2: at cad 0 nid 1 on hdac1 pcm3: at cad 0 nid 1 on hdac1 -pcm4: at cad 3 nid 1 on hdac1 Why does the HDMI codec is renamed to Q57? I didn't tweak snd_hda(4) much, I only added the following in my /boot/devices.hints to get a proper jack-sense on my front panel: hint.hdac.1.cad0.nid27.config="as=1 seq=15" Cheers, -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_JAIL and make delete-old{,-libs}
On 20/03/2011 17:31, Alexander Leidinger wrote:
On Sun, 20 Mar 2011 08:34:51 +0100 David Demelier
wrote:
Hello,
I was surprised to see there is no ${MK_JAIL} conditional to remove
old files on 8.2-RELEASE so I started to write it without watching if
-CURRENT already make it in
/usr/src/tools/build/mk/OptionalObsoleteFiles.inc.
.if ${MK_JAIL} == no
OLD_FILES+=usr/sbin/jail
OLD_FILES+=usr/sbin/jexec
OLD_FILES+=usr/sbin/jls
OLD_FILES+=usr/share/man/man8/jail.8.gz
OLD_FILES+=usr/share/man/man8/jexec.8.gz
OLD_FILES+=usr/share/man/man8/jls.8.gz
.endif
I personnaly added more files :
OLD_LIBS+=lib/libjail.so.1
OLD_LIBS+=usr/lib/libjail.a
OLD_LIBS+=usr/lib/libjail_p.a
OLD_FILES+=usr/lib/libjail.so
OLD_FILES+=etc/rc.d/jail
So if you do an installworld, do those files you added show up again or
not? If they show up, they are wrong to be added there. Delete old is
supposed to delete stuff which does not get installed during an
installworld but was installed in some older version of FreeBSD. From
my reading of the Makefile in src/lib/ (on -current) it looks like at
least the libjail is installed regardless of the knob. I do not know if
this is a bug or by design, this would have to be discussed on the
mailinglist which is about FreeBSD jails.
If those files are not installed during an installworld, it's obviously
a bug which needs to be fixed (and I would have misunderstood the
Makefile).
(/usr/lib/libjail.so is a symbolic link)
I think they should be removed too, thus can you merge it to -STABLE
if it's not already done? (sorry I'm not used to the cvs web
interface and I don't have -STABLE right now)
Cheers,
No I understood why, that's because a lot of userland programs that can
handle jails processes are linked to the libjail such as top, ifconfig, ...
Cheers,
--
David Demelier
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
WITHOUT_JAIL and make delete-old{,-libs}
Hello,
I was surprised to see there is no ${MK_JAIL} conditional to remove old
files on 8.2-RELEASE so I started to write it without watching if
-CURRENT already make it in
/usr/src/tools/build/mk/OptionalObsoleteFiles.inc.
.if ${MK_JAIL} == no
OLD_FILES+=usr/sbin/jail
OLD_FILES+=usr/sbin/jexec
OLD_FILES+=usr/sbin/jls
OLD_FILES+=usr/share/man/man8/jail.8.gz
OLD_FILES+=usr/share/man/man8/jexec.8.gz
OLD_FILES+=usr/share/man/man8/jls.8.gz
.endif
I personnaly added more files :
OLD_LIBS+=lib/libjail.so.1
OLD_LIBS+=usr/lib/libjail.a
OLD_LIBS+=usr/lib/libjail_p.a
OLD_FILES+=usr/lib/libjail.so
OLD_FILES+=etc/rc.d/jail
(/usr/lib/libjail.so is a symbolic link)
I think they should be removed too, thus can you merge it to -STABLE if
it's not already done? (sorry I'm not used to the cvs web interface and
I don't have -STABLE right now)
Cheers,
--
David Demelier
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
On 12/01/2011 00:03, Garrett Cooper wrote: On Tue, Jan 11, 2011 at 12:11 PM, David DEMELIER wrote: Hello, I'm just guessing why current BSD panic() when a problem occurs, all modern operating systems solve the problem instead of crashing suddently and corrupting all your data without saving your work. Yes, why this function exists? There is no way to solve a problem without panic'ing? Is panic really needed? Imagine someone working on something really important and his computer just panic, his work not saved everybody shout at him in the corporation. He lose his job, his wife, his dog, everything is wrong, just because of a panic() ! Seriously, I really hate when I play some music that suddenly the music get stucked in a infinite loop, why ? I don't know because the panic does not core dump. But after some search I found that the panic was done because of conky. How the hell conky can panic FreeBSD? We are in 2011 ! I think even Window 2000 does not crash on a user-land software. I'm guessing now, if minix panic when a bloated crappy software is running. I think Andrew is in the right way. So I guess with that reasoning we don't need asserts, bugs never occur, and the if the computer catches on fire we should just let it burn up instead of getting an extinguisher and put it out :D? As an example: I would rather have my PC panic and not write out corrupt data to disk instead of write out that corrupt data to disk. The latter has happened with userland apps on occasion before they crash, and that really fries my bacon... Similarly, if we're beyond recovery, panicing is the best and only option, but yes... recovery could be handled better in some cases. Filesystems are a bit trickier though because they're more mission critical than say a non-critical device driver (my sound driver?) tanking. Thanks, -Garrett In any case, when panic occurs, switching display to the tty can be great. Why not a sysctl like kern.tty_on_panic? Because when you're running X and a panic occurs not everybody understand what happens. Or the problem for me, when a panic occurs it *NEVER* core dump. Absolutely never, it stops at a moment but does not finish so I need to be in tty to debug directly so that's why a tty switch may helps in my case :-) -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cannot switch tty's after install xorg, gnome and gdm
On 23/01/2011 16:32, LOL wrote: Hi guys. On every release of freebsd that i tried (-CURRENT, -STABLE, -RELEASE) everything goes fine until I install xorg, gdm and gnome by packages or not it does not make any difference. When I boot with gnome_enable="YES" , and gdm start, when I try to change tty, on every tty, its a black screen and my monitor tell me, power saving mode enable until I switch back to gdm. I installed the xf86-video-ati driver and I have an ati radeon HD 5770. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Hi LOL, You should try to compile xorg from ports with the WITHOUT_NOUVEAU knob placed in your /etc/make.conf. This will install a more recent libdrm, dri and so on. It may helps. Also see the UPDATING note related to : 20100207: AFFECTS: users of Mesa3D libraries and x11-drivers/xf86-video-nouveau AUTHOR: n...@freebsd.org If you want to use Mesa3D 7.6.1 and libdrm 2.4.17 rather than 7.4.4 and 2.4.12, you must define WITHOUT_NOUVEAU global macro, at least, enabled on graphics/libGL*, graphics/libglut, graphics/dri, graphics/mesa-demos, and graphics/libdrm. And please give up using x11-drivers/xf86-video-nouveau. At this time, I cannot enable latest Mesa3D and libdrm, because they break xf86-video-nouveau. But old (current?) Mesa3D and libdrm do not break any drivers. AMD Radeon HD 2xxx/3xxx/4xxx users: If you use AMD Radeon HD [234]xxx series, please define WITHOUT_NOUVEAU global macro. You can then use OpenGL Hardware Accelerator feature on these series. Cheers, -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
suspend with drm activated ?
Hello, My laptop can't suspend/resume correctly using 8.1-RELEASE. It can with -CURRENT but if I remember correctly you can suspend with drm activated but resuming results in a lot of problem in X. Is this still the case before I upgrade to current? I would like to suspend/resume with DRM. Thanks, -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: BSDInstall: merging to HEAD
On 14/01/2011 19:26, Nathan Whitehorn wrote: As those of you who have been reading freebsd-sysinstall and freebsd-arch know, I have been working for a few weeks on a lightweight new installer named 'bsdinstall'. This is designed to replace sysinstall for the 9.0 release. After two weeks of testing and bug fixes on the sysinstall list, I believe this now has all required functionality and is ready to be merged into the main source tree. I would like to do this on Tuesday, 18 January. Switching this to be the default installer would happen a few weeks after that, pending discussion on release formats with the release engineering team. This should provide a sufficient testing period before 9.0 and allow a maximal number of bugs to be discovered and solved before the release is shipped. Demo ISO for i386: http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110114.iso.bz2 SVN repository: svn://svn.freebsd.org/base/user/nwhitehorn/bsdinstall Wiki page: http://wiki.freebsd.org/BSDInstall Goals - The primary goal of BSDInstall is to provide an easily extensible installer without the limitations of sysinstall, in order to allow more modern installations of FreeBSD. This means that it should have additional features to support modern setups, but simultaneously frees us to remove complicating features of sysinstall like making sure everything fits in floppy disk-sized chunks. New Features: - Allows installation onto GPT disks on x86 systems - Can do installations spanning multiple disks - Allows installation into jails - Eases PXE installation - Virtualization friendly: can install from a live system onto disk images - Works on PowerPC - Streamlined system installation - More flexible scripting - Easily tweakable - All install CDs are live CDs Architecture BSDInstall is a set of tools that are called in sequence by a master script. These tools are, for example, the partition editor, the thing that fetches the distributions from the network, the thing that untars them, etc. Since these are just called in sequence from a shell script, a scripted installation can easily replace them with other things, (e.g. hard-coded gpart commands), leave steps out, add new ones, or interleave additional system modifications. Status -- This provides functionality most similar to the existing sysinstall 'Express' track. It installs working, bootable systems you can ssh into immediately after reboot on i386, amd64, sparc64, powerpc, and powerpc64. There is untested support for pc98. The final architecture on which we use sysinstall, ia64, is currently unsupported, because I don't know how to set up booting on those systems -- patches to solve this are very much welcome. There are still some missing features that I would like to see in the release, but these do not significantly impact the functionality of the installer. Some will be addressed before merging to HEAD, in particular the lack of a man page for bsdinstall. Others, like configuration of wireless networking and ZFS installation, can happen between merge and release. The test ISOs are also lacking a ports tree at the moment, which is a statement about the slow upload speed of my DSL line and not about the final layout of releases. Please send any questions, comments, or patches you may have, and please be aware when replying that this email has been cross-posted to three lists. Technical discussion (bug reports, for instance) should be directed to the freebsd-sysinstall list only. Most other discussion belongs on -sysinstall and -current. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Why does the installer use GPT partition by default? Do you know that GPT is not supported on every (even modern) computer ? -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: why panic(9) ?
2011/1/11 Chuck Swiger : > On Jan 11, 2011, at 12:11 PM, David DEMELIER wrote: >> I'm just guessing why current BSD panic() when a problem occurs, all >> modern operating systems solve the problem instead of crashing >> suddently and corrupting all your data without saving your work. > > You've got it backwards. A system panic()s to avoid writing corrupted data > to disk. > >> Yes, why this function exists? There is no way to solve a problem >> without panic'ing? Is panic really needed? > > Sometimes, yes. If it was possible for the kernel to handle an error > condition without panic()ing, then that is obviously preferred-- but there > are situations where there is no way for the system to recover. Common > examples of that include when the boot disk fails or disappears, or when the > kernel runs out of memory in a situation where it can't get more free pages > available. Less common is when some kind of kernel invariant is violated, > indicating that essential kernel data structures have been corrupted. > Well I see, I know that kern.sync_on_panic exists to force a sync on a panic but because my laptop usually does not core dump so never reboot my disk are not sync'ed :-( it results in a file system not clean an that's the thing I really hate. >> Imagine someone working on something really important and his computer just >> panic, his work not >> saved everybody shout at him in the corporation. He lose his job, his >> wife, his dog, everything is wrong, just because of a panic() ! > > I admire your contrived example. :-) The data available to me suggests that > Solaris boxes on enterprise-grade hardware have the highest uptimes; FreeBSD > (and related platforms like NetBSD/OpenBSD/DFly/etc) are next, then MacOS X, > then Linux, then Windows. > > I expect anything based on Unix to be routinely capable of multi-year > uptimes; some carefully chosen Windows boxes can also do that, but the > widespread prevalence of security issues requiring reboots on Windows means > that I don't usually see Windows boxes with uptimes of greater than a month. > >> Seriously, I really hate when I play some music that suddenly the >> music get stucked in a infinite loop, why ? > > Probably a bug in the sound card driver. > No no, it was a panic that didn't core dump so I needed to do a hard reboot. >> I don't know because the panic does not core dump. But after some search I >> found that the panic >> was done because of conky. How the hell conky can panic FreeBSD? We are in >> 2011 ! I think even Window 2000 does not crash on a user-land software. > > "think"? If you don't have experience running Windows 2000 are thus are > simply guessing, let me assure you that Win 2000 can and does (or did) panic > due to userland software. > In fact I like FreeBSD, and I don't expect running anything else. But I must say that I didnt see windows 2000 crashing on my every boxes I have before switching to FreeBSD. I understand everything, corrupts kernel data must not be used. That's why panic are made to prevent any dangerous things. -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
why panic(9) ?
Hello, I'm just guessing why current BSD panic() when a problem occurs, all modern operating systems solve the problem instead of crashing suddently and corrupting all your data without saving your work. Yes, why this function exists? There is no way to solve a problem without panic'ing? Is panic really needed? Imagine someone working on something really important and his computer just panic, his work not saved everybody shout at him in the corporation. He lose his job, his wife, his dog, everything is wrong, just because of a panic() ! Seriously, I really hate when I play some music that suddenly the music get stucked in a infinite loop, why ? I don't know because the panic does not core dump. But after some search I found that the panic was done because of conky. How the hell conky can panic FreeBSD? We are in 2011 ! I think even Window 2000 does not crash on a user-land software. I'm guessing now, if minix panic when a bloated crappy software is running. I think Andrew is in the right way. -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
No human readable message with g_vfs
Hello, Sometimes when I use my external harddrive I get these awful message : g_vfs_done():da1[WRITE(offset=34590720, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34656256, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34721792, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34787328, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 18:36:07 Abricot kernel: g_vfs_done():da1[WRITE(offset=34852864, length=65536)]error = 5 /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel: g_vfs_done():ufs/public[WRITE(offset=244271529984, length=16384)]error = 5 /var/log/messages.1.bz2:Dec 21 22:50:28 Abricot kernel: g_vfs_done():ufs/public[READ(offset=244563705856, length=131072)]error = 5 /var/log/messages.5.bz2:Nov 29 16:36:52 Abricot kernel: g_vfs_done():ufs/public[READ(offset=232718991360, length=131072)]error = 5 I think for a lambda user these are absolutely not understandable. I think these message could be enabled with a little options in the kernel config. why not something like "options GPART_DEBUG" or something else? And do something more readable without. Kind regards, -- David Demelier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9-CURRENT: ports/net/kdenetwork3 does not compile
2010/11/2 Rob Farmer : > On Mon, Nov 1, 2010 at 23:14, Matthias Apitz wrote: >> Something wrong with 'struct utmp ubuf' in HEAD? > > It has been removed: > > http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014893.html > > -- > Rob Farmer > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > A lot of ports will need some patches then, isn't it ? -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/25 Marcin Cieslak : >>> M. Warner Losh wrote: > >>: I agree but like Aleksandr said, almost 70% of dhcp code is already in >>: base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea >>: to keep some parts in the ports tree and move out from the base. >> >> Yea. I agree too. Just because BIND was EOLd in 6 isn't a great >> argument against dhcp server. Most of the code is there anyway, and >> it isn't evolving as fast as BIND. >> >> It would be very convenient to have this particular thing in the base, >> and we shouldn't be too dogmatic about never having any new 3rd party >> things in the base. After all, we just added more compression >> utilities to the base, and nobody said a peep. This is analogous: we >> have good opportunity to integrate into the system, and users benefit >> from that integration. > > As a road-warrior consultant I really value having things like > bootpd, tftpd, bootparamd and similar software always there. > Many times I wished dhcpd was there, too. > > Another typical use - FreeBSD makes a good small network router out > of the box (PPP, NAT, ipfw, WLAN AP, DNS are there, dhcpd - missing). > > I am not sure about the whole "modularization" goal - I think > the relatively monolythic nature is one of the FreeBSD's merits. > > For example, it's good to have NFSv4, Kerberos and required > userland daemons packaged in the base. I don't want to have > those done separately in a modular way (although Heimdal > we have is older then what their current trunk is). > We got stuck on connecting Linux boxes via NFSv4 to Solaris > and BSD because one of the userland modules in Linux was terribly > out of date and authenticating the user w/Kerberos was not possible. > > As we build a more complex networking landscape with VIMAGE and > friends I think that the benefits of better integration of dhcpd > in the base system (rc.d, rc.conf...) may outweigh its costs > (maintenance, bloat, etc.). > > //Marcin > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > I agree that for some people it will be completely useless, but if we can disable it in src.conf everyone will be happy. Since FreeBSD is great for a router it's really fast to make a full working server without installing anything else. I agree for the 70% part of dhcp which is already present. In any case, src.conf(5) is still working and usable, isn't it? Kind regards, -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Web feeds for UPDATING files
2010/9/25 jhell : > On 09/25/2010 09:24, Alexander Kojevnikov wrote: >> On 25 September 2010 17:04, Alexander Kojevnikov >> wrote: >>> On 25 September 2010 15:44, jhell wrote: Really awesome! This will come in handy to serve up stable/*/UPDATING and head/UPDATING to. And thinking along those lines it could probably be incorporated directly into the DAV tree on svn. to serve directly from there. >>> >>> Great idea, I'll try to implement both feeds during the weekend and >>> will post here and on freebsd-current@ and freebsd-stable@ when it's >>> done. >> >> ...and done: >> >> http://updating.versia.com/ >> >> The site now features Atom feeds for the following files: >> >> * ports/UPDATING >> * head/UPDATING >> * stable/7/UPDATING >> * stable/8/UPDATING >> >> Hope you find the feeds useful. >> >> Cheers, >> Alex >> >> PS: I apologise to ports/UPDATING subscribers who got quite a few >> duplicate entries. I barely missed the Ballmer Peak, just delete >> those. > > Your amazing! > > Thanks Alexander! > > -- > > jhell,v > ___ > freebsd-sta...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > It's so great that it should be merge to the official FreeBSD web page! Thanks a lot! Kind regards, -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Null modem to USB wire not working
2010/9/19 Boris Samorodov : > On Sun, 19 Sep 2010 21:25:36 +0200 David DEMELIER wrote: > >> I just bought a null modem to USB from Profilic and it isn't >> recognized by FreeBSD. > >> It's a chipset Prolific Technology Inc. > >> Sep 19 21:19:15 Melon root: Unknown USB device: vendor 0x067b product >> 0x2303 bus uhub6 >> Sep 19 21:19:15 Melon kernel: ugen6.2: at usbus6 > >> Is there any driver I can use or I need to buy another one? > > alya% apropos prolific > uplcom(4) - USB support for Prolific PL-2303/2303X/2303HX > serial adapters driver > > -- > WBR, Boris Samorodov (bsam) > Research Engineer, http://www.ipt.ru Telephone & Internet SP > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > Thanks ! -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Null modem to USB wire not working
Hi, I just bought a null modem to USB from Profilic and it isn't recognized by FreeBSD. It's a chipset Prolific Technology Inc. Sep 19 21:19:15 Melon root: Unknown USB device: vendor 0x067b product 0x2303 bus uhub6 Sep 19 21:19:15 Melon kernel: ugen6.2: at usbus6 Is there any driver I can use or I need to buy another one? Kind regards, -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/14 Kevin Oberman : >> Date: Tue, 14 Sep 2010 19:13:58 +0200 >> From: David DEMELIER >> Sender: owner-freebsd-curr...@freebsd.org >> >> 2010/9/14 Marian Hettwer : >> > On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER >> > wrote: >> >> 2010/9/13 Gordon Tetlow : >> >>> On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER >> >>> >> >>> wrote: >> >>>> >> >>>> Perl is a great example, I don't really understand why it's in the >> >>>> base, then the port need to rewrite the links into the base hierarchy >> >>>> and I think this is bad. >> >>> >> >>> Perl is not in the base system anymore. It's in the ports system. >> >>> Gordon >> >> >> >> Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! >> > >> > Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC. >> > Nothing to do with following -current ;-) >> > >> > ./Marian >> > >> >> Oh then I'm confused, why the ports still rewrite links in /usr/bin then ? > > This was a way to avoid breaking the huge number of perl scripts that > had: #!/usr/bin/perl as the first line. If perl simply moved to > /usr/local/bin, this would have broken a LOT of stuff people were doing, > so it was decided to put a link in /usr/bin. The port now has an option > to control this, but it is still there by default: > USE_PERL "Rewritelinks in /usr/bin" on > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: ober...@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > Well I see, thanks ! -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/14 Marian Hettwer : > On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER > wrote: >> 2010/9/13 Gordon Tetlow : >>> On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER >>> wrote: >>>> >>>> Perl is a great example, I don't really understand why it's in the >>>> base, then the port need to rewrite the links into the base hierarchy >>>> and I think this is bad. >>> >>> Perl is not in the base system anymore. It's in the ports system. >>> Gordon >> >> Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! > > Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC. > Nothing to do with following -current ;-) > > ./Marian > Oh then I'm confused, why the ports still rewrite links in /usr/bin then ? -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/13 Gordon Tetlow : > On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER > wrote: >> >> Perl is a great example, I don't really understand why it's in the >> base, then the port need to rewrite the links into the base hierarchy >> and I think this is bad. > > Perl is not in the base system anymore. It's in the ports system. > Gordon Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/11 Doug Barton : > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: >> >> Hi, >> >> another argument about hostapd :) if have access point we must have >> way to assign IP for AP clients. > > To start with, your assumption is wrong. DHCPd is not *actually* a > requirement, although I admit that practically it is. > >> Last spring I made firmware based on FreeBSD for router with only 4MB >> NOR flash (D-Link DIR-320). > > In this category (micro-miniaturization) you're already in the "significant > customization needed" area, which means that general arguments about "the > base" don't apply. > >> Since this device is router I must be >> able to serve DHCP. And current implementation of dhcpclient, that we >> have, is same isc-dhcp, and I replace system dhcpclient with ports >> one+dhcpd but with small patch that put basic dhcp utils onto >> libdhcp.so. > > Your argument is creative and well thought out, but I personally don't find > it persuasive. Counter arguments that come immediately to mind are: > 1. The DHCP server is not going to benefit any but a small minority of > FreeBSD users. > 2. The software is already available in the ports tree, and adding a > port/package of it really is not an overwhelming burden. > > More generally, the main reason I want to keep more stuff out of the base, > and remove some of the stuff that's in there now, is that it makes > maintenance difficult across FreeBSD branches. We have a general policy that > if we have a major version N of something in a release branch that we don't > upgrade that major version without a really good reason to avoid POLA > surprises for our users. Once again using BIND as an example, this has led > to a really old and past-EOL version of BIND in FreeBSD 6 which I've only > gotten away with because anyone doing serious DNS work nowadays has to > upgrade to at least 9.6 anyway. But it's an ugly situation, and I don't want > to repeat it. > I agree but like Aleksandr said, almost 70% of dhcp code is already in base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea to keep some parts in the ports tree and move out from the base. Perl is a great example, I don't really understand why it's in the base, then the port need to rewrite the links into the base hierarchy and I think this is bad. > The problems get worse and/or more complex with the more 3rd party stuff you > start including in the base. In part because of the product lifecycle issues > that are similar to BIND's, but also due to the possibility of licensing > issues (such as with gcc and/or other GPL software) and other more esoteric > factors. > > Even with home-grown stuff like our pkg_* tools we have problems because > when we want to introduce new features (or deprecate old ones) there is > currently a _minimum_ 3-year cycle we have to follow in order to make sure > that the new feature is/is not available on all supported versions of > FreeBSD. That's the main motivation behind my continuing to repeat the > suggestion to move those tools specifically into the ports tree so that we > can better support innovation in our ports/packages system. > > In my view what we've needed to do for a long time now is to seriously strip > down the notion of what "the base" should be to those items that are needed > to work together for a specific API/ABI/AKI release, and move everything > else into the ports tree. (Obviously there would be some exemptions made for > really basic/vital stuff like ls, etc.) We can do this in a way that finds a > middle ground between the linux model where literally everything is a > package and the traditional BSD model of providing a "complete system," > which is hardly ever true since I've never been involved with any FreeBSD > system administration where there were absolutely no ports/packages > installed at all. > > Such a system could also be streamlined by creating a ports virtual category > (something like "system") the packages for which could be included in the > install media as long as we are judicious about what goes in there. Things > like wpa_supplicant, dhclient, DNS tools, etc. could all be in that > category, and all we'd have to do to make that work is to very slightly > expand the list of questions that sysinstall already asks. > > So this is a much longer version of my previous response which hopefully > gives you more background about why it's a bad idea to add *any* more 3rd > party stuff to the base. > > > Doug > > -- > > ... and that's just a little bit of history repeating. > -- Propellerheads > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > > -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/10 Matthew Jacob : > I think not. You are given the opportunity to install prebuilt packages at > install time, and with a modest amount of effort can install prebuilt > packages afterwards. > > IMO, such as it is, there should be *less* in the base system than there > currently is and more in ports. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > In this case there are some parts in base/ that could live in ports/ instead of the base directory such as hostapd(8), maybe nobody want to make a usable wireless access point? And what about bind too? A lot of user do not needs it, by the way there is already src.conf(5) to enable or disable modules, then a WITHOUT_DHCPD would be useful. Cheers. -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
DHCP server in base
Hi folks, I personally agree that a DHCP client must exists in base, and for this purpose we have dhclient. However soon I will have a new small machine that will only work as bind and dhcpd server. I was surprised to see that there is no DHCP server in base, obviously it's not difficult to fetch the net/isc-dhcp31-server package but for people that would like to setup a new server on FreeBSD quickly they will take some time to learn how packages framework works or ports and it can be annoying. Since the size of the net/isc-dhcp31-server port is really small I think it would be really useful to get it by default on a FreeBSD install. Information for isc-dhcp31-server-3.1.3_1: Package Size: 1232(1K-blocks) What do you think? With kind regards, -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
unzip in basesystem.
Hi,
I noticed that unzip came into basesystem in src/usr.bin/unzip/. To
prevent port installing the ports/archivers/unzip one, I propose to
add this in bsd.port.mk
.if defined(USE_ZIP) && !exists(/usr/bin/unzip)
EXTRACT_DEPENDS+= ${LOCALBASE}/bin/unzip:${PORTSDIR}/archivers/unzip
.endif
Is that right ?
King regards
--
Demelier David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: unzip in basesystem.
2010/5/5 David DEMELIER :
> Hi,
>
> I noticed that unzip came into basesystem in src/usr.bin/unzip/. To
> prevent port installing the ports/archivers/unzip one, I propose to
> add this in bsd.port.mk
>
> .if defined(USE_ZIP) && !exists(/usr/bin/unzip)
> EXTRACT_DEPENDS+= ${LOCALBASE}/bin/unzip:${PORTSDIR}/archivers/unzip
> .endif
>
> Is that right ?
>
Sorry I gone too fast, I would add this in bsd.commands.mk too :
.if exists(/usr/bin/unzip)
UNZIP_CMD=/usr/bin/unzip
.else
UNZIP_CMD?= ${LOCALBASE}/bin/unzip
.endif
--
Demelier David
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
