Re: speed up port compiling using RAM (tmpfs) ???
[ Cc trim a bit ] On Fri, Jan 20, 2006 at 08:53:11PM -0500 I heard the voice of Kris Kennaway, and lo! it spake thus: In order to do better you either have to: This is something that may be easier to: 3) Implement in portupgrade or portmanager or some such higher-level tool in a language that gives a little more flexibility than make, and which is already apparently pulling in most of the information it may need to do the job. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up port compiling using RAM (tmpfs) ???
On Sat, Jan 21, 2006 at 10:07:39AM -0600, Matthew D. Fuller wrote: [ Cc trim a bit ] On Fri, Jan 20, 2006 at 08:53:11PM -0500 I heard the voice of Kris Kennaway, and lo! it spake thus: In order to do better you either have to: This is something that may be easier to: 3) Implement in portupgrade or portmanager or some such higher-level tool in a language that gives a little more flexibility than make, and which is already apparently pulling in most of the information it may need to do the job. You still have the same issue as 1). Kris pgpzJKQnkm0kC.pgp Description: PGP signature
Re: speed up port compiling using RAM (tmpfs) ???
On Sat, Jan 21, 2006 at 03:23:21PM -0500 I heard the voice of Kris Kennaway, and lo! it spake thus: On Sat, Jan 21, 2006 at 10:07:39AM -0600, Matthew D. Fuller wrote: This is something that may be easier to: 3) Implement in portupgrade or portmanager or some such higher-level tool in a language that gives a little more flexibility than make, and which is already apparently pulling in most of the information it may need to do the job. You still have the same issue as 1). [ 1 == building dependancy tree to know what depends on what ] Yes, but portupgrade and friends already do most of that, so they can upgrade stuff in order. The biggest thing it seems like portupgrade (which is the only one I'm personally familiar with) lacks is that it doesn't of itself find out which of these dependancies are already installed, and lets the ports tree itself recurse down. It sounds, from reading the emails, like the script dougb has been putting together does this, though. Given that capability, and the information portupgrade builds (from all-depends-list, I think?) to determine which order to upgrade things in, it seems like it would have right there most of what it needs. There are still issues like after you start building something and it does the make config and the like to handle (as well as terminal arbitration issues with multiple possibly interactive compiles going at once), of course. Not an easy or trivial thing to do even with all that, certainly, but probably easier in perl/ruby/C/etc than in make... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up port compiling using RAM (tmpfs) ???
On Sat, 2006-Jan-21 14:30:57 -0600, Matthew D. Fuller wrote: On Sat, Jan 21, 2006 at 03:23:21PM -0500 I heard the voice of Kris Kennaway, and lo! it spake thus: On Sat, Jan 21, 2006 at 10:07:39AM -0600, Matthew D. Fuller wrote: This is something that may be easier to: 3) Implement in portupgrade or portmanager or some such higher-level tool in a language that gives a little more flexibility than make, and which is already apparently pulling in most of the information it may need to do the job. You still have the same issue as 1). [ 1 == building dependancy tree to know what depends on what ] Yes, but portupgrade and friends already do most of that, so they can upgrade stuff in order. Actually, they rely on there being an up-to-date INDEX file and build their own dependency database from that. Actually building the INDEX file is non-trivial (it takes roughly an hour for me). Tools like p5-FreeBSD-Portindex-1.4 cache intermediate output from make index but still have the up-front make index cost (and the documentation recommends a full make index regularly). You can save time by fetching the INDEX, but then you can't be certain that it matches your ports tree or your port options. Given that a port's dependency tree can depend on the options it is invoked with, it would be nicer if the dependency tree was generated dynamically, rather than pulled out of the latest INDEX file. If the INDEX dependencies are used to generate a parallel build tree then it's still important that the actual build process has interlocks to prevent unforeseen dependencies causing clashes. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up port compiling using RAM (tmpfs) ???
On Sun, Jan 22, 2006 at 08:09:56AM +1100 I heard the voice of Peter Jeremy, and lo! it spake thus: Given that a port's dependency tree can depend on the options it is invoked with, it would be nicer if the dependency tree was generated dynamically, rather than pulled out of the latest INDEX file. I'm pretty sure it _is_, since portupgrade finds things related to OPTIONS and such for me, and I don't blow multiple hours on INDEX builds. I'm pretty sure it uses all-depends-list (or one of its siblings). -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for FreeBSD Status Reports
All, On Friday 13 January 2006 20:19, I wrote: no big news since 6.0, but in the background there are many interesting projects: Just now the new malloc has hit current, we hear promising numbers from the network performance crew, the first batch of security advisories is out and I'm sure some of you spent the holidays doing exiting stuff for FreeBSD as well. Please tell us! This is the call for Status Reports of your project activity between October and now. This is not limited to developers. We want a broad spectrum of reports from everybody involved with FreeBSD. Check the Status Report homepage[1] for earlier reports. Submission deadline is a week from now, January 20th! I don't want to delay the publication much this time, so please write your report now! Please use the XML-generator[2] or -template[3] and send your report to [EMAIL PROTECTED] by next Friday. Thanks a lot! to date we have received only 11 reports, which - compared to earlier rounds - is a poor turnout. I am wondering if we just had a quiet period, if you don't feel your projects are ready for prime-time or if you are just tiered of writting reports? In either case, please let me know so we can do something about it. If you want to submit a report - deadline is extended to Wednesday (25th). Thanks! -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpHQNg4clsUN.pgp Description: PGP signature
Re: style(9) example :-)
On 2005-03-18 00:50, Roman Kurakin [EMAIL PROTECTED] wrote:
Giorgos Keramidas:
On 2005-03-17 19:33, Roman Kurakin [EMAIL PROTECTED] wrote:
I was unable to refrain from posting this :-)
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o, world!\n,'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
I've written stuff that's probably a bit harder to read, but in Perl :P
% cat filter.pl
#/usr/bin/perl
while(STDIN){chomp;print(join('',(map{my($b,$j,$t,$o)=(65,128,90,ord($_));((
$o-$b)=0($o-$b)=($t-$b))?eval{$o=(($o-$b)+13)%26+$b;$j=11;}:eval{$b=97;$t=
122;(($b$o)||($t$o))?eval{$j=10;}:eval{$o=(($o-$b)+13)%26+$b;$j=1431;};};$_=
chr(int(int(($j%2)==(chr($o)==$_))?$o:ord($_)));}(split//,$_))).\n);}
%
I saw smth like that, which run rm -rf /. I hope this one word greeting ;-)
Probably one such code could be added to fortunes.
This one is a rot13 filter. But no need to run it. It's was fun
writing, but very very useless. Other than as an example of how ugly
Perl can be, I guess...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 default pty/tty-limit (256) OFF!
Hi Antti, I need patch to raise FreeBSD 6.0 default pty/tty-limit (256) UP or OFF. In shell-production usage, that limit is ridiculous, there must be stop to this and put PTY-limits off! I changed my servers operating systems moment ago from Linux to FreeBSD thinking that FreeBSD could be more better, but how this can be possible, that so important think like PTYs are limited to so low?? every UNIX has more ptys. This is a long standing problem, as is evident from kern/25866 [1] from 2001. A more recent report is standards/90896 [2], wich also contains a patch. I'd suggest you try the patch and provide feedback to the bug report. $.02, /Mikko 1) http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/25866) 2) http://www.freebsd.org/cgi/query-pr.cgi?pr=standards/90896 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
