On Tue, Oct 27, 2009 at 08:23:10PM -0400, Dave Eckhardt wrote:
>
> University of Utah, "Flux OSkit".
>
> Old OSkit is mostly BSD licensed (if you count the CMU Mach license
> as a BSD license), but at some point somebody sprayed the GPL over
> everything (somewhat reducing the utility of some CMU
> Wasn't there an "OS kit" or something like that with drivers
> derived from Linux one's at some moment?
University of Utah, "Flux OSkit".
Old OSkit is mostly BSD licensed (if you count the CMU Mach license
as a BSD license), but at some point somebody sprayed the GPL over
everything (somewhat r
the oskit was a great tool.
Only that if you wanted to use some component, in the end,
most of them had to be pulled into.
On Tue, Oct 27, 2009 at 10:43 PM, Tim Newsham wrote:
>> Wasn't there an "OS kit" or something like that with drivers derived
>> from Linux one's at some moment? Found this so
Wasn't there an "OS kit" or something like that with drivers derived
from Linux one's at some moment? Found this some years ago when I was
searching doc. about OSes---I seem to remember this was when looking for
Mach (!) documentation, so could be CMU.
yes, utah (also did mach work) made oskit:
On Tue, Oct 27, 2009 at 12:37:58PM -0400, erik quanstrom wrote:
>
> there was also a bit of talk about os agnostic driver stubs.
> i'm a little pessimestic about the chances for success there,
> especially for oses that don't use the berkeley socket stuff.
> but it's probablly something that's wor
> I'm impressed. What are the prospects of this happening. It is good
> news if people decide to go that route.
>
in certain cases, 100%.
there was also a bit of talk about os agnostic driver stubs.
i'm a little pessimestic about the chances for success there,
especially for oses that don't use
On Tue, Oct 27, 2009 at 9:16 AM, erik quanstrom wrote:
> there were a lot of wierd os people talking to a lot of package
> maintainers at google this weekend. the solution that made
> sense to *BOTH* was to ditch autoconf and submit a platform
> specific makefile.
I'm impressed. What are the pr
> // Since the purpose of ape is to emulate the environment
> // configure is expected to run in...
>
> false premise. the purpose of ape is to provide an ANSI/POSIX environment.
> it's purpose is as much for outbound porting as inbound, and maintaining the
> actual target is more important in tha
// Since the purpose of ape is to emulate the environment
// configure is expected to run in...
false premise. the purpose of ape is to provide an ANSI/POSIX environment.
it's purpose is as much for outbound porting as inbound, and maintaining the
actual target is more important in that direction.
> The problem is, everyone who generates configure by this version (or
> some range of versions) of autoconf would run into this because this
> is inserted in the configure's initialization code without any feature
> tests requested by configure.ac
lots of discussion of autoconf at the gsoc mentor
On Oct 26, 9:21Â am, 23h...@googlemail.com (hiro) wrote:
> > Since the purpose of ape is to emulate the environment configure is
> > expected to run in, and such mismatch has been found, it migh be
> > easier to fix ape than to convince maintaners of autoconf to fix on
> > their side...
>
> Why are
> Since the purpose of ape is to emulate the environment configure is
> expected to run in, and such mismatch has been found, it migh be
> easier to fix ape than to convince maintaners of autoconf to fix on
> their side...
Why are you so sure they wouldn't fix it? Have you or has anybody you
know
Tim,
On Oct 23, 2:23Â pm, news...@lava.net (Tim Newsham) wrote:
> What if you just made a command "gnuconfig" which rewrote the
> configure script, fixing the minor defects, and ran the result?
> Or bound in a dummy "ls" and "egrep" before executing the real
> configure script?
> Lets keep the in
http://plan9.bell-labs.com/sources/contrib/fgb/rc/config
hacks configure and mostly gets it going
for egrep and fgrep
aux/stub /bin/egrep
bind /bin/grep /bin/egrep
On Fri, Oct 23, 2009 at 4:18 PM, Tim Newsham wrote:
>> Jason: I understand your reasoning. However if two small fixes would
>> unbl
> What if you just made a command "gnuconfig" which rewrote the
> configure script, fixing the minor defects, and ran the result?
I wrote an rc script (vary
http://codereview.appspot.com/117087/diff/1/2) which generally applies
a sam script to a file (via ssam
http://codereview.appspot.com/95076/d
Jason: I understand your reasoning. However if two small fixes would
unblock execution of many projects' configure on Plan9 IMHO they are
worth making; they won't break anything.
What if you just made a command "gnuconfig" which rewrote the
configure script, fixing the minor defects, and ran the
> Jason: I understand your reasoning. However if two small fixes would
> unblock execution of many projects' configure on Plan9 IMHO they are
> worth making; they won't break anything.
I wasn't going to comment again on this, since it's ape's tools, not
the plan9 versions. I was obviously mistake
Charles,
On Oct 23, 10:40Â am, fors...@terzarima.net (Charles Forsyth) wrote:
> it's /rc/bin/ape/ls that would change, not Plan 9's ls-proper.
Of course ape's one. As well as I am proposing to add egrep to ape's
tree not Plan9's native tree.
> what does autoconf do with the `inode number'?
In f
I have no idea, but I know that removing the -i switch from configure
gets it going,
so just ignoring it should be good enough
On Fri, Oct 23, 2009 at 12:12 PM, Charles Forsyth wrote:
> it's /rc/bin/ape/ls that would change, not Plan 9's ls-proper.
>
> what does autoconf do with the `inode number
Charles Forsyth wrote:
it's /rc/bin/ape/ls that would change, not Plan 9's ls-proper.
what does autoconf do with the `inode number'?
Haven't you heard of the elephant that escaped from a traveling circus and
wandered into the vegetable garden of a lady who had never seen an elephant in
her
it's /rc/bin/ape/ls that would change, not Plan 9's ls-proper.
what does autoconf do with the `inode number'?
Dimitry wrote:
> I have two suggestions for ape minor additions arising from my recent
> attempts to run configure scripts on Plan9
>
> These things are needed by autoconf.
>
> Looks like these
> things are hardwired in the autoconf macro library.
Since autoconf should deal with "any" unixy enviro
Great, thanks Russ.
I have two suggestions for ape minor additions arising from my recent
attempts to run configure scripts on Plan9
1. Add this script (suggested by Russ) as /rc/bin/ape/egrep
#!/bin/rc
if(~ $1 -E) shift
exec grep $*
2. Make ls accept -i option (if inode numbers do not exists i
23 matches
Mail list logo
