RE: userland ppp - startup
-Original Message- From: Josef Karthauser [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, July 07, 1999 1:22 PM To: Ladavac Marino Cc: Brian Somers; Mark Thomas; [EMAIL PROTECTED]; Wayne Self Subject: Re: userland ppp - startup On Wed, Jul 07, 1999 at 12:20:35PM +0200, Ladavac Marino wrote: [ML] Don't know about sppp, but the only halfway secure way to keep this sensitive data is in a file readable by root, and having the program which needs it setuid root. Sounds a lot like /etc/ppp/ppp.conf, doesn't it? The secure way would be not keeping the info at all :) It does :) That said doesn't sysinstall using ppp to do a net install? How does it setup username/password, etc. [ML] It asks for it in a dialog box, IIRC (never having used it :) /Marino Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: wide char support
-Original Message- From: Chuck Robey [SMTP:chu...@picnic.mat.net] Sent: Monday, June 07, 1999 6:32 PM To: ito...@iijlab.net Cc: David E. Cross; freebsd-current@FreeBSD.ORG Subject: Re: wide char support May you both live in interesting times! [ML] No, not that curse! Everyone, flee the Agatean Empire! /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Building www/en
-Original Message- From: Peter Jeremy [SMTP:jere...@gsmx07.alcatel.com.au] Sent: Monday, June 07, 1999 11:41 PM To: freebsd-current@FreeBSD.ORG Subject: Building www/en Part of my regular rebuild is a `cd www/en; make -DENGLISH_ONLY' My question is: How do I create /usr/local/share/sgml/docbook/catalog ? It doesn't exist in any of the ports. [ML] IIRC, mkdir /usr/local/share/sgml/docbook/catalog should suffice. It's been a while, though, since I've had a FreeBSD box with SGML toolchain. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: IRQ sharing with newbus
-Original Message- From: Garrett Wollman [SMTP:woll...@khavrinen.lcs.mit.edu] Sent: Wednesday, June 02, 1999 9:13 PM To: Bruce Evans Cc: d...@nlsystems.com; woll...@khavrinen.lcs.mit.edu; curr...@freebsd.org; new...@atdot.dotat.org Subject: Re: IRQ sharing with newbus On Wed, 2 Jun 1999 16:17:36 +1000, Bruce Evans b...@zeta.org.au said: But the sio non-multiport stuff should be able to use RF_TIMESHARE. -- If I'm not using my serial port, I should be able to use my infrared Preemptive timesharing would be hard to implement reasonably for irqs. A uniform timeslice would have to be 86 usec to work properly for unbuffered sio devices at 115200 bps. You're talking intervals about six orders of magnitude smaller than I am. [ML] If I understand you correctly, you want to resource track the IRQ's so if one device that uses one particular IRQ is active, another one cannot be activated? Example: I have a modem on sio1 and digicam on sio3 (both on IRQ3). I can either use my modem or download the photos, but not both at the same time. That would be nice. I don't known whether this is already supported as I don't have sio3 :) (I don't have sio1 either :) /Marino -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: FTP passive mode - a new default?
-Original Message- From: Nick Hibma [SMTP:nick.hi...@jrc.it] Sent: Wednesday, May 26, 1999 1:38 PM To: Jordan K. Hubbard Cc: curr...@freebsd.org Subject: Re: FTP passive mode - a new default? Is there a list of pro-/cons- available? - it is slower, but by how much and on which types of lines (low/high latency, low/high bandwidth)? [ML] same speed. passive means that the client (and not the server) opens the data connection. advantageous for people sitting behind packet or nat firewalls. - any (windows) tools not supporting it? [ML] this is an ftp client request. some ancient ftp servers may not support passive data connections, but I haven't seen one of those in a long while. I don't know whether the windows ftpd is incapable of passive mode. actually, if the passive mode default is implemented correctly, the client should send PASV and if the server accepts it proceed, otherwise remain in active mode (and if you are behind a nat or a firewall you are no worse off than you already were). /Marino Nick Unless I hear unanimous fierce outcry against it, I'm strongly considering making FTP_PASSIVE_MODE obsolete by virtue of being the default for all tools/libraries which currently examine it. FTP_ACTIVE_MODE will be the new flag for toggling the previous behavior. Given the state of the Internet today, I think this is purely a sensible change in defaults. Comments? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: priorities
-Original Message- From: Doug White [SMTP:dwh...@resnet.uoregon.edu] Sent: Sunday, May 23, 1999 2:46 AM To: Doug Rabson Cc: FreeBSD current Mailing list Subject: Re: priorities On Fri, 21 May 1999, Doug Rabson wrote: If you've worked on Windows or Macs, you know what I'm talking about (Device failure or Could not switch your connection due to an error). [ML] Or my all-time-favorite from Excel: File was not saved. /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: swap on Irix (overcommiting, etc.)
-Original Message- From: Matthew Dillon [SMTP:dil...@apollo.backplane.com] Sent: Thursday, April 15, 1999 9:38 PM To: Mikhail Teterin Cc: curr...@freebsd.org Subject: Re: swap on Irix (overcommiting, etc.) If some of you are wondering why some of us are saying this guarenteeing of memory is a crap argument, it's because it *IS* a crap argument. [ML] hey, I know it's a crap argument, that's why I did not raise any objections concerning memory overcommit (even though I am the one who has read the STDC document in an anal-retentive manner regarding malloc failures). One simply has to allocate sufficient swap so that the processes do not get killed before the machine swaps itself to death :) In my experience, this is about 5xRAM for a smallish desktop, 1xRAM for a database server (but do not let any badly behaved programs run on the latter machine). There is a feature of HPUX (and I think SINIX and Solaris as well) that they are capable of potentially swapping into a mounted filesystem. The actual filesystem swapping is very slow, and is used by the system as the last resort only--merely, swap is reserved there (reserved in the sense that the systems idea of free space in the filesystem is reduced by (a fraction of) the reserved amount i.e. the system keeps statistics about how much VM would have been needed if no overcommit were used, how much of the swap was really used, and how much of the filesystem swap was actually used). If the sysadmin ever sees non-zero actual filesystem swap usage, he better increases RAM/swap. Alas, I do not quite know whether this feature were possible in FreeBSD, or how hard would it be to implement it. It does not really solve anything, but it brings you somewhat further along. OTOH, just normal swap monitoring on FreeBSD provides you with the same information, and is practically as safe (okay, the filesystem swappers have an emergency swap area as well, which means that they can err on the low side with actual swap, but this doesn't really bring anything.) /Marino (who really did not expect this thread will explode so :) -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: swap-related problems
-Original Message- From: Mikhail Teterin [SMTP:m...@misha.cisco.com] Sent: Wednesday, April 14, 1999 12:45 AM To: curr...@freebsd.org Subject: Re: swap-related problems Well, this is just an implementation detail, is not it? I don't mean to critisize, or anything, but such thing as no available memory is a fairly intuitive... Coming down, again, the malloc should return a usable memory if available and NULL if it's not. Is not this a natural semantics? Why can a program die because _another_ program ate up all the rest of the memory? [ML] This is a common problem for any OS that implements memory overcommit. This means that it is not possible to detect an out-of-swap condition sinchronously as the swap is reserved only when the pages are dirtied and not when brk is grown. This means that you can set brk a gigabyte higher (given that your user limits allow that), and you will not be using swap as long as you do not write to the pages you allocated to the process. Another strategy is to reserve the swap space as soon as it is allocated by the program. This strategy is much more conservative and inherently safer, but it needs much more space: for instance, if you have a program with WSS of a gigabyte and you want to system( date ), you will need at least 2 gigs of swap because system() does fork() first which means that you get 2 copies of your big program and the system cannot know that in one of the copies an exec() will be shortly forthcoming--thus, it has to reserve the full WSS for the copy because it will potentially write to all pages of its WSS. It would be nice if memory overcommit were configurable (on-off, or per process). /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: swap-related problems
-Original Message- From: Daniel C. Sobral [SMTP:d...@newsguy.com] Sent: Wednesday, April 14, 1999 3:04 PM To: Ladavac Marino Cc: 'm...@aldan.algebra.com'; curr...@freebsd.org Subject: Re: swap-related problems Ladavac Marino wrote: Another strategy is to reserve the swap space as soon as it is allocated by the program. This strategy is much more conservative and inherently safer, but it needs much more space: for instance, if you have a program with WSS of a gigabyte and you want to system( date ), you will need at least 2 gigs of swap because system() does fork() first which means that you get 2 copies of your big program and the system cannot know that in one of the copies an exec() will be shortly forthcoming--thus, it has to reserve the full WSS for the copy because it will potentially write to all pages of its WSS. It would be nice if memory overcommit were configurable (on-off, or per process). On AIX, you can have it set as a global option and on/off per process. In my experience, though, setting it to off never solved anything: if you need memory, you have to add memory. [ML] Oh, memory overcommit does have its applications. Remember the olden days of FORTRAN when dynamic memory allocation was a meaningless term :) Overcommit let the people allocate a 1*1 matrix and use only a 20*20 subset of it and have program execute instead of fail out-of-swap. Nowadays, vfork() could solve most of the problems on fork/exec. Sadly, a frightening number of unices implement vfork() as #define vfork fork /Marino -- Daniel C. Sobral (8-DCS) d...@newsguy.com d...@freebsd.org nothing better than the ability to perform cunning linguistics To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: swap-related problems
-Original Message- From: Mikhail Teterin [SMTP:m...@kot.ne.mediaone.net] Sent: Wednesday, April 14, 1999 5:01 PM To: curr...@freebsd.org Subject: Re: swap-related problems They then, rightfully exclaimed: . but should not malloc() have returned me NULL? And the rest is drowned in the explanations of why it is very hard to assure. I'm repeating myself here and so do others. We are probably facing the major disadvantange of the overcommit strategy, and there may not, indeed, be a way around this. [ML] Short of disabling memory overcommit, no there is no answer. If you do disable overcommit, prepare to add humongous swap areas (or maybe not--some unices reserve the pages in the filesystem, stealing the free blocks, so to say, but write the dirty pages to the swap partitions. They also keep 2 counters: swap pages reserved, and swap pages actually used. They are capable of swapping into a filesystem should the need actually arise, but are very inefficient in doing so. However, having both numbers--swap reserved and swap used--allows the sysadmin to properly size the swap partitions). Documenting this properly is what is definitely in order... [ML] I would agree to this. Perhaps in the IMPLEMENTATION section of the corresponding manpages (malloc, s/brk, fork.) While we are at this, what is the right way to find out if the returned pointer can be used? [ML] Sadly, in the memory overcommit situation, there is no way to know whether a pointer returned by malloc will cause a process demise or not. The pointer is valid, but the swap area mapping is defered until the page is dirtied (basically, the pointer points to a readonly zero filled physical page and on write the trap handler tries to allocate a backing swap area for the page. If the swap is exhausted, the handler eventually fails. What the system does at this time is irrelevant. Please note that memory overcommit architectures are a rather common optimization; FreeBSD is one of them. They do, however, break the ISO/ANSI C conformance (strictly speaking). /Marino -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: DoS from local users (fwd)
-Original Message- From: Amancio Hasty [SMTP:ha...@rah.star-gate.com] Sent: Sunday, April 11, 1999 5:36 AM To: Matthew Dillon Cc: Dmitry Valdov; Brian Feldman; freebsd-current@FreeBSD.ORG Subject: Re: DoS from local users (fwd) I guess any sufficiently advance science is indeed consider magic by some. Amancio [ML] Then I would like to have a high-tech gizmo for reading my users' minds. Would you, perhaps, know where I could buy/borrow/steal one of these? :) /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Games
-Original Message- From: Daniel C. Sobral [SMTP:d...@newsguy.com] Sent: Thursday, April 01, 1999 1:14 PM To: Alexander Leidinger Cc: curr...@freebsd.org; tr49...@rcc.on.ca Subject: Re: Games Alexander Leidinger wrote: On 1 Apr, Daniel C. Sobral wrote: Well, first of all, .profile, .cshrc and signature scripts are broken in the absense of fortune. If I remember correctly .cshrc contains [ -x /usr/games/fortune ] ... so this shouldn't be an issue. Well, some people seem to be able to survive without fortune, but that's probably the exception to the rule... :-) [ML] Oh, I can live without fortune(6), but pom(6) was invaluable in software malfunction diagnosis: luser: My program fails when I do this or that. me: types pom No wonder, the moon is 73% full. /Marino -- Daniel C. Sobral (8-DCS) d...@newsguy.com d...@freebsd.org nothing better than the ability to perform cunning linguistics To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: UPDATE4: ATA/ATAPI driver new version available.
-Original Message- From: Soren Schmidt [SMTP:s...@freebsd.dk] Sent: Tuesday, March 30, 1999 1:29 PM To: sobo...@altavista.net Cc: curr...@freebsd.org Subject: Re: UPDATE4: ATA/ATAPI driver new version available. It seems Maxim Sobolev wrote: New ata driver (cvsup'ed several minutes ago) locks my box solid (only reset but ton can help). Bug is fully reproducible on my machine (Toshiba Satellite Pro 445). I using the following command: dd if=/dev/zero of=/dev/ad0s2 bs=1024k. It works several minutes then IDE led turns off and box freezes. Interesting that when I looking at systat -vm measures, performance constantly degrades from 3.3MB/s to 2.5MB/s. Bug exist either in single-user and in multi-user mode. Following is relevant dmesg pieces from my dmesg output: Hmm, are you sure you want to WRITE all those zeros to your disk ?? However it should not hang before the end of disk is reached that is. Have you tried reading all of the disk instead, does that hang ?? The degradation is probably becuse the transferrate of the disk slows down as you get closer to the center of the disk. Have you anu idea on how much data is transferred ?? how long is it running ?? [ML] Also, is there any swapping area on that slice? Because if there is and kernel has been told to use it (AFAIR swapon happens even in single user mode) you have just obliterated the kernel pages (kernel is pageable these days IIRC, at least the data if not the code). /Marino -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE:
-Original Message- From: Sheldon Hearn [SMTP:sheld...@iafrica.com] Sent: Tuesday, March 30, 1999 3:47 PM To: ca...@avias.com Cc: freebsd-current@freebsd.org Subject: Re: On Tue, 30 Mar 1999 17:28:06 +0400, Ilya Naumov wrote: i wonder what is the situation with AIC driver now? we're suffering without it :) All traces of it have been completely removed from CURRENT. [ML] Hey, not all is lost. You can still use your 1510 as an el-cheapo external SCSI case connector. What I did after my ancient 386SX-16 died was to throw away the motherboard and use the case as a 5-bay case (it was a midi-tower). The 1510 came in handy because it was cheaper than the ribbon-to-50-pin-D SCSI adapter. Of course I did not bother to power the card :) /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: repeated ufs_dirbad() panics on 4.0-c
-Original Message- From: Ollivier Robert [SMTP:robe...@keltia.freenix.fr] Sent: Thursday, March 18, 1999 12:26 AM To: curr...@freebsd.org Subject: Re: repeated ufs_dirbad() panics on 4.0-c According to Mikhail A. Sokolov: nope /dev/da1e17235735 7414244 844263347%/mnt/arc /dev/da2e 8617355 1724705 689265020% /mnt/spool1 /dev/da3e 8617355 1723638 689371720% /mnt/spool2 disklabel output is what you want to send us, df is not enough :-) [ML] In his case it is, because if you take a very careful look, you will see that he's using the e compatibility partition on three separate disks :) So, it's probably not overlapping, but the compatibility that may cause problems. /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: disk quota overriding
-Original Message- From: Dmitry Valdov [SMTP:d...@dv.ru] Sent: Wednesday, March 17, 1999 1:37 PM To: freebsd-current@freebsd.org; freebsd-secur...@freebsd.org Subject: Re: disk quota overriding Hi! I think that there is only one way to fix it - it's to disable making *hard*links to directory with mode 1777. [ML] But only if the quotas have been turned on. BTW, has chown been fixed to the ludicrous SysV semantics that the root and owner can chown a file? If so, the latter has to be disabled in presence of quotas on the volume--otherwise: touch big_file chmod 777 big_file chown root:wheel big_file cat /dev/zero big_file This joke used to work on HPUX 10.something which kept the owner-may-chown semantics even in presence of quotas. It was not funny. (I don't know whether HP has fixed that). /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Simple DOS against 3.x locks box solid
-Original Message- From: Peter Jeremy [SMTP:peter.jer...@auss2.alcatel.com.au] Sent: Friday, March 05, 1999 4:25 AM To: dil...@apollo.backplane.com Cc: curr...@freebsd.org Subject: Re: Simple DOS against 3.x locks box solid As for the general problem, is it sensible to allow a read-only file to be mmap'd R/W (with or without MAP_PRIVATE) and then written into? It would be fairly easy to make mmap() return EACCES if the fd was not open for writing (or map the memory R/O and SEGV on a write). [ML] Can you say dlopen( /usr/lib/libc.so)? I thought you could :) Disallow RW MAP_PRIVATE maps of RO files and shared libraries are history. /Marino Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: ATAPI and ATAPI_STATIC with the new ATA* driver?
-Original Message- From: Sheldon Hearn [SMTP:sheld...@iafrica.com] Sent: Wednesday, March 03, 1999 1:40 PM To: Cejka Rudolf Cc: freebsd-current@freebsd.org; s...@freebsd.dk Subject: Re: ATAPI and ATAPI_STATIC with the new ATA* driver? I'm not sure I understand what real-world frustrations people are having here. Is this thread the product of reactionary criticism, or are there real examples of situations in which there are serious disadvantages to the way Soren has things working? [ML] Well, it's for those people who plug a drive occasionally into a computer. They don't want other drives moved around. This is the situation that the external SCSI disc case owners live with for years now, and was the reason device wiring was introduced for SCSI devices. Soeren said that the same mechanism could be added for atapi devices as well (yet better, extended to include the atapi devices as well). He just doesn't currently have time to do it right now. /Marino Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: IDE CDROM not found with PIIX4 chipset, -current kernel
-Original Message- From: Sheldon Hearn [SMTP:sheld...@iafrica.com] Sent: Thursday, February 25, 1999 5:40 PM To: Pierre Beyssac Cc: Greg Lehey; freebsd-current@FreeBSD.ORG Subject: Re: IDE CDROM not found with PIIX4 chipset, -current kernel On Thu, 25 Feb 1999 17:16:53 +0100, Pierre Beyssac wrote: I tried to find out why it worked with a Linux kernel by comparing our IDE code and theirs, but it was way beyond my comprehension. I'm not trained for the black magic of IDE probing. I used this particular issue for the launch of my first adventure into serial console kernel debugging. Multo fun. I can offer you two interesting points: 1) I have an ATAPI drive that FreeBSD 2.2-STABLE won't detect on boot if it contains a disc. 2) I found that stepping through the kernel caused exactly the same problems I was having with accessing my one ATAPI drive that I experience just running normally with my other drive. So it looks like at least one problem regarding ATAPI has to do with timings. So far, the conversations I've had with clueful FreeBSD hackers have led me to accept the following: A) The ATAPI standard is weak and the variety of implimentations thereof is even worse. B) The odds that your ATAPI CDROM drive will behave predictably in accordance with said standards are directly proportional to its age. It seems that newer (24xspeed+) drives suck. C) The ATAPI code in FreeBSD is about as good as our hackers care to make it, given the demotivating impact of A and B above. I spent a good few days stepping around my kernel over serial connection, using a working 4xspeed drive and a broken 36xspeed drive and testing a reproducible fault with cdcontrol. I'm a pretty stubborn guy, but I gave up. [ML] Heh, it would seem that the prevailing OS is not really ATAPI compliant and the manufacturers try to make their hardware more easily detectable for the prevailing OS family. How about this brilliant idea: put a logic analyzer on the IDE cable and measure the timings the prevailing OS family/BIOS uses? Sadly, I don't have access to a logic analyzer :( Anyone with (good) connections to a (university) hardware lab? /Marino Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Need Help
HI I have a trouble with FreeBSD 2.1.5 [ML] 2.1.5 is hardly current (it used to be, some years ago :) After a mistyped rm :( when i try some commands like ps or netstat i got this message: [ML] Careful with those thumbs when you run as root :) ps: /dev/drum: No such file or directory [ML] An obsolete device (would have to take a look at 2.1.5 sources to be able to tell you what it was. IIRC, it used to be swap in Version7 days) What does it mean ? [ML] That means that most probably all your device nodes are gone, and that you should cd /dev ./MAKEDEV in order to try to recreate them. Beware, most probably this will not help very much because who knows what else did you delete -- was it perchance a rm -rf * in / ? How can i fix it? [ML] Reinstall is really your only option. Followed by the restore so that you get back all the user files. You do make backups, don't you? The system still run .. for the moment..(sob). [ML] But will probably fail to reboot. It might manage to mount /, but the other partitions are most probably unreachable. Please Help!! [ML] Don't run as root. And be very careful when you do. [ML] /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: locale errors
-Original Message- From: D. Rock [SMTP:r...@cs.uni-sb.de] Sent: Thursday, February 04, 1999 10:36 AM To: Joerg Wunsch Cc: Andrey A. Chernov; curr...@freebsd.org Subject: Re: locale errors It is impossible. The collate couldn't detect concatenated words, which sould sort the usual way: aussetzen austreiben (just a simple example) [ML] Shouldn't ß (scharfes-s, sz) be collated as SZ which it really is? /Marino I noticed the difference while looking into the /R/dist/src directory during a make release. ssys.XX was sorted behind susrbin.XX in ls output. I suggest just backing out the stuff with multi character locale settings because it is bogus. We should just use the simple phonebook sorting, because it is easier to implement, and the people are more familiar with it. Duden isn't always right (very true since last year for some parts in northern Germany) Daniel P.S. Solaris does sorting the easy way (at least for LC_COLLATE=de.ISO8859-15 and LC_COLLATE=de) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: btokup().. patch to STYLE(9) (fwd)
-Original Message-
From: Mikhail Teterin [SMTP:m...@misha.cisco.com]
Sent: Monday, February 01, 1999 9:41 PM
To: curr...@freebsd.org
Subject: Re: btokup().. patch to STYLE(9) (fwd)
=Whilst the official codebase may be under the control of a select
=group of committers, the code should be capable of being understood
by
=anyone who is reasonably proficient with C.
Depends on your definition of reasonably, Mr. Special Counselor...
[ML]
I see no cause for name calling.
A Reasonably Proficient programmer is the one who
writes correct code. The one who writes maintainable
correct code is Very Proficient. The one who writes
well-documented maintainable correct code is a target
for a marriage proposal :)
Sadly, few proficient programmers program exclusively
in C/C++. Most of us have bills to pay and switch on
a drop of a hat from C to PL/I to COBOL to VisualBASIC
to Perl to FORTRAN to YouNameIt to ...
And, guess what, none of these languages have the same
operator precedence as C/C++. But they all have
parentheses. Knowledge of operator precedence as a
metric of programming proficience--ludicrous. My brain
would turn to pretzel if I had to know all the precedence
rules in all the languages that I daily have to use.
So, yes, I do use parentheses relying on assocciativity
only around addition/multiplication. Logical expressions
are handled differently in every language--some of them
do not even have short-circuiting logical operators--thus,
they will be parenthesized.
An example that was being thrown around would look like
this in my code:
/* the reason for branching */
if ( (a * b - c * d) (e / f) ) {
true_part();
}
else {
false_part();
more_false_part();
}
You will have noticed that I put braces around single
statements. This has no performance penalty--a reasonable
compiler will not create a stack frame--and helps in
maintenance.
/* copy null-terminated b to a */
for (pa = a, pb = b; (*pa = *pb) != 0; ++pa, ++pb) {
/* NOTHING */
}
Same thing here--okay, so it is a bit more verbose than
absolutely neccessary. The advantage is that the people
who are not absolutely acquainted with the syntactical
finesse of the language *can* read it and can actually
*modify* it without undue hassle.
That's what is being tirelessly debated for the last several days.
[ML] Hopefully we will come to agreement about a
reasonable metric for programmer proficiency (and
when I am at that, I can also hope for a jackpot in
lottery :)
/Marino
-mi
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
RE: btokup().. patch to STYLE(9) (fwd)
-Original Message- From: John Saunders [SMTP:john.saund...@nlc.net.au] Sent: Monday, February 01, 1999 10:53 AM To: freebsd-current@FreeBSD.ORG Cc: Dan Swartzendruber Subject: Re: btokup().. patch to STYLE(9) (fwd) In nlc.lists.freebsd-current you wrote: At 12:09 PM 2/1/99 +1100, Gregory Bond wrote: You are not supposed to understand this. You are not expected to understand this. It's inside the swtch() function call. Just having a quick look now. Inside expand(), where core is allocated for a process, if no core is available the process is swapped out with a call to xswap(), then switched out with a call to swtch(). When core becomes available and the process image is read in from swap, the process will be selected by swtch() to become runnable. However with the current context, swtch() would return and the tail end of the expand() function would execute. So inside expand() a call is made to save the stack state so that when swtch() restores this state, the return skips over the expand() function entirely. [ML] I don't understand that. But, then again, I am not supposed to :) P.S I did understand it, but it was too good an opportunitiy to miss. /Marino To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
