Re: gcc ABI compliance (was: Re: Memory Mangement Problem in5.1-RELEASE)
On Sat, 26 Jul 2003, Alexander Leidinger wrote: On Fri, 25 Jul 2003 23:22:00 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Didn't the GNU people say they had to change it to be more ABI compliant with the 'standard'? I will believe that when they upgrade their FORTRAN compiler to be more compliant with 'the standard'. Some standards are not worth complying with; I still have yet to see anyone tell me exactly what the practical benefit of doing this is. When X (X 1) compilers comply to the same ABI standard, I can mix the results of those compilers (if I see a benefit to do so). As we have icc in the ports collection and the base system is compiled with gcc and I want to be able to link to gcc compiled libs with icc, I appreciate the effort of the involved parties to try to comply to a common ABI standard. That might be so over in your reality, but over in this really there is tonns of paisn due to the changes and changing libstdc++.so major. Lets not get into promises about ABI stability Bye, Alexander. -- I believe the technical term is Oops! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Native JDK with libthr/libkse
On Mon, 2 Jun 2003, Sheldon Hearn wrote: On (2003/06/01 23:53), Narvi wrote: The absence of credible Java support in FreeBSD has lost us significant penetration in the past, and it would be disastrous if the perceptions of the past shaped the future. credible rather sounds like 'comes on the installation cd, doesn't have significantly more bugs than linux/solaris/xxx version' 8-( And I think we'll get there. I would really hope so, its increasingly a barrier. I'm currently doing some Java development on a FreeBSD-CURRENT workstation using a native jdk14. It's good enough for testing components in a J2EE application server (JBoss), and performance is comparable to that seen on an equivalent Windows workstation. java is not all just j2ee, though its an increasingly important niche. The developer side is probably in the short term more important than the number of servers deployed using it. Would I use FreeBSD as a production J2EE server reliant on 1.4.1? No. But the time is coming, so don't write FreeBSD off just yet. oh, i'm not writing off freebsd, its just not as ready in this regard as competition. Running production j2ee servers is a level above having a useful / credible java story - it would probably be something you'd do on 5.3 with a good jdk. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Native JDK with libthr/libkse
On Sun, 1 Jun 2003, Sheldon Hearn wrote: On (2003/06/01 00:50), Daniel Eischen wrote: I just built jdk13 a couple of days ago. No problem whatsoever. You guys must have rotten karma or something. Did you already have a native JDK installed? I built the native 1.4.1 JDK two weeks ago, first without the native JDK for bootstrapping, and then with the native JDK. Both worked without a hitch. If you're having problems with the build, your input would be appreciated on freebsd-java. The absence of credible Java support in FreeBSD has lost us significant penetration in the past, and it would be disastrous if the perceptions of the past shaped the future. credible rather sounds like 'comes on the installation cd, doesn't have significantly more bugs than linux/solaris/xxx version' 8-( FreeBSD now has some seriously committed Java people working hard on the port, and it'd be a shame if they didn't get to hear about the problem you've encountered. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
On Thu, 29 May 2003, [iso-8859-1] Thorsten Futrega wrote: Dear users, The most important changes I'm going to commit today: - Remove gcc and replace it with a new TenDRA snapshot. yay! but what about c++ support? - Remove GNU tar. double yay! - Fix httpd.ko to make it work on buggy AMD processors. - Drop support for 386 and 486 cpus. - Remove ext2 support (GPL encumbered). - Add perl 5.8 *and* python 2.2 to base. - Remove Sendmail and replace it with Postfix. mostly yawn... If anyone has any reason why these should not be committed, I'll give a 5 hours grace time. Send replies to the list. Thank you. Thorsten and the rest or the release engineering team. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
On Fri, 30 May 2003, Narvi wrote: [snip] Ahem.. i am very embarrassed about having sent the reply, everybody please pretend I was nowhere near the thread, pretty please? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Wed, 28 May 2003, Marcin Dalecki wrote: Harti Brandt wrote: MDNO no and again no. This would repeat the same design mistake MDthat is already in Linux. On API level you DO NOT WANT versioning. MDWhat you really want is: type signature cheking. Like for example MDdone through C++ symbol mangling rules. If you can't do it like that MDthen better leave it off as it is. Versioning in itself Type signature checking doesn't help you if the semantics of an API change without type changes. APIs should be semantically and syntactically stable in -STABLE. In -CURRENT they are expected to change. Managing a 3rd party driver for current is a nightmare, but may no be necessary once we have a -STABLE based on FreeBSD5. Sure sure. Perhaps I wasn't clear enough. Versioning doesn't help you *anything* at all, but it is introducing new problems instead. Tons of them in fact, if one looks at the Linux pain in this area. I suggested type signature cheking in C++ style just to show how fundamentally flawed the idea of version cheking is, but I can perfectly life with the situation as it is. Uhh... it is not true that versioning does not help anything at all. i'm not sure what type signatures would help you with - knowing that foo(int, void *) still has teh same siganture doesn't tell you anything about what must be passed in as values what assumptions about call order with bar(void *) exist or anything else. Symbol versioning is good to implement multi-flavoured single binary objects (glibc uses it this way) and *not* for interface cheking. Again my main point is versioning on the symbol level simply makes no sense and worsens the situation. It's the fundamentally wrong approach to the actual problem. The fact that Linux does something like this is only showing that Alan Cox and Keith Owens didn't get it either and one shouldn't repeat the mistake. uhhh... symbol versioning != library versioning and really, in case of glibc is pretty useless, very few if any glibc 2.2 progarms woiuld actually run on a 2.1 system, making it all pretty pointless No more no less. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tue, 27 May 2003, Scott Long wrote: Q wrote: I have been burnt by this in the past also. I think that it would be useful if you could allow kernel modules to be bound to a particular kernel version/date/whatever, and have external modules refuse to load and/or complain if the kernel is upgraded. This should prevent unnecessary kernel panics when you upgrade. The Linux kernel has been doing this for years. Seeya...Q For the love of god, no! This creates a support nightmare. What happens when a user installs his system and recompiles the kernel without changing the source at all? His modules won't work, but there is no reason why they shouldn't. What if one of those now non-working modules is a driver for his hard drive? if you didn't change the code, no change to version = modules continue to work? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rand() is broken
On Sun, 2 Feb 2003, Andrey A. Chernov wrote: On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote: Why not? Arc4 is a) deterministic and b) good for all bits. If you mean arc4random() function - not, because it use true randomness, if you mean RC4 algorithm, probably yes, but we should compare its distribution with our current variant and be sure that speed is acceptable. What form RC4 distribution have? arc4 is the non-encumbered name for rc4 that is not derived from RSA code -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, 2 Feb 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Andrey A. Chernov writes: On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote: Anyway, last time we discussed this, I think we stuck with the rand() we had because we feared that people were using it's repeatable well documented sequence of random numbers in regression testing. As documented, it must be repeatable across the calls for same seed, that is all. It not means repeatable accross platforms or across different OS versions. In fact it is already not repeatable across different OS'es, so regression is limited. Also, regression must not stop bugs fixing progress in anycase. Our manual pages do not comprehensively list all compatibility concerns or concessions, waving our manpage about does not address the concern. As I said, I don't know how big a concern this is. But last time it was enough of a concern to make us keep rand() as it was. man srand on another system (for what its worth) says: The rand() function uses a multiplicative congruential random-number generator with period 2**32 that returns suc- cessive pseudo-random numbers in the range of 0 to RAND_MAX (defined in stdlib.h). The srand() function uses the argument seed as a seed for a new sequence of pseudo-random numbers to be returned by sub- sequent calls to rand(). If srand() is then called with the same seed value, the sequence of pseudo-random numbers will be repeated. If rand() is called before any calls to srand() have been made, the same sequence will be generated as when srand() is first called with a seed value of 1. Please surf the mail-archives to find the discussion, it contained a lot of good arguments from both sides, arguments which should be thought about before changing rand(). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, 2 Feb 2003, Juli Mallett wrote: * De: David Malone [EMAIL PROTECTED] [ Data: 2003-02-02 ] [ Subjecte: Re: rand() is broken ] On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote: FreeBSD Redhat SunOS 660787754660787754645318364 FWIW - AIX aggrees with Solaris. Endiannes, or an SVR4 implementation difference? Not endianess, unless they did something really gross to the routine on Solatis/x86 -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
On Fri, 1 Feb 2002, Peter Wemm wrote: - AMD write cache allocation due to speculative writes being cancelled and then written back later vs no cache snooping on AGP regions. I'm somewhat perplexed about this issue, there's lots of conflicting info going around, a good deal of it which does not make much sense [to me :-)]. I really dont see what PSE has to do with this for several reasons.. if the page/ region is cacheable, why does a 4MB vs 4K page make any difference? cacheable vs no-cache-snooping is a recipe for disaster.. why would 4K pages on a non-coherent region be safer? Or is the problem that write allocation happens on uncacheable/non-write-back regions in 4MB pages? Or something else? Speculative writes can only happen to pages in the TLB (so you don't get speculative TLB misses and replacements), not having a large amount of 4M pages around in the TLB means that addresses covered by these can't possibly be involved in speculative writes. I personaly suspect the reason the cache line flushes of speculatively written to cache lines derive from the AMD-s use of MOESI coherency and mapping that to actual bits. Another minor side effect is that you get direct cache-to-cahce transfers in SMP systems for shared data. Sander Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
On Mon, 4 Feb 2002, Terry Lambert wrote: Narvi wrote: Speculative writes can only happen to pages in the TLB (so you don't get speculative TLB misses and replacements), not having a large amount of 4M pages around in the TLB means that addresses covered by these can't possibly be involved in speculative writes. I personaly suspect the reason the cache line flushes of speculatively written to cache lines derive from the AMD-s use of MOESI coherency and mapping that to actual bits. Another minor side effect is that you get direct cache-to-cahce transfers in SMP systems for shared data. I think that the problem is more related to the fact that there are 16 TLB entries for 4K data pages, 16 for 4K code pages, and another 8 for 4M pages. Peter is right, in other words, because there is a problem with the interaction of 4K and 4M pages. I've seen this myself, as I've previously reported, as well as seeing other problems (and knowing how to work around them, after weeks of investigation into characterizing them). I wasn't aware that I was contradicting Peter 8-) Yes, it is possible that there are issues (some of which may in turn be bugs) in the 4KB and 4MB page handling. I'm not sure that 4K vs. 4M handling is done in any special way when it comes to speculative vs. normal writes. Speculative writes don't cross page boundaries (which means a different thing depending on which TLB you found the page from) - meaning that having a change of objects inside a mapped 4M page is asking for trouble. Writing back the cache lines that may have been written to is imho reasonable behaviour. Note that I was lucky, in that I had modified the FreeBSD kernel to use certain types of mappings in a certain way; I think it would be very difficult, or impossible, for anyone else to duplicate the problem in order to better characterize it beyond DISABLE_PSE, except the chip vendors themselves, if they started from first principles with a simulation. It may even well be possible to get different results with aligned vs. misaligned reads and writes, or a proper mix thereof. It may be possible to build a model to track down the what is really going on part, but its not clear its worth the trouble over just picking what (not) to do. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI project progress report
On Tue, 20 Jun 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Narvi writes: : You obviously haven't considered the ability to be able to near hot-swap : motherboard and cpu - or even RAM - in this way. The ACPI spec specifically states that one cannot disassemble a machine in S4 state and expect the state to be saved on reassembly. Maybe the same sort of mechanism could be used to do this, but then again, maybe night. At any rate, being able to save and then restore the state would be the needed inital step in reassembly related state saves/recoveres. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Tue, 20 Jun 2000, Josef Karthauser wrote: On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote: The real issue here is persistent system state across the S4 suspend; ie. leaving applications open, etc. IMO this isn't really something worth a lot of effort to us, and it has a lot of additional complications for a "server-class" operating system in that you have to worry about network connections from other systems, not just _to_ other systems. That said TCP/IP is very resilient :). I tried suspending to disk my laptop, unplugging the batteries and ether card, taking it to another part of the building and the firing it up. Pccardd saw the ethernet card, Dhclient saw the dhcp server and got my ip address back, and my pre-existing remote terminal sessions continued functioning :) Excellent. IMO if the machine is a server and you want to suspend it, who cares about the clients at the other end? If you did you wouldn't suspend it in the first place :) You obviously haven't considered the ability to be able to near hot-swap motherboard and cpu - or even RAM - in this way. Joe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Tue, 16 May 2000, David Scheidt wrote: On Fri, 28 Apr 2000, David Scheidt wrote: On Fri, 28 Apr 2000, Bush Doctor wrote: Out of da blue David Scheidt aka ([EMAIL PROTECTED]) said: Not incidently, SCO have waived the $100 license application fee, which means that you can get your own official Ancient UNIX(TM) Source Code License for free. This roughly cuts in half the cost of the disks for someone not covered under a orginizaitonal souce code license. Is there a new license form to sign or do we just fill out the current form without sending the applicateion fee? I don't know. SCO just made the announcement a week or two ago -- the same time they BSD licensed cscope -- and don't appear to have made changes to their web site yet. The press release is at http://www.sco.com/press/releases/2000/6927.html It might be worthwhile to attempt to contact the contact name on the release. SCO have updated their webpages, to show that they are now giving these licenses away. See http://www.sco.com/offers/ancient.html. They also have have the 5th, 6th and 7th edition UNIXs available, as well as system III and 32V available. This makes checking the 'this command dates from xxx version' much easier 8-) David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Breaking build world costs $5? (was: Can we please have acurrent that compiles?)
On Mon, 15 May 2000, Paul Richards wrote: "Brian W. Buchanan" wrote: On Mon, 15 May 2000, Greg Lehey wrote: I see this money scheme as an extension of the "finger pointing" which does nothing to build team spirit. That depends very much on the way it's taken. At the moment, people take the pointy hat voluntarily, not because it's forced on them. It's my expectation that the $5 should be in the the same spirit. Exactly... it's not meant to be a complicated system of fines or to discourage people from developing (at Desktop, we certainly don't want that!), it's just a little bit of good-natured public humiliation to encourage people to think (and maybe test) before they commit. :-) The only problem being that at Desktop you can drop the $5 into the fine box when you leave work but I'd have to walk down the bank and either do a wire transfer or send an international money order. Apart from the hassle involved there's the fact that all told it will cost me in the region of $30-40 to pay the fine! A nice idea but not very practical for the FreeBSD project. Just theoretically, there are e-gold and other payment things that are all that tied to things like 'geographical location'... Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Errrmmm Really, did you check the archives for the issue? There used to be a real long thread on why/why not sysV style init scripts. It produced not one but several flamewars iirc 8-) In short - if we change from the present scheme, we want something better than just stop and restart entry points for the scripts. What happens if the restarting is not an atomic, independent act? On Sat, 6 May 2000, Will Andrews wrote: Hello, I've noticed an inconsistency among our ports. It seems that not every port that installs rc.d startup scripts includes methods to not only startup, but also shutdown and/or restart, where appropriate. (Sent to -ports for ports hackers' opinions.) Shouldn't this sort of thing be standardized? And maybe a similar method be integrated into /etc/rc for restarting base system daemons? (Sent to -current for src hackers' opinions.) Please continue specific discussion on either of these in their own list, or if reply is general Cc both. -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bluetooth
On Tue, 18 Apr 2000, Southwell wrote: It would be good to be ahead of the game rather than behind it on this occasion -- I am still trying to find out about getting IEEE 1394 support -- cards have been available to me for at least 3 years!! E... Do you also have docs? And did you check the archives? A link to files to get support for some cards (in ip over firewire) were posted. There is most probably also some bitrot in there... My two peenorth anyway David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bluetooth
On Tue, 18 Apr 2000, Brooks Davis wrote: I am still trying to find out about getting IEEE 1394 support -- cards have been available to me for at least 3 years!! Did you even read the licensing site? It's pretty clear that you couldn't write code that Walnut Creek could ship on CDs without charge (to them). With licensing problems like that, I'm beginning to believe that Intel's approach of ignoring 1394 in favor of USB2 is the right idea. That's unfortunate for those who have 1394 hardware, but that's the live of an early adoptor. Early adaptor? You *HAVE* got to be kidding. Consider anybody with any real DV hardware. Early adopting for firewire happened several years ago. Hopefully there will be firewire support for FreeBSD, like say from BSDI. Otherwise, and in the case of existing code, setting up a nfp (say "BSD Firewire initative") that collected the licence fee + overhead on each download of the binary is another option. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD Build status
On Tue, 18 Apr 2000, Peter Jeremy wrote: On 2000-Apr-18 08:07:45 +1000, "Jordan K. Hubbard" [EMAIL PROTECTED] wrote: As for the lists being tedious and long: I've sorted the content by relevance, and it was my hope that over time they would shrink to zero if we annoyed people enough with them. I think that's too much annoyance, really. I can see most people simply unsubscribing from -current in the face of a mail that long and tedious IMHO, it's not such a bad idea. freebsd-current _is_ the place to report problems with -current, why can't the report be produced by a daemon? All the MUA's I've ever used allowed me to delete a mail before reading all of it, so I don't see that having detailed information (at the end) is a real issue (though it might be for someove paying by the byte). It *IS* a bad idea. Consider how big the failure report can be. Why not instead: 1) have the report automatically uploaded on web 2) have the summary of summaries be sent to -current The summary of summaries would roughly look like this: Subject: -current build report Success: world, generic Fail: lint For details, see http://blah.foo.bar/FreeBSD-build/date It conveys the information most needed, and can hardly hurt anybody's mailbox. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD Build status
On Tue, 18 Apr 2000, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Nar vi writes: The summary of summaries would roughly look like this: Subject: -current build report Success: world, generic Fail: lint The First part of the email is a summary just like that. See what Boris Popov writes on the issue. I am sure there are more people who think that a big status report is not cost effective, if they can get a *short* summary, and an url where they can get the full report. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Wed, 1 Mar 2000, Christopher Masto wrote: On Wed, Mar 01, 2000 at 11:28:13AM -0800, John Polstra wrote: It takes no more than a well-designed operating system service to ensure that badly written programs don't fail to release resources when they crash. We didn't design that particular service. That's why it's called System V shared memory. I did mean to imply that it was poorly designed, but not that it was designed by FreeBSD's designers. Also, it's persistent for legitimate design reasons, just like files are. Applications need to clean up after themselves. You can have many more than 32 files. Files are (usually) well-organized and have names, so you can wipe out your web browser's cache or lock file relatively easily. Files take up a negligible fraction of the available file space. SysV shared memory is limited, unnamed, unorganized, and uses up a very scarce resource. The OS has no way of knowing whether an application wants its shared memory segments to survive after it terminates. That's unfortunate. That's one of the reasons I try to stay away from SysV IPC. I don't like to have to reboot. You don't have to reboot. Ipcrm is you friend. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Now that sigcontext is gone ...
On Sat, 2 Oct 1999, David O'Brien wrote: P.S. This also reminds me that FreeBSD is non-standard relative to Linux and all of the major vender commercial Unices in that a disallowed access, such as a write to a read-only region of memory, generates a SIGBUS rather than a SIGSEGV. Yes, this even violates the 1996 POSIX spec. So lets make the change for 4.0. :-) Just how much code will break? All that has been changed during porting to catch the other signal? And what will we be issuing sigbus for? -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Mon, 23 Aug 1999, Andrzej Bialecki wrote: On Mon, 23 Aug 1999, Daniel C. Sobral wrote: Let me retract the Ghost in the Shell statement. I just checked, and my memory played tricks on me. It was a different letter effect. :-) Andrzej, can you somehow turn it into a parody? If you can make it into a parody, then it's legal. I can't think of any... What could be funny in such primitive effect anyway? Besides, I'm not that sure I want to spend more time on that. Feel Parody doesn't hve to be funny. free to hack it, guys, if you like it - it's BSD license, you know... Make the falling letters black (on black background) and we will put up a patch in numerous free web directories that makes the letters visible again. 8-) Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Sun, 22 Aug 1999, Andrzej Bialecki wrote: On Sat, 21 Aug 1999, Kevin Day wrote: I hate to keep bringing things like this up, or start a legal war, but this screensaver is more than likely a copyright and/or trademark violation, and bringing it into the source tree may not be a good idea. Yes, lots of people may be making things like this, but it would probably be best to distance FreeBSD itself from such a thing. You can trademark the title "The Matrix", but you can't trademark a common word "matrix". That's the only word I use for the name of the module. As Daniel mentioned, they even can't claim that it's their idea. So I think I can pretty safely import it. If we wanted to be legally paranoid we would call it the "letter" saver and add as the comment the words "Falling letters like in the movie with red bills" Andrzej Bialecki // [EMAIL PROTECTED] WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small Embedded FreeBSD: http://www.freebsd.org/~picobsd/ Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Sun, 22 Aug 1999, Kevin Day wrote: On Sun, 22 Aug 1999, Andrzej Bialecki wrote: On Sat, 21 Aug 1999, Kevin Day wrote: I hate to keep bringing things like this up, or start a legal war, but this screensaver is more than likely a copyright and/or trademark violation, and bringing it into the source tree may not be a good idea. Yes, lots of people may be making things like this, but it would probably be best to distance FreeBSD itself from such a thing. You can trademark the title "The Matrix", but you can't trademark a common word "matrix". That's the only word I use for the name of the module. As Daniel mentioned, they even can't claim that it's their idea. So I think I can pretty safely import it. If we wanted to be legally paranoid we would call it the "letter" saver and add as the comment the words It's not just the name "Matrix" though. Make a screen saver of the Superman 'S' logo, and see how quickly a certain comic book company comes after you. The "S" logo? We are not dealing with the "S" logo, we are dealing with a screensaver that displays an ordinary rotation S on the screen. :) Making a derivative work based on something that was in a movie probably is a copyright violation. Warner Brothers could easily say that you've Is it derived from the movie? Says who? It rather reminds me of an old virus that made letters fall on the screen... copied an element from their movie (even if it's not the entire movie), and even go so far as to get a judge to get any CD-ROM distributors of FreeBSD to recall all unsold CD's, and destroy them. As for the trademark issue, it doesn't have to be a name to be trademarked. Logos, effects, and even sounds can be trademarked. Uhhh Depends on where. Sounds can't be trademarked everywhere. I'm really not trying to be annoying about things like this, but I already had to fight for the ability to be able to use FreeBSD at work, after they discovered other copyright/trademark violations in the source tree.. (Trek, etc). "If they'll steal things here, how do we know the entire kernel isn't They aren't violations until the judge says so. If it is not true in the legalsystem you are in, I suggest moving to another one. stolen from somewhere else?" Yes, it's silly logic, but they do sort of have a point. We're selling a product with FreeBSD embedded in it. Should some copyright/patent holder come up proving that the VM system is his, and FreeBSD stole it from him, they could legally force us to recall every machine we've sold, and replace it with non-infringing materials. Obviously we're not shipping 'trek' on our system, and wouldn't include the matrix saver anyway, but I (for completely selfish reasons) would like to keep FreeBSD distanced from anything that could possibly be infringing on anything, and let you download it from somewhere else if you want it. :) Kevin Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel hacker tasks seek interested hackers
On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Narvi writes: On Sun, 15 Aug 1999, Poul-Henning Kamp wrote: [snip] 7. [medium] The current naming for ptys doesn't scale that well. Changing it to ttyp%d / pty%d would probably be a good idea in the long run, but the ramifications are relatively widespread (think: "ports") Which while being scaleable in one direction (you can have things like /dev/pty1234567890) as it is essentialy open ended, on the other hand: a) pty/tty names are now variable length b) the name length advances quite quickly as we add more ptys c) it is a totaly new "look and feel" So why not instead: I think that is needlessly complicated. It's a direct extension to the present tty naming scheme. I think tty%05d would solve all but the third of your objections, The first was more a question of radix, implying that 10 might be too low. IMHO base-32 has many good qualities to itself. It makes retaining the policy of creating ptys in increments of 32 easy, the name space does not grow as fast (pty allows for more ptys than pty%06d) and it is not much different from the naming system. and quite frankly the "we've never done that before" argument works badly with me. It's more the argument of "why do it *significantly* differently from others?" -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pex5 and xie load errors
On Sat, 14 Aug 1999, Randy Bush wrote: i just upgraded to current. i still have the following in my /etc/XF86Config Section "Module" Load"pex5.so" Load"xie.so" EndSection during X startup i get load errors for these. but i can see nothing unappy with X. do i delete them from /etc/XF86Config or rebuild X or what? Rebuilding X won't help last I tried. They have been broken for quite some time now. Seems there aren't enough people who care enough. thanks. randy Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KDE programs won't compile
On 6 Jun 1999, Joel Ray Holveck wrote: I can only assume that we install our KDE headers somewhere different than the developers (primarily on Linux machines). By default, KDE installs to /usr/local/kde. On RedHat, the RPM installs it to /opt/kde. All the includes are in /usr/local/kde/include, the libs in /usr/local/kde/lib, etc. where the headers are on the FreeBSD machines and then you'll have to probably add a configure argument like: --with_kde_includes= /some/dir/where/kde/includes/are Most KDE programs, including the configure scripts, look for the KDEDIR environment variable. I believe that the correct thing to do with FreeBSD's KDE install is to set KDEDIR to /usr/local. I do this in /etc/profile and /etc/csh.cshrc here. (I have KDE in /usr/local/kde here, too, so I haven't tested it as /usr/local.) NO This can't be left to stand so. A port *should* set the KDEDIR to $PREFIX, not /usr/local. Just maybe I don't have my ports under /usr/local or have a separate test branch under something else? Yes, for better or for worse (I'd vote for worse), the FreeBSD ports install the kde headers in /usr/local/include.. However a simple --prefix=/usr/local *should* fix any configure problems, and if this is to make it into a FreeBSD port, use --prefix=$(PREFIX). --prefix specifies where it should install to. However, this app needs to find some 3rd-party include files, so --prefix is not appropriate. --prefix=($PREFIX) is definately appropriate - you signal with $PREFIX what is the root of your install to tree. If you have your ports under /opt, $PREFIX=/opt -- by default $PREFIX=/usr/local. FWIW, I've found that using /usr/local/kde instead of /usr/local has, in my case, been most helpful. I don't advocate it for every tiny library, but for something as large and complex as KDE, it works well. It must definately be used with moderation. Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Nt source licenses...
On Sun, 16 May 1999, Dean Lombardo wrote: Garance A Drosehn wrote: At 3:51 PM +0700 5/12/99, Ustimenko Semen wrote: Are we going to get this license? I am interested in NTFS source code a lot... I would be very careful about getting an NT source license if your intention is to write NTFS support for some other operating system. Microsoft is not doing this licensing for the benefit of mankind, they are doing it to attract college-type users to sticking with WinNT over open-source unixes. The last thing we need is some code from WinNT which causes us to be sued by Microsoft... They can't sue - unless, of course, the code is copied verbatim (and They most definately *CAN* sue. I don't think can't sue is something that applies to the US in any way. it's not very likely to be, anyway). Otherwise, it shouldn't be any more illegal than reverse engineering the code, and several federal appeals courts have held that it is fair use to reverse engineer a program in order to examine and copy its ideas and any unprotected expression. But do we have the money to prove that? And if we do, wouldn't it be spend on better things? Dean Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Nt source licenses...
On Sat, 15 May 1999, Alfred Perlstein wrote: On Sat, 15 May 1999, Narvi wrote: On Fri, 14 May 1999, Garance A Drosehn wrote: At 3:51 PM +0700 5/12/99, Ustimenko Semen wrote: Are we going to get this license? I am interested in NTFS source code a lot... I would be very careful about getting an NT source license if your intention is to write NTFS support for some other operating system. Microsoft is not doing this licensing for the benefit of mankind, they are doing it to attract college-type users to sticking with WinNT over open-source unixes. The last thing we need is some code from WinNT which causes us to be sued by Microsoft... It would probably be very unwise for the project to get get the licence. However, considering that we support loadable filesystem modules, somebody adventurous enough can get the licence and write a (separate distributed, possibly even only as binary) module. Downloading a kld module from the net definately does not taint your mind. I'm unsure what the fuss is over, don't we have a kld to read NTFS already? How about writing? Is there really anything special about NT that we NEED to learn that hasn't been done _better_ by Sun, SGI or Digital? :) No, not really. -Alfred Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Nt source licenses...
On Fri, 14 May 1999, Garance A Drosehn wrote: At 3:51 PM +0700 5/12/99, Ustimenko Semen wrote: Are we going to get this license? I am interested in NTFS source code a lot... I would be very careful about getting an NT source license if your intention is to write NTFS support for some other operating system. Microsoft is not doing this licensing for the benefit of mankind, they are doing it to attract college-type users to sticking with WinNT over open-source unixes. The last thing we need is some code from WinNT which causes us to be sued by Microsoft... It would probably be very unwise for the project to get get the licence. However, considering that we support loadable filesystem modules, somebody adventurous enough can get the licence and write a (separate distributed, possibly even only as binary) module. Downloading a kld module from the net definately does not taint your mind. --- Garance Alistair Drosehn = g...@eclipse.acs.rpi.edu Senior Systems Programmer(MIME NeXTmail capable) Rensselaer Polytechnic Institute; Troy NYUSA Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
