I'd like to see how OSI's going to call every and any author of Open Source software (as in licenced under an OSI-approved licence, not just OSD-compliant) and tell them it isn't any more, and they have to switch.
People should consider themselfes lucky that there are authors giving out their source freely. OSI can't, thank goddess, revoke their licences. If they hadn't been, that code would not be freely redistributable.
... it's because I'm writing the OS myself (and with the other six lads).
Ok, there's code in from OpenBSD, NetBSD(TM), FreeBSD(TM), MicroBSD, the FSF, the ASF, the XFree86 Project, Thomas Dickey (Lynx, cdk), Jörg Schilling (mkisofs), Perl and Sendmail. But that's only the indirect contributors.
"All of them" is _really_ the way to go, we stress this at exhibitions etc. for people like the one who asked, too.
If you would not be coming from $otherOS to BSD, I'd say you should really buy the hardware which your OS (the one you want to use and which fits your needs) supports, not choose the OS among the selected few which work with your closed-firmware closed-spec hardware.
May I suggest you have a look at MirOS (an OpenBSD derivate) too? http://mirbsd.de/
I'm always reading as much as I can as early as I can. This has saved me a lot of hassle (e.g. I never bought a "copy"-protected CD because it was lacking the "CD Digital Audio" logo).
Of course, everyone else I know is even too lazy to read the quickstart guide or the less-than-1K BSD licence throughoutly.
In addition, I read many of the svn-related links in this article's posts today and found the evaluation of GNU Mono's move to svn.
The svn developers clearly state that their tool is not suited for projects as large as ours (with way above 130'000 files), and even Mono (with IIRC about 50'000 files) has got difficulties because the management it totally different for large projects.
So it looks that, how nice svn might be, we're not even in the target market. And I didn't check how many files or Gibibytes the OpenBSD/cvs is right now, but I strongly believe they have at least 60-70% more than we.
c) Rewrite ftp-proxy so that it uses a table
which is manipulated by ftp-proxy but which
must be contained in the pf.conf first.
spamd does this too, I think.
Eh? cvs uses ssh for connecting to the server, or operates locally.
What? You're using pserver/kserver? Don't.
You can even use anoncvs to make non-anynomous read/write accounts for users to access the CVS repository by means of cvs server, preventing them from directly writing into the repo. http://mirbsd.bsdadvocacy.org/cvs.cgi/src/l ibexec/ anoncvssh/
Laptops have usually 10-30 GB disc space and 128-256 MiB RAM. And WLAN, or worse: ADSL access to the repo via Internet (can you say 768 kbps downstream, 128 kbps up?).
Open Source projects often have Pentium-class systems as servers. Alpha. Vax. SPARCstation.
Neither are as large projects as an entire opera- ting system with far above 100'000 files in the CVS Repository.
Also, cvsweb won't work (viewcvs would, but it uses Python, yuck, and is a worse nightmare to patch/maintain), rsync on berkeley DBs is pretty much unsupported, the new file storage is untested and who-knows-what implications there are on lok- king, and the biggest problem is anonCVS which would not work any more. And nobody sane would trust svn as a network server, or - worse - as an Apache(tm) 2 module (henning@openbsd also says Apache(tm) 2 is not broken code, but even broken design, and that it will never ever run on OpenBSD).
Also, RCS files are well-hung and (in the mean- while) pretty documented files. Says someone who's hung in there with rcs(1) commands as well as $EDITOR countless times in the last 3 years.
Now now. That's definitively FTP's fault, and IMHO this pre-1980 protocol deserves to finally die anyway. What's wrong with using HTTP for fast public down- loads, SCP/SFTP for secured file transfers and if it really has to be fast, netcat (and ssh to start netcat on the remote end)?
Even Windows®-FTP-Clients do usually support SFTP.
I'm running an OpenBSD fork, and probably have less code in my CVS than them, but it's about 1.55 GB for us right now.
I don't trust a Berkeley DB this far, and the new filesystem backend of svn is... smelly.
In addition to that, Benny tried to play with only the ports tree in a svn repo. Checking it out after the import, with no mods yet, required already 384 MiB RAM and swap. That's too much.
You'll be soon supposed to know metrics in and out, e.g. take a look at the 14th line of http://mirbsd.bsdadvocacy.org/cvs.cgi/src/gnu/ usr. bin/cvs/doc/cvs.texinfo.diff?r1=1.8&r2=1.9&f=u which you are supposed to read too;-)
Nah, if I had known that I had not ported GNU CVS 1.12 and rather peeked into OpenCVS, maybe helped with it (since I know CVS and RCS pretty well, after 2+ years of running my own).
I'm developer of an OpenBSD fork/derivate (and slightly pissed off that I heard of this only yesterday, and not 4 weeks ago or so when they started; so much for their "live cvs mails"), and I started to replace our outdated cvs 1.11.1p1 with many many local patches by a modern GNU cvs 1.12.10 two weeks ago. It's not exactly compatible with the old CVS, but it works pretty well for now, and I had not to fix too much.
The code for 1.12 has actually improved a lot.
I won't jump onto the wagon for OpenCVS right now, even if I'd like to for licence reasons. First, I'm still pissed off, second, GNU CVS is well-hung, proven code and we're relying on it.
Subversion is, how much benz asks it, not an option. For example, in a subversion repo only containing the MirPorts Framework, a check-out temporarily requires about 384 MiB RAM, which is just too much. Our master CVS server is a Soekris net4801 with 128 MiB RAM and a 266 MHz Pentium-compatible Geode CPU, which also serves as my home ADSL router and firewall.
The German-language Slashdot equivalent symlink.lu has had this for ages (two days longer), cf.
http://www.symlink.ch/article.pl?sid=04/12/02/0954 249&mode=nested
Although they are no longer documented, I accidentally hit ^Qc in Borland C++ 5 or so while hacking (at work), and it took me to the end of the file. So they still worked.
Do these still work in modern Delphi?
For anyone who wants a simple, free text editor for Unices (and DOS and Win and...) which has got these keybindings, can optio- nally do syntax highlighting and is configu- rable, check out my "jupp" modifications to the JOE's Own Editor at
http://wiki.mirbsd.de/JuppEditor (there are binaries for Mac OSX 10.3.5 I compiled on my shell acct. at
http://users.mirsolutions.de/~tg/binaries/ availa ble). It does various character sets (almost any single-byte charset, including a custom Klingon one, and UTF-8 - no DBCS such as EUC-JP yet though), even on non-locale-aware operating systems such as OpenBSD or my own project MirOS.
OTOH I have made even more PITA efforts and created MirLibtool and a framework which replaces all known instances of GNU libtool with it, then runs a patched GNU autoconf (2.13 or 2.59, according to what the package needs) over it, before running configure.
This is based upon work from the OpenBSD ports tree:
metaauto - install more than one autoconf at once
gnu.port.mk - replace config.guess and config.sub
and control invoking autoconf/autoheader
And work by myself:
autoconf - integrate Tom Dickey's patches into
2.13 and fix 2.13 and 2.59 up enough
libtool - vandalize 1.5 so it works on both
autoconf versions
Slashdot Mirror
I'd like to see how OSI's going to call every
and any author of Open Source software (as in
licenced under an OSI-approved licence, not
just OSD-compliant) and tell them it isn't any
more, and they have to switch.
People should consider themselfes lucky that
there are authors giving out their source
freely. OSI can't, thank goddess, revoke their
licences. If they hadn't been, that code would
not be freely redistributable.
... it's because I'm writing the OS myself
(and with the other six lads).
Ok, there's code in from OpenBSD, NetBSD(TM),
FreeBSD(TM), MicroBSD, the FSF, the ASF,
the XFree86 Project, Thomas Dickey (Lynx, cdk),
Jörg Schilling (mkisofs), Perl and Sendmail.
But that's only the indirect contributors.
"All of them" is _really_ the way to go, we stress
this at exhibitions etc. for people like the one
who asked, too.
If you would not be coming from $otherOS to BSD,
I'd say you should really buy the hardware which
your OS (the one you want to use and which fits
your needs) supports, not choose the OS among the
selected few which work with your closed-firmware
closed-spec hardware.
May I suggest you have a look at MirOS (an OpenBSD
derivate) too? http://mirbsd.de/
Uh, I'm a boy and I even learn non-computer games
such as Magic faster by RTFM than by just trying.
Playing (under assistance) during RTFM helps,
though. Watching rarely, even assisted.
I'm always reading as much as I can as early as I
can. This has saved me a lot of hassle (e.g. I
never bought a "copy"-protected CD because it was
lacking the "CD Digital Audio" logo).
Of course, everyone else I know is even too lazy
to read the quickstart guide or the less-than-1K
BSD licence throughoutly.
(Hi Stephen.)
/cvs is
In addition, I read many of the svn-related
links in this article's posts today and found
the evaluation of GNU Mono's move to svn.
The svn developers clearly state that their
tool is not suited for projects as large as
ours (with way above 130'000 files), and even
Mono (with IIRC about 50'000 files) has got
difficulties because the management it totally
different for large projects.
So it looks that, how nice svn might be, we're
not even in the target market. And I didn't check
how many files or Gibibytes the OpenBSD
right now, but I strongly believe they have at
least 60-70% more than we.
a) You can retrieve packages by HTTP.
b) More insecurity in the kernel?
c) Rewrite ftp-proxy so that it uses a table
which is manipulated by ftp-proxy but which
must be contained in the pf.conf first.
spamd does this too, I think.
Eh? cvs uses ssh for connecting to the server, or
l ibexec/ anoncvssh/
operates locally.
What? You're using pserver/kserver? Don't.
You can even use anoncvs to make non-anynomous
read/write accounts for users to access the CVS
repository by means of cvs server, preventing them
from directly writing into the repo.
http://mirbsd.bsdadvocacy.org/cvs.cgi/src/
OpenBSD was going to transition to OpenCM long-term.
The bad news is that it uses boehm-gc, requires
6 to 8 GB of RAM and development stalled.
So, I think, they'll stick to (Open)CVS for
at least another 10 years. Might be a good thing.
Try SSH connection multiplexing with CVS, and
the slowest part - the authentication phase -
is not repeated. Works really really good.
Laptops have usually 10-30 GB disc space and
128-256 MiB RAM. And WLAN, or worse: ADSL
access to the repo via Internet (can you say
768 kbps downstream, 128 kbps up?).
Open Source projects often have Pentium-class
systems as servers. Alpha. Vax. SPARCstation.
Neither are as large projects as an entire opera-
ting system with far above 100'000 files in the
CVS Repository.
Also, cvsweb won't work (viewcvs would, but it
uses Python, yuck, and is a worse nightmare to
patch/maintain), rsync on berkeley DBs is pretty
much unsupported, the new file storage is untested
and who-knows-what implications there are on lok-
king, and the biggest problem is anonCVS which
would not work any more. And nobody sane would
trust svn as a network server, or - worse - as
an Apache(tm) 2 module (henning@openbsd also
says Apache(tm) 2 is not broken code, but even
broken design, and that it will never ever run
on OpenBSD).
Also, RCS files are well-hung and (in the mean-
while) pretty documented files. Says someone
who's hung in there with rcs(1) commands as well
as $EDITOR countless times in the last 3 years.
Now now. That's definitively FTP's fault, and IMHO
this pre-1980 protocol deserves to finally die
anyway.
What's wrong with using HTTP for fast public down-
loads, SCP/SFTP for secured file transfers and if
it really has to be fast, netcat (and ssh to start
netcat on the remote end)?
Even Windows®-FTP-Clients do usually support SFTP.
Try a
/cvs
$ du -sk
I'm running an OpenBSD fork, and probably have
less code in my CVS than them, but it's about
1.55 GB for us right now.
I don't trust a Berkeley DB this far, and the new
filesystem backend of svn is... smelly.
In addition to that, Benny tried to play with
only the ports tree in a svn repo. Checking it
out after the import, with no mods yet, required
already 384 MiB RAM and swap. That's too much.
Our main CVS server is a Soekris net4801.
MirBSD: being out for >2 years, continuous improvements
in quality, actuality, smallity(?) and number of
both users and developers.
http://mirbsd.de/ for you. The new 4th BSD.
(I like that mascot, w00t)
MirBSD: being out for >2 years, continuous improvements
in quality, actuality, smallity(?) and number of
both users and developers.
http://mirbsd.de/ for you.
You'll be soon supposed to know metrics in and out,/ usr. bin/cvs/doc/cvs.texinfo.diff?r1=1.8&r2=1.9&f=u ;-)
e.g. take a look at the 14th line of
http://mirbsd.bsdadvocacy.org/cvs.cgi/src/gnu
which you are supposed to read too
It does not work in Lynx.
;-)
Still the best webbrowser available
Nah, if I had known that I had not ported GNU
CVS 1.12 and rather peeked into OpenCVS, maybe
helped with it (since I know CVS and RCS pretty
well, after 2+ years of running my own).
It was not even imported.
One 'cvs add' for the directory
src/usr.bin/cvs
Then M mails for files which ought
to not exist (according to the eMails before)
Actually, you can sell GPL'd software. If it's
binaries, you just have to deliver the sources.
And you can't prevent your customers from giving
away for free what they bought from you.
I'm developer of an OpenBSD fork/derivate (and
slightly pissed off that I heard of this only
yesterday, and not 4 weeks ago or so when they
started; so much for their "live cvs mails"),
and I started to replace our outdated cvs 1.11.1p1
with many many local patches by a modern GNU
cvs 1.12.10 two weeks ago. It's not exactly
compatible with the old CVS, but it works pretty
well for now, and I had not to fix too much.
The code for 1.12 has actually improved a lot.
I won't jump onto the wagon for OpenCVS right
now, even if I'd like to for licence reasons.
First, I'm still pissed off, second, GNU CVS
is well-hung, proven code and we're relying
on it.
Subversion is, how much benz asks it, not an
option. For example, in a subversion repo only
containing the MirPorts Framework, a check-out
temporarily requires about 384 MiB RAM, which
is just too much. Our master CVS server is a
Soekris net4801 with 128 MiB RAM and a 266 MHz
Pentium-compatible Geode CPU, which also serves
as my home ADSL router and firewall.
Plus I don't trust databases.
The German-language Slashdot equivalent symlink.lu4 249&mode=nested
/.
has had this for ages (two days longer), cf.
http://www.symlink.ch/article.pl?sid=04/12/02/095
On the other hand, ln-s often symlinks to
Although they are no longer documented, I
a ble). It does various character sets
accidentally hit ^Qc in Borland C++ 5 or so
while hacking (at work), and it took me to
the end of the file. So they still worked.
Do these still work in modern Delphi?
For anyone who wants a simple, free text
editor for Unices (and DOS and Win and...)
which has got these keybindings, can optio-
nally do syntax highlighting and is configu-
rable, check out my "jupp" modifications to
the JOE's Own Editor at
http://wiki.mirbsd.de/JuppEditor
(there are binaries for Mac OSX 10.3.5 I
compiled on my shell acct. at
http://users.mirsolutions.de/~tg/binaries/
avail
(almost any single-byte charset, including a
custom Klingon one, and UTF-8 - no DBCS such
as EUC-JP yet though), even on non-locale-aware
operating systems such as OpenBSD or my own
project MirOS.
OTOH I have made even more PITA efforts and created
MirLibtool and a framework which replaces all known
instances of GNU libtool with it, then runs a patched
GNU autoconf (2.13 or 2.59, according to what the
package needs) over it, before running configure.
This is based upon work from the OpenBSD ports tree:
metaauto - install more than one autoconf at once
gnu.port.mk - replace config.guess and config.sub
and control invoking autoconf/autoheader
And work by myself:
autoconf - integrate Tom Dickey's patches into
2.13 and fix 2.13 and 2.59 up enough
libtool - vandalize 1.5 so it works on both
autoconf versions