Write Apt and Accurate English (adv)
Keyboard Write Apt And Accurate English Dear friends, The aim of the LCCI Certificate in English for Business Level 2 programme is to enable candidates to develop the ability to undersatnd and write English using formats that are current and common in business communication. Objectives to enable candidates to develop the ability to: Write apt and accurate English suited to the stated purpose Write business correspondence in a clear and concise manner Adopt the tone, form, layout, content and composition appropriate to the requirements of a given situation Effectively resolve problems through writing Participate in conversations Course Outline Communications in business Common errors in business writing Effective business writing Styles in business writing The art of business writing The buslness letter The business report Memorandum Leaftlet development Notice for business Article writing List format Email writing Administrative Details Course Name: LCCI Certificate in English for Business level 2 Start Date: 16.08.11 End Date: 15.11.11 Day/Time: Tuesday / 7pm to 10pm Course Duration: 13 sessions (3hrs per session) Training Venue: 19 Carpenter Street. (near Clarke Quay MRT station) Course Fee: $250nett with SDF grant ( for Singapore Citizen and Singapore PR only) Other fees: Admin fee @ $15nett,Course book @ $25nett, Exam fee @ $135nett Course fee without SDF grant @ $530nett (for non Singapore citizen and PR ) For enquiry or registration Contact Binson Lim @ 91783929 or email : bin...@edutrainingresources.com.sg Training Provider: Edu Training Resources Pte Ltd , 40C Hongkong Street , Singapore 05967 LCCI or The london Chamber of Commerce and Industry has over 100 years of experience in providing trusted and valued business-related qualifications. Employers and professional bodies recognise the LCCI international qualifications. LCCI's range of courses is designed to deliver the skills essential for success in todays's demanding business environment
Re: build from source vs. rc.d files
Hello, thank you all for your binary upgrade responses, but I do not think that it is the right method for my conditions. My machines are about 500km away and my remote access is solved by openvpn clients. Physical access to them and booting from external CD (or other installXX.iso image) is possible - hopefully only about once a year. Quick look into /usr/src/etc/Makefile reveals, that only way to install rc.d scripts are through make distribution-etc-root-var, which is called by make release (so here is that binary upgrade), but not by make install or make build. So, 1) is there any way to do binary upgrade from release files without loosing remote connectivity? 2) upgrade from source will be no more supported for obsd5 ? 3) if I do that cp/chmod/chgrp for /etc/rc.d/* files by hand, what else will be missing in upgraded system? Alexander On Sun, 2011-07-24 at 15:49 +0200, Alexander KrE!ek wrote: Hello, may be this is something I simply overlooked, but I found out (hard way) that my way of building/updating -current system from source (FAQ 5.3 + FAQ 5.5 w/o Making a release + sysmerge) left my system without new /etc/rc.d/ startup files (and may be some else). Is this a) bug, b) documented feature, or c) my stupidity? If c) is right, what is the right way of complete upgrade -current system from source? Alexander
Re: PC for assembly learning purposes
Well, I haven't chosen word break wisely, instead I meant I don't want to reinstall my PC for work (different OS). I rather need new pc for my personal use at home. Anyway, thank you for your responses. I have got a better picture now and as Nick said I will try several architectures, my original intention was to learn more about microprocessors at low level. 2011/7/25 Nick Holland n...@holland-consulting.net: On 07/24/11 07:27, Tomas Vavrys wrote: Hello, I am looking for a new cheap PC for assembly learning purposes, because I don't want to break my current workstation. I was thinking about http://www.tekmote.nl/epages/61504599.sf/nl_NL/?ObjectPath=/Shops/61504599/Pr oducts/CFL-006 but I am a little bit worried about current status All on-board devices are supported, but the framebuffer is currently limited to the 640x400x8 video mode set up by the firmware. What is the status in -current at the moment? This device will be used only for my learning purposes. I would like to jump on C and compilers later. Is it better to start with RISC or CISC? Should I buy rather x86? yes I'm assuming you mean assembly language, not putting hardware together... If so, what's your purpose? B Learning a particular assembly language? In which case, you get a machine of the exact type you plan to be coding for. If you are after the more generic learning microprocessors at a low level, you need SEVERAL, really. B Its a bit like learning a human language, I suspect (while I learned many different processors Way Back When, I'm hopelessly monolingual in the human world, but I've heard multi-lingual people tell me this) -- Learn one, you know one barely. Learn two, the third and later come quickly and easily, and you learn a lot more about your first. The good news is you don't need to buy new hardware. B For anything you are likely to do for the near term, the slowest processor will assemble code and run rapidly for you. So, get yourself a PII or PIII for x86, a sparc and a sparc64, an amd64 system (this one you probably have to pay for), and a mac68k (we're bringing that port back. B I don't think I can fully answer why). Nick.
Re: PC for assembly learning purposes
Op 24-7-2011 23:35, Tomas Vavrys schreef: This looks also promising... http://www.genesi-usa.com/products Are there any plans to support this architecture? Don't think so: http://www.openbsd.org/pegasos.html says it all. Erik
Gigabit Ethernet Controller compatibility with OpenBSD 4.9
Hi All, Have anyone of you ever installed OpenBSD 4.9(i386/amd64 platform) on a machine using Gigabit Ethernet Controller as follows: 1.Realtek 8111C Gigabit Ethernet Controller 2.Intel 82574L Gigabit Ethernet Controller 3.Intel 82567V Gigabit Ethernet Controller 4.Intel 82583V Gigabit Ethernet Controller 5.Intel 82574E Gigabit Ethernet Controller 6.Intel 82576 Gigabit Ethernet Controller 7.Intel 82599ES 10Gigabit Ethernet Controller Is there any compatibility issue? The reason I am asking because those gigabit and 10G ethernet controllers mentioned above are not listed on: http://www.openbsd.org/i386.html http://www.openbsd.org/amd64.html Regards, Stefan
Re: PC for assembly learning purposes
The easiest (if not perhaps the cheapest) solution is virtualisation. Use VMWare ESXi/VMWare Server/Xen or Qemu. Alternatively if you have more cash, run VMWare Workstation which includes the ability to record the state of a machine and then play it backwards to track down especially tricky bugs. On 25/07/2011, Tomas Vavrys vav...@cleancode.cz wrote: Well, I haven't chosen word break wisely, instead I meant I don't want to reinstall my PC for work (different OS). I rather need new pc for my personal use at home. Anyway, thank you for your responses. I have got a better picture now and as Nick said I will try several architectures, my original intention was to learn more about microprocessors at low level. 2011/7/25 Nick Holland n...@holland-consulting.net: On 07/24/11 07:27, Tomas Vavrys wrote: Hello, I am looking for a new cheap PC for assembly learning purposes, because I don't want to break my current workstation. I was thinking about http://www.tekmote.nl/epages/61504599.sf/nl_NL/?ObjectPath=/Shops/61504599/Pr oducts/CFL-006 but I am a little bit worried about current status All on-board devices are supported, but the framebuffer is currently limited to the 640x400x8 video mode set up by the firmware. What is the status in -current at the moment? This device will be used only for my learning purposes. I would like to jump on C and compilers later. Is it better to start with RISC or CISC? Should I buy rather x86? yes I'm assuming you mean assembly language, not putting hardware together... If so, what's your purpose? B Learning a particular assembly language? In which case, you get a machine of the exact type you plan to be coding for. If you are after the more generic learning microprocessors at a low level, you need SEVERAL, really. B Its a bit like learning a human language, I suspect (while I learned many different processors Way Back When, I'm hopelessly monolingual in the human world, but I've heard multi-lingual people tell me this) -- Learn one, you know one barely. Learn two, the third and later come quickly and easily, and you learn a lot more about your first. The good news is you don't need to buy new hardware. B For anything you are likely to do for the near term, the slowest processor will assemble code and run rapidly for you. So, get yourself a PII or PIII for x86, a sparc and a sparc64, an amd64 system (this one you probably have to pay for), and a mac68k (we're bringing that port back. B I don't think I can fully answer why). Nick.
Re: 4.7 ospfd FIB/RIB synchronization
On Sun, Jul 24 2011 at 27:21, David Gwynne wrote: On 24/07/2011, at 8:27 PM, Jonathan Lassoff wrote: On Wed, Apr 20, 2011 at 7:10 AM, David Gwynne l...@animata.net wrote: On 20/04/2011, at 11:08 PM, Jonathan Lassoff wrote: On Wed, Apr 20, 2011 at 4:22 AM, David Gwynne l...@animata.net wrote: you might be able to upgrade your passive firewall to 4.9 next to the active 4.7 one. it looks like the protocol stayed the same so they should be able to talk to each other. This would seem to be the case. This (http://undeadly.org/cgi?action=articlesid=20090301211402) is an absolutely excellent bit of writing about the improvements to pfsync, BTW. Thanks for letting that be shared. however, it looks like bulk updates were broken in 4.7, which would explain your failover problems. you can work around that by going pfctl -S /dev/stdout | ssh activefw pfctl -L /dev/stdin as root on the passive fw. As an initial seeding of state? It seems to me that only some of my flows get affected when failing over (not everything is reset and traffic can still flow). yes. the pfctl commands will do a bulk update since the in kernel implementation was unreliable back then. It appears that both firewalls have an approximately congruent set of states, but usually a pfctl -ss | wc -l can be off by several hundred, to several thousand states at times. My hunch is that state creation and counter updates are not updated synchronously, so when failing over there are still some updates in-flight, and for flows that are moving their sequence numbers at a decent clip I could see why they might get reset. pf has a bit of fuzz when it does its tcp window matching, so packets can get ahead of the firewall and be ok. Do you know if there is a way to see how much this fuzz is or if there's an offset? from memory its 1000 bytes. If dropped for being out of a window, will (or can) it get logged to pflog? again, from memory its just dropped. i wrote defer, so yes... on my boxes the increase in latency is about .2 to .3ms. if a firewall is missing its peer(s) it will go up to about 1/100th of a second. So does defer wait for a peer to acknowledge a new state just at the time of creation, or does it include state updates about sequence numbers as well? defer only delays the first packet. I suspect I'm hitting a similar issue as you were with long-lived flows getting reset at failover. i think my problem is that i run both firewalls with the carp demotion counter set low. when a box is rebooted the carp default is at 0 or 1, which means it takes over traffic before it gets all the states. later code in rc.local demotes it, but by that time some packets have been eaten by the new box. i should fix it, but im lazy. thats exactly how i have my stuff configured. Have you ever had trouble when re-numbering an interface? It seems to me like ospfd doesn't pick up changes in interface numbering if changed out from under it. Most other OSPF daemons I use would pick this up as it changes, but as far I as can tell there's no way to tell ospfd to reload interface addressing. interfaces and addresses moving around hurts me too. I'm often needing to add more and more interfaces and ospf interfaces, necessitating failing over so as to make it safe to kill and re-start ospfd -- in the process it just seems to nip some flows from flowing. i do that too. lets annoy claudio together! In my world, it happends to change interface numbering. The solution we found is - remove the interface from ospfd.conf, - reload configuration with ospfctl reload - destroy the interface (our ospf interfaces are mainly gif ones), - recreate interface with new IPs - add conf to ospfd.conf, - reload configuration with ospfctl reload This may sound a bit too much, but it works and seems to be reliable for the moment and it does not require to kill and restart the daemon :) Claer
Re: Gigabit Ethernet Controller compatibility with OpenBSD 4.9
2011/7/25 Stefan N stefanbsd...@yahoo.com: The reason I am asking because those gigabit and 10G ethernet controllers mentioned above are not listed on: http://www.openbsd.org/i386.html http://www.openbsd.org/amd64.html The lore is that 1G controller will just work. 10G are special, though. Best Martin
Re: build from source vs. rc.d files
On Mon, Jul 25, 2011 at 10:04:49AM +0200, Ing. Alexander KrE!ek wrote: Hello, thank you all for your binary upgrade responses, but I do not think that it is the right method for my conditions. My machines are about 500km away and my remote access is solved by openvpn clients. Physical access to them and booting from external CD (or other installXX.iso image) is possible - hopefully only about once a year. Quick look into /usr/src/etc/Makefile reveals, that only way to install rc.d scripts are through make distribution-etc-root-var, which is called by make release (so here is that binary upgrade), but not by make install or make build. So, 1) is there any way to do binary upgrade from release files without loosing remote connectivity? 2) upgrade from source will be no more supported for obsd5 ? 3) if I do that cp/chmod/chgrp for /etc/rc.d/* files by hand, what else will be missing in upgraded system? man 8 sysmerge That is the solution you are looking for. http://openbsd.org/faq/upgrade49.html also contains advice that works for most upgrades (look under ``final steps''. -0- -- Meskimen's Law: There's never time to do it right, but there's always time to do it over.
Re: OPenBSD 4.9 i386, Asus EEE 701, no network
On Sun, Jul 24, 2011 at 08:58:26PM +0200, Rudolf Leitgeb wrote: Hi folks, I wanted to give OpenBSD a new try and installed it on my Asus EEEPC 701. Install went well, but for some reason the network interface lii0 reports no carrier. Since I have no network in the OpenBSD computer, please forgive me for not going through the regular sendbug routine but posting the bug report directly to this mailing list. Just to make sure this is not a hardware problem: I test booted Ubuntu 10.04.1 i386 desktop from CD ROM and network was fully functional. I did not change anything in the hardware between boots, and the network cable remained untouched. Here is what I did after startup: - log in as root - type ifconfig lii0 192.168.1.55 Result: - ifconfig lii0 returns: lii0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 lladdr correct MAC address priority: 0 media: Ethernet autoselect (none) status: no carrier inet6 Did you up the interface? ifconfig lii0 up -0- -- I've seen better heads on half a pint of beer.
Re: build from source vs. rc.d files
On Mon, 25 Jul 2011, Owain Ainsworth wrote: man 8 sysmerge pkg_add mc is another good solution. Lee
Re: OPenBSD 4.9 i386, Asus EEE 701, no network
Am Montag, den 25.07.2011, 13:00 +0100 schrieb Owain Ainsworth: Did you up the interface? ifconfig lii0 up Thanks a lot, Owain, that was the problem. Network fully operational now! Cheers, Rudi
[PATCH] chat(8) manpage clarification
Hi! I've recently tried debugging a pppd(8) connection and noticed that the information in the chat(8) manpage was a little imprecise with regard to how logging is done. According to chat.c (lines 304 onward, from 4.9-release), it will log using facility LOCAL2 and level WARNING. If -v is specified, it will also log up to level INFO. I think it might be useful to include this information in the manpage as well; see patch below. Regards, s//un Index: chat/chat.8 === RCS file: /cvs/src/usr.sbin/pppd/chat/chat.8,v retrieving revision 1.18 diff -u -r1.18 chat.8 --- chat/chat.8 28 Oct 2010 18:34:44 - 1.18 +++ chat/chat.8 25 Jul 2011 15:08:18 - @@ -58,8 +58,12 @@ .It Fl S Do not use .Xr syslog 3 . -By default, error messages are logged via -.Xr syslog 3 . +By default, error messages are logged through +.Xr syslog 3 +with facility +.Ar local2 +and level +.Ar warning . The use of .Fl S will prevent both log messages from @@ -110,8 +114,10 @@ .Nm program will then log the execution state of the chat script as well as all text received from the modem and the output strings sent to the modem. -The default is to log via -.Xr syslog 3 ; +The default is to log through +.Xr syslog 3 +with level +.Ar info ; the logging method may be altered with the .Fl S and [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Gigabit Ethernet Controller compatibility with OpenBSD 4.9
On 25/07/2011, Stefan N stefanbsd...@yahoo.com wrote: The hardware support pages (at least for i386/amd64, I can't comment on the others) aren't as current or thorough as the man pages. A very quick check found that a number of the controllers are supported. 1.Realtek 8111C Gigabit Ethernet Controller This is mentioned in re(4) albeit not at the beginning http://www.openbsd.org/cgi-bin/man.cgi?query=rearch=i386sektion=4 2.Intel 82574L Gigabit Ethernet Controller 3.Intel 82567V Gigabit Ethernet Controller 4.Intel 82583V Gigabit Ethernet Controller 5.Intel 82574E Gigabit Ethernet Controller 6.Intel 82576 Gigabit Ethernet Controller Some of these are listed in em(4) as supported, others are not mentioned. While I'd be surprised if they're not supported I wouldn't count on it, especially as there are a number of other options which definitely are supported. http://www.openbsd.org/cgi-bin/man.cgi?query=emarch=i386sektion=4 7.Intel 82599ES 10Gigabit Ethernet Controller Supported according to ix(4) http://www.openbsd.org/cgi-bin/man.cgi?query=ixarch=i386sektion=4
Re: Gigabit Ethernet Controller compatibility with OpenBSD 4.9
On 25/07/2011, Glen Anderson g.s.ander...@gmail.com wrote: The hardware support pages (at least for i386/amd64, I can't comment on the others) aren't as current or thorough as the man pages. Of course if you're interested in support in a particular version you should check the appropriate man pages, not the versions in current that I linked to.
Re: em0: watchdog timeout with -current
On 22 July 2011 18:58, Sevan / Venture37 ventur...@gmail.com wrote: On 4 July 2011 21:32, Chris Smith obsd_m...@chrissmith.org wrote: Breakage happens with revision 1.258 (the MSI one), rev 1.257 and earlier work fine. Thanks to all who helped. Chris I'll try double check on mine next week as I experienced the same issues, I sent a follow up to bugs@ http://marc.info/?l=openbsd-bugsm=131135453411288w=2 So I reverted to if_em.c to rev1.257 rolled a new kernel, indeed this stops the watchdog error messages but interface is still useless, I experience high packet loss any replies which make it through have a very high RTT Sevan dmesg: OpenBSD 5.0-beta (GENERIC.MP) #0: Mon Jul 25 17:34:22 BST 2011 r...@t105-1.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4292673536 (4093MB) avail mem = 4164284416 (3971MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf0ba0 (48 entries) bios0: vendor Dell Inc. version 1.4.4 date 07/30/2009 bios0: Dell Inc. PowerEdge T105 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP TCPA SLIC SPCR EINJ HEST BERT SSDT ERST SRAT SSDT MCFG HPET APIC BOOT acpi0: wakeup devices PCI0(S5) USB0(S0) P2P0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-7 acpihpet0 at acpi0: 2500 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Dual-Core AMD Opteron(tm) Processor 1212, 2009.49 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Dual-Core AMD Opteron(tm) Processor 1212, 2009.26 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P2P0) acpiprt2 at acpi0: bus 5 (XVR0) acpiprt3 at acpi0: bus 4 (XVR1) acpiprt4 at acpi0: bus 3 (XVR2) acpiprt5 at acpi0: bus 2 (XVR3) acpicpu0 at acpi0: C3, C2, PSS acpicpu1 at acpi0: PSS acpibtn0 at acpi0: PWRB cpu0: PowerNow! K8 2009 MHz: speeds: 2000 1800 1000 MHz memory map conflict 0xcff6d000/0x11000 pci0 at mainbus0 bus 0 NVIDIA nForce4 DDR rev 0xa4 at pci0 dev 0 function 0 not configured pcib0 at pci0 dev 1 function 0 NVIDIA nForce4 ISA rev 0xf1 nviic0 at pci0 dev 1 function 1 NVIDIA nForce4 SMBus rev 0xa2 iic0 at nviic0 spdmem0 at iic0 addr 0x52: 2GB DDR2 SDRAM ECC PC2-5300CL5 spdmem1 at iic0 addr 0x53: 2GB DDR2 SDRAM ECC PC2-5300CL5 iic1 at nviic0 ohci0 at pci0 dev 2 function 0 NVIDIA nForce4 USB rev 0xa2: apic 2 int 20, version 1.0, legacy support ehci0 at pci0 dev 2 function 1 NVIDIA nForce4 USB rev 0xa4: apic 2 int 20 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 NVIDIA EHCI root hub rev 2.00/1.00 addr 1 pciide0 at pci0 dev 7 function 0 NVIDIA nForce4 SATA rev 0xf3: DMA pciide0: using apic 2 int 20 for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: WDC WD2500SD-01KCC0 wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6 wd1 at pciide0 channel 1 drive 0: WDC WD800JD-75MSA3 wd1: 16-sector PIO, LBA48, 76293MB, 15625 sectors wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 6 pciide1 at pci0 dev 8 function 0 NVIDIA nForce4 SATA rev 0xf3: DMA pciide1: using apic 2 int 20 for native-PCI interrupt atapiscsi0 at pciide1 channel 0 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: TSSTcorp, CDRWDVD TS-H493B, D200 ATAPI 5/cdrom removable cd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 2 ppb0 at pci0 dev 9 function 0 NVIDIA nForce4 PCI-PCI rev 0xf2 pci1 at ppb0 bus 1 vga1 at pci1 dev 8 function 0 ATI ES1000 rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: apic 2 int 16 drm0 at radeondrm0 ppb1 at pci0 dev 11 function 0 NVIDIA nForce4 PCIE rev 0xf3 pci2 at ppb1 bus 2 bge0 at pci2 dev 0 function 0 Broadcom BCM5722 rev 0x00, BCM5755 C0 (0xa200): apic 2 int 16, address 00:1d:09:22:8a:a6 brgphy0 at bge0 phy 1: BCM5722 10/100/1000baseT PHY, rev. 0 ppb2 at pci0 dev 12 function 0 NVIDIA nForce4 PCIE rev 0xf3 pci3 at ppb2 bus 3 ppb3 at pci0 dev 13 function 0 NVIDIA nForce4 PCIE rev 0xf3 pci4 at ppb3 bus 4 ppb4 at pci0 dev 14 function 0 NVIDIA
Re: xf86 driver won't compile
Brett wrote: I could not find any info on the openbsd site or mailing list on how to do this, except for radeon(4) man page, and this posting (for a different radeon card): It's not documented because it's not officially supported, it's replacing a shipped component with something that's newer.. 1) Do the lines above in the dmesg indicate this driver is already installed on my system? If so, is compiling a new driver likely to result in, for example, less frame dropping in mplayer fullscreen mode? The kernel support is for DRM/DRI support without KMS, modesetting and device initialization isn't done by the kernel. The driver mentioned in this thread is the userland Xorg driver, the verion shipped lacks features and stability on some newer cards.. in your case it will add Textured XVideo support. 2) Is this where I should get the code from?: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati You could, however that is the main development repository.. the source there does not have any generated configure script. You'll probably want to get it from here instead: http://ftp.x.org/pub/individual/driver/xf86-video-ati-6.14.2.tar.gz 3) Once compiled (using the configure options at the top of this email), is there some other configuration changes I need to make to the system, so this driver will load when I boot computer or startx? No, the X server should just load the new module.. you don't even have to reboot your system. 4) Is there any sites that I missed where this is already explained? ... -Bryan.
J - 15 !!!!!!!!!!
www.chienaplumes.fr [demime 1.01d removed an attachment of type image/jpeg which had a name of bandeau750x250_50dpi.jpg] [demime 1.01d removed an attachment of type image/png which had a name of fnac.png] [demime 1.01d removed an attachment of type image/jpeg which had a name of Ticketnet.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of couvpetite72.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of plage.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of facebook.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of Twitter.jpg] [demime 1.01d removed an attachment of type image/jpeg which had a name of dailymotion.jpg]
Re: [PATCH] chat(8) manpage clarification
On Mon, Jul 25, 2011 at 5:20 PM, Stefan Unterweger ste...@aleturo.com wrote: Hi! I've recently tried debugging a pppd(8) connection and noticed that the information in the chat(8) manpage was a little imprecise with regard to how logging is done. According to chat.c (lines 304 onward, from 4.9-release), it will log using facility LOCAL2 and level WARNING. If -v is specified, it will also log up to level INFO. I think it might be useful to include this information in the manpage as well; see patch below. Regards, s//un Index: chat/chat.8 === RCS file: /cvs/src/usr.sbin/pppd/chat/chat.8,v retrieving revision 1.18 diff -u -r1.18 chat.8 --- chat/chat.8 28 Oct 2010 18:34:44 - 1.18 +++ chat/chat.8 25 Jul 2011 15:08:18 - @@ -58,8 +58,12 @@ .It Fl S Do not use .Xr syslog 3 . -By default, error messages are logged via -.Xr syslog 3 . +By default, error messages are logged through +.Xr syslog 3 +with facility +.Ar local2 +and level +.Ar warning . The use of .Fl S will prevent both log messages from @@ -110,8 +114,10 @@ .Nm program will then log the execution state of the chat script as well as all text received from the modem and the output strings sent to the modem. -The default is to log via -.Xr syslog 3 ; +The default is to log through +.Xr syslog 3 +with level +.Ar info ; the logging method may be altered with the .Fl S and Having scratched my head around this in the past, I can say I like it. Ok for me. ciao, David
Re: [PATCH] chat(8) manpage clarification
On Mon, Jul 25, 2011 at 08:03:32PM +0200, David Coppa wrote: On Mon, Jul 25, 2011 at 5:20 PM, Stefan Unterweger ste...@aleturo.com wrote: Hi! I've recently tried debugging a pppd(8) connection and noticed that the information in the chat(8) manpage was a little imprecise with regard to how logging is done. According to chat.c (lines 304 onward, from 4.9-release), it will log using facility LOCAL2 and level WARNING. If -v is specified, it will also log up to level INFO. I think it might be useful to include this information in the manpage as well; see patch below. Regards, ? ?s//un Index: chat/chat.8 === RCS file: /cvs/src/usr.sbin/pppd/chat/chat.8,v retrieving revision 1.18 diff -u -r1.18 chat.8 --- chat/chat.8 28 Oct 2010 18:34:44 - ? ? ?1.18 +++ chat/chat.8 25 Jul 2011 15:08:18 - @@ -58,8 +58,12 @@ ?.It Fl S ?Do not use ?.Xr syslog 3 . -By default, error messages are logged via -.Xr syslog 3 . +By default, error messages are logged through +.Xr syslog 3 +with facility +.Ar local2 +and level +.Ar warning . ?The use of ?.Fl S ?will prevent both log messages from @@ -110,8 +114,10 @@ ?.Nm ?program will then log the execution state of the chat script as well as all ?text received from the modem and the output strings sent to the modem. -The default is to log via -.Xr syslog 3 ; +The default is to log through +.Xr syslog 3 +with level +.Ar info ; ?the logging method may be altered with the ?.Fl S ?and Having scratched my head around this in the past, I can say I like it. Ok for me. ciao, David i committed this with two tweaks: - i used Dq for the facility/level, since that seems more consistent with the syslog pages - i made a small wording tweak, for readability, that was unrelated to the diff jmc
PHP 5.3 on 4.9 (stable)
I'm getting this error, which I would have thought would have been cleaned up in the stable ports but doesn't seem to be. Has anyone else seen this or know if this a simple error of not updating a check file somwhere: Size does not match for /usr/ports/distfiles/php-5.3.5.tar.gz -- Devin M. Ceartas, owner NacreData L.L.C.
Re: PHP 5.3 on 4.9 (stable)
mistakes happen. fix is to do make makesum? gentle reminder: ports questions should go to ports@, not misc@ On Mon, Jul 25, 2011 at 2:36 PM, Devin Ceartas nacred...@gmail.com wrote: I'm getting this error, which I would have thought would have been cleaned up in the stable ports but doesn't seem to be. Has anyone else seen this or know if this a simple error of not updating a check file somwhere: Size does not match for /usr/ports/distfiles/php-5.3.5.tar.gz -- Devin M. Ceartas, owner NacreData L.L.C.
Re: PHP 5.3 on 4.9 (stable)
No, IIRC the mismatch is due to php website returning html page, fix is to add the actual path (something with attic or museum in it) to php/Makefile.inc, I can provide a patch soon if needed. You should probably CC maintainer too, and direct such problems at ports@ instead of misc@ On 25 juil. 2011 22:30, Amit Kulkarni amitk...@gmail.com wrote: mistakes happen. fix is to do make makesum? gentle reminder: ports questions should go to ports@, not misc@ On Mon, Jul 25, 2011 at 2:36 PM, Devin Ceartas nacred...@gmail.com wrote: I'm getting this error, which I would have thought would have been cleaned up in the stable ports but doesn't seem to be. Has anyone else seen this or know if this a simple error of not updating a check file somwhere: Size does not match for /usr/ports/distfiles/php-5.3.5.tar.gz -- Devin M. Ceartas, owner NacreData L.L.C.
Re: PHP 5.3 on 4.9 (stable)
OK, sorry to be off topic thanks for help; will give it a try. -- devin On Mon, Jul 25, 2011 at 4:52 PM, Thomas de Grivel billi...@gmail.comwrote: No, IIRC the mismatch is due to php website returning html page, fix is to add the actual path (something with attic or museum in it) to php/Makefile.inc, I can provide a patch soon if needed. You should probably CC maintainer too, and direct such problems at ports@ instead of misc@ On 25 juil. 2011 22:30, Amit Kulkarni amitk...@gmail.com wrote: mistakes happen. fix is to do make makesum? gentle reminder: ports questions should go to ports@, not misc@ On Mon, Jul 25, 2011 at 2:36 PM, Devin Ceartas nacred...@gmail.com wrote: I'm getting this error, which I would have thought would have been cleaned up in the stable ports but doesn't seem to be. Has anyone else seen this or know if this a simple error of not updating a check file somwhere: Size does not match for /usr/ports/distfiles/php-5.3.5.tar.gz -- Devin M. Ceartas, owner NacreData L.L.C. -- Devin M. Ceartas, owner NacreData L.L.C. nacred...@gmail.com i...@nacredata.com (919) 442-8899 AIM: nacredata skype IM: nacredata
Re: PHP 5.3 on 4.9 (stable)
On 2011-07-25, Devin Ceartas nacred...@gmail.com wrote: I'm getting this error, which I would have thought would have been cleaned up in the stable ports but doesn't seem to be. Has anyone else seen this or know if this a simple error of not updating a check file somwhere: Size does not match for /usr/ports/distfiles/php-5.3.5.tar.gz php 5.3 is not in 4.9 / -stable.
Re: PHP 5.3 on 4.9 (stable)
On Mon, Jul 25, 2011 at 15:36, Devin Ceartas nacred...@gmail.com wrote: I'm getting this error, which I would have thought would have been cleaned up in the stable ports but doesn't seem to be. Has anyone else seen this or know if this a simple error of not updating a check file somwhere: Size does not match for /usr/ports/distfiles/php-5.3.5.tar.gz snip Your system is not in sync. See FAQ 15.4.1: http://www.openbsd.org/faq/faq15.html#NoFun I'm getting all kinds of crazy errors. I just can't seem to get this ports stuff working at all. It is very likely that you are using a system and ports tree which are not in sync.
Re: PHP 5.3 on 4.9 (stable)
How can I be out of sync if I just updated both the system and the ports collection to stable from CD? I'm not upgrading or doing something else which would lead to being out of sync. I find /usr/ports/lang/php/5.3 as well as /usr/ports/lang/php/5.2 in the 4.9 stable ports tree (cd /usr; cvs checkout -P -rOPENBSD_4_9 ports) Now I'm confused devin On Mon, Jul 25, 2011 at 9:25 PM, vovka net.v...@gmail.com wrote: On Mon, Jul 25, 2011 at 15:36, Devin Ceartas nacred...@gmail.com wrote: I'm getting this error, which I would have thought would have been cleaned up in the stable ports but doesn't seem to be. Has anyone else seen this or know if this a simple error of not updating a check file somwhere: Size does not match for /usr/ports/distfiles/php-5.3.5.tar.gz snip Your system is not in sync. See FAQ 15.4.1: http://www.openbsd.org/faq/faq15.html#NoFun I'm getting all kinds of crazy errors. I just can't seem to get this ports stuff working at all. It is very likely that you are using a system and ports tree which are not in sync. -- Devin M. Ceartas, owner NacreData L.L.C. nacred...@gmail.com i...@nacredata.com (919) 442-8899 AIM: nacredata skype IM: nacredata
HOY PUEDE EDITAR SUS LIBROS-julio 2011-
Ediciones Pasisn de Escritores Impresisn sobre demanda Impresiones cortas Reediciones HOY PUEDE EDITAR SU OBRA EL MEJOR PRECIO DEL MERCADO Promocisn julio-2011 Tamaqo: 14 x 20 Tapas a 4 colores Sobre papel ilustracisn de 300g Laminado en opp brillante Interior Blanco y negro En papel Obra 75/80g extra blanco Encuadernacisn Binder 50Libros de 60paginas: Precio final de impresisn$ 540.- Solicite presupuesto en formatos: 14x2015x215.5x23 16x2417x2520x2821x28 Nuestros servicios Ediciones sobre demanda Reedicisn de publicaciones desde 25 ejemplares Prueba de galera Tramitacisn sin cargo del ISBN - Tasa a cargo del escritor Tramitacisn sin cargo - Ley 11723 - Tasa a cargo del escritor Servicios opcionales Diseqo de tapas Servicio de correccisn Maquetado Nuestras ediciones se abonan en 3 cuotas Solicite informacisn a: consultaedic...@pasiondeescritores.com.ar www.pasiondeescritores.com.ar NOTA IMPORTANTE: Si no desea recibir informacisn en el futuro, le rogamos enviar un mail para ser removido. Este mail no es un SPAMpues incluye un medio de remocisn, conforme las disposiciones del Decreto 5.1618 . Tmtulo 3 #, aprobado por el Congreso base de las normativas internacionales sobre SPAM. [demime 1.01d removed an attachment of type image/jpeg which had a name of logofirma.jpg]
Re: PHP 5.3 on 4.9 (stable)
On 25-Jul-11 19:02, Devin Ceartas wrote: How can I be out of sync if I just updated both the system and the ports collection to stable from CD? I'm not upgrading or doing something else which would lead to being out of sync. I find /usr/ports/lang/php/5.3 as well as /usr/ports/lang/php/5.2 in the 4.9 stable ports tree (cd /usr; cvs checkout -P -rOPENBSD_4_9 ports) Now I'm confused devin The CD is the -release branch, not stable. Also what is the exact path you are using to grab the bits to ports? Depending on where you are getting them, the bits may be for -current, which is months ahead of -release
Re: PHP 5.3 on 4.9 (stable)
On Mon, Jul 25, 2011 at 08:10:23PM -0700, LeviaComm Networks wrote: On 25-Jul-11 19:02, Devin Ceartas wrote: How can I be out of sync if I just updated both the system and the ports collection to stable from CD? I'm not upgrading or doing something else which would lead to being out of sync. I find /usr/ports/lang/php/5.3 as well as /usr/ports/lang/php/5.2 in the 4.9 stable ports tree (cd /usr; cvs checkout -P -rOPENBSD_4_9 ports) Now I'm confused devin The CD is the -release branch, not stable. Also what is the exact path you are using to grab the bits to ports? Depending on where you are getting them, the bits may be for -current, which is months ahead of -release Yes, the 5.3 dir is in the tree of 4.9, but it is not linked to the build. Only in 5.0 it will be. -Otto
