NTPD isn't good enough for me -- bad weather on the Internet has caused
my server to loose synchronization one too many times,
Your NTP setup is misconfigured if this is the case.
The NTP daemon has many algorithms built in to measure jitter (how "off"
a clock is from what NTP thinks is the realtime) and factors in network
delay as well. (Run ntpq
-p to see a list of time servers that your NTP client is
accessing and their associated jitter/delay/offset values.)
NTP's primary job is to poll various time servers, figure out which ones
are good and use that data to set your clock. This so called "bad
weather" you refer to should not be a problem for NTP if it is setup
correctly.
As others have mentioned in this thread, you should set up one or two
primary NTP servers that probe external servers (preferably from
the pool.) and then have your
interval servers probe those site-local time servers.
They need special tools to make simple text websites?
I have found that you don't need to have specialized tools or make special websites
for mobile devices as long as you follow the standards and generally accepted
web design principles.
Case in point: I was able to surf on Google on my BlackBerry just fine,
even before they added a special mobile section. Google more or less used
sane HTML+CSS and I really didn't have any major issues with them.
Other sites however, were doing funky things with JavaScript and Flash
and other non-standard or ill-conceived technologies (e.g. by making
their site completely useless unless you were running MSIE 6.x at exactly
1024x768 with ActiveX enabled) so I was never able to visit them at all.
No special tool can compensate for lack of common sense
CVSup is *the* way to update the software and the OS on FreeBSD. You keep your/usr/ports tree and src distribution of the OS in sync with the official repositories using it. It is very similar to rsync, but takes advantage of CVS source code repositories (FreeBSD is stored in CVS).
It is a great tool, and really the only downside to using it is that it was written in Modula-3. Building CVSup from sources required a *lot* of time and was unnecessarily complex. To remedy this, the author of CVSup released a language called ezm3, which is basically a stripped down version of the Modula-3 source base that "contains only those components which are required for building and running CVSup". So to build CVSup, you first built ezm3.
As you can imagine, getting Modula-3 compiled on your system (even if it
is a stripped down version of Modula-3), just to run CVSup was seen as
overkill. But what really prompted work on csup (according to the
authors) was because "the Modula-3 runtime environment was not
ported to all the architectures supported by the various *BSD
projects, and it was becoming increasingly harder to find people for
maintaining the code."
csup is a rewrite of the CVSup software in C. I It is pretty fast,
but currently supports checkout mode only -- not that big a deal, since
most people only us CVSup to keep their ports and OS src trees in sync
with the upstream repositories. Furthermore, since it is written in C,
this has allowed them to put it in the base FreeBSD distribution instead
of shipping it as a separate package.
One of the better worm analysis papers I've read was "Reflections on
Witty" by Nicholas Weaver and
Dan Ellis (of MITRE), published in the June 2004
issue of ;login, the
Usenix
magazine.
Rather than a dissection of the worm itself, the authors give a
detailed analysis of the author/attacker of Witty.
Some insights about the worm author that Weaver and Ellis
proposed:
he was a fairly proficient programmer - there were no significant
bugs in the code of the worm, he knew how to program x86 assembly and
access the Windows API, he implemented a stack-overflow attack, and most
importantly, he constructed a payload that was malicious to the host,
but didn't significantly slow the worm's spread.
he was quite clever at what he did - randomly padded packet sizes,
randomized the destinations and port numbers, and he seeded the worm
(rather than start at a single location, the worm started out from 110
different victims) -- prior to this no one had significantly seeded
their worms
he wrote compact code, Witty consists of 177 x86 instructions in
474 bytes (the rest is the buffer overflow and padding); with 177
instructions, he was able to construct routines to cleanup from the
overflow attack, seed the RNG, propagate the worm, and execute the
malicious payload (Witty slowly overwrites disks on the infected hosts
until the machine crashes)
he worked quite fast; the stack overflow in the ISS
BlackIce products was published on March 18, 2004. Witty was released on
March 19, 2004, less than 48 hours after the security advisory was
published by eEye; it is possible that he knew of the vulnerability when eEye
notified ISS on March 8, 2004, but the paper goes into why this is
unlikely
he probably tested the worm before he released it (cf. the lack of
major bugs); this combined with the fact that he seeded on 110 hosts,
means that he had access to a wide array of compromised machines -- it
probably means he has access to the "hacker underground", to gain access
to these machines in such a short time frame
The authors' conclusion is somewhat alarming, they reason that Witty
represents a new generation of virus/worm authors: motivated, skilled
and malicious individuals who are experts at what they do.
Of course most of the projects collapsed! VCs dump money into lots
of projects with the full knowledge that the vast majority won't come
close to turning a profit.
False.
Steve Bourne gave a talk last year at Columbia University about his
Venture Capital company, El Dorado Ventures (it's a fascinating story
how he went from writing Unix shells to becoming a VC). I forget the
exact details, but trust me when I say that VC firms most certainly do
not expect their projects to fail. Out of all the proposals that come
their way, they allow a very small fraction to give one hour
presentations to the VC firm partners. From those, they select an even
smaller percentage to actually fund.
IIRC, roughly half the projects fail.
It's the handful that do that make a VC company a fortune.
Perhaps. Still referring to Dr. Bourne's talk, out of the half that
do not fail, a majority of those are successful and give the VC firms
fairly good returns on their investment. A very small fraction of those
are "astronomically successful" and give the VC firm a very good return
on their investment. He did emphasize however that the number of
projects in this last group was quite small.
Overall, I got the impression that they thoroughly screen the
projects that they invest in and I'm fairly certain other VC firms do
the exact same thing.
You make a mistake in thinking that VC firms "gamble" with their
capital, i.e. that they put a million dollars each into 10 companies,
expect 9 to fail, and the 10th to return 100 million. This is most
certainly not the case. Partners in VC firms did not get their positions
by throwing huge sums of cash around so easily.
At some point during his excellent talk on the history of Unix and his
place in it, someone asked what he thought was the reason for the
success of the operating system, and without hesitating, he talked about
the room where all the terminals were located (he never specifically
referred to it as the "Unix room" though) and how when you released
software it was used immediately by those in the room and if
something broke, you were called "idiot" (and probably worse) by your
peers -- it was in your best interest to make sure you didn't put out
junk as you really didn't have that dilution of responsibility that
engineers have in a large corporation where the design team is in one
wing of the building, the coders are in another, and the testers in yet
another location, etc.
It was a great speech, anyone who hasn't seen Dr. Bourne speak should do
so, he is an excellent source of insight into the early years of Unix
and software engineering in general. He is now working for a venture
capital firm and roughly a third of his talk was spent talking about
that, it's a testament to his great speaking skills that most of the
people in the room didn't lose interest when he switched topics like
that (I'm convinced that most hackers suffer from ADD).
You can download a pre-compiled binary, but it was several builds behind and
missing some vital features when we made the switch, and so we had to compile
from source.
I fail to see how this is a Subversion problem. The developers (almost
none of whom get paid to work on the project) shouldn't be required to
compile binaries for every operating system out there. That should be
the job of your OS's package maintainer.
There are numerous dependencies that are all in unstable status, we had
to upgrade and recompile half the server platform just to get svn built.
I think you're abusing the word "unstable" here. Subversion may use the
latest and greatest versions of some libraries, but I don't think
any are in alpha or beta status. (Could you point out any that are?)
Now, if you are having problems with your dependencies not being up to
date, take that up with your package maintainer, whoever that may be.
CVS allowed per-user authentication, such that I could set up some users
to be authenticated as read/write and others as read-only, for the cases
when a non-committer needed an update of the code immediately without us
having to go off and build a tarball and have them download it.
Subversion does not support this, instead allowing "anonymous" and
"authenticated" access levels - you're either logged in or not, and get
read/write permission accordingly, with no ability to configure
permissions on a per-user basis.
False.
Subversion most certainly allows you to configure permissions on a
per-user basis. It even goes so far as to allow you to fine-tune those
permissions on a directory level (i.e./src/foo is read-writeable while/src/bar is only readable and/src/quux is off-limits).
Don't place the blame for your failure to thoroughly read the
documentation on Subversion.
CVS allows you to use a standard htpasswd file for storing hashed passwords
along with user names. Subversion requires the passwords to be in plain text
mode, so I had to ask all my developers to generate random passwords so that I
wouldn't be accidentally exposed to passwords they use for other things.
This issue has been beaten to death several times on the mailing lists.
Please read the archives.
We can't use the web-svn server because it needs to run through Apache 2.0 and
we're running 1.3 still, without the option to upgrade because of some other
plugins that haven't been ported.
And who said you have to upgrade your webserver to run Subversion? You
can run Apache 1 and 2 just fine on the same machine, just use a
different port for Apache 2.
Overall, I'm not very impressed with Subversion, and will probably still keep
updated my CVS repository in parallel until SVN gets its act in order. I'll
take a look and see if 1.1 fixes any of my complaints.
Overall, I'm not very impressed with your inability to read
documentation before you make uneducated statements like "People told
me that svn supported various things, and convinced me to make the
upgrade; they were largely incorrect, and this "CVS replacement" doesn't
really deserve to be at 1.0, let alone 1.1."
Subversion, like any other tool, requires a bit of effort to switch over
to. But the Subversion devs are smart people who have dealt with (and
solved) all of the issues that you brought up. It is not perfect, but it
is being actively developed and baseless complaining doesn't help
anyone. In future, I advise you to read the docs completely, and ask the
proper questions in the proper channels before you begin to criticize.
Don't get me wrong, Subversion has its share of problems. Some of these
can be fixed, others require significant design overhauls before they
can be addressed. But unfounded claims such as yours shouldn't need to
be addressed several times per week just because you can't be bothered
to look into them properly.
Why is the new fsfs repository such a big deal ?(unless you do store it on
network filesystems?)
It is a very big deal if you've used Subversion for any appreciable
amount of time. See my other post in this thread for a more
detailed overview of BDB vs. FSFS. Or just take a look at the
Greg Hudson FSFS document.
There is the little note; "Note that the data files created by fsfs
repositories are still in a binary format, and are not human editable!"
Which brings up the question, why do you want your repositories to be
human editable? With CVS, you needed it because CVS regularly screwed up
your repository, with Subversion, that's guaranteed not to happen.
Also, when you use apps that use Berkeley DB, PostgreSQL, MySQL, Oracle,
MS SQL, Sybase, or DB2 as a backend, does it bother you that your data
is not human editable? Why should you worry so much about Subversion
then?
And can it do hot backup, with guaranteed atomicity?
One of the bigger changes that users of 1.0.x will see when upgrading is
Greg Hudson's awesome new FSFS filesystem.
Subversion uses a db-like transactional filesystem to store your files,
up until v1.1, Subversion used Berkeley DB to implement this filesystem.
But BDB was somewhat of a headache for many Subversion users. Some
issues:
no networked filesystem - since BDB (along with many other databases)
used file locking features that were not available over network shares,
you couldn't host your Subversion project over NFS/AFS/CIFS(Samba).
With FSFS this problem is gone.
wedged repositories - for some people their Subversion filesystem would
inexplicably "lock up", requiring the sysadmin to run "sdvnadmin
recover" on the repo. It was actually BDB that locked up, and sdvnadmin
recover actually ran the Berkeley DB recovery procedure on a repository,
but most people blamed Subversion.
This never happens with FSFS.
smaller repositories - because it stores deltas, FSFS repositories are
smaller than BDB ones. Greg Hudson's FSFS documents claims that "space
savings are on the order of 10-20%", but that's a modest claim. I've
personally seen myself (and others have mentioned) significantly
smaller repos when switching over to FSFS.
Of course there are a ton of other nice fixes and improvements to 1.1,
but FSFS shines above the rest.
Also, there are rumors that FSFS will soon become the default filesystem
in Subversion, I for one will welcome that change.
For more information about FSFS, Greg Hudson's
original FSFS document
is required reading.
I'm sorry if this post comes off as Berkeley DB bashing, I really didn't
intend for it to be like that. To be fair, I think that Subversion put
DB to use in ways that perhaps it was not intended to, and coupled with
the fact that Berkeley DB is mostly a commercial product,
I can sort of see why an opensource project like Subversion would take
backseat to Sleepycat's paying customers.
(I should probably mention
that Sleepycat recently placed one of their employees as a "Subversion
liaison" to help resolve BDB bugs/issues quicker.)
I remember hearing a few years ago that the folks who ran tick and tock
asked that only second-tier time servers sync to them, and that all the "leaf
nodes" sync to a second-tier server.
I heard something similar a while back, but in this case, the guilty
parties were sticking ntpdate(1) into a cronjob and pointing it
at the time servers, having it run at the top of every hour. =-(
In response, I posted the following notice. I'm reproducing it here
(without updates or corrections), in the hopes that may be helpful:
To: debian-user@lists.debian.org
Subject: ntpdate from cron -- DON'T DO THAT!
From: "N. Thomas" <nthomas@cise.ufl.edu>
Date: Sat, 21 Dec 2002 18:51:24 -0500
Contrary to what you may have heard, ntpdate does not keep your system
clock synced. Also ignore the foolish recommendations to run ntpdate
from a cron job.
ntpdate works like date(1), but it sets your clock's time to that of an
ntp server (or servers) instead of having it specified by you.
If you want to keep your clock in sync use ntpd -- that's what it was
designed for. It uses many sophisticated algorithms and statistical
methods to accomplish this. After some time, it can even figure out how
"bad" your system clock is (i.e. its drift) and compensate for it, even
if your network connection goes out.
Unfortunately, some people, instead of taking the time to read the ntp
documentation and writing a proper ntp.conf file, took the easy route
and started running ntpdate from cron.
This caused two problems, firstly it did not keep very good time:
immediately after you called ntpdate, your clock would begin to drift
again. And more importantly, every hour or so, the ntp servers were
being affected by a "thunderclap" effect, the result of everybody
putting:
0 * * * */usr/local/bin/ntpdate
or something similar into their crontab files. The ntp daemon does not
do this as it randomizes the time it waits between queries.
For this reason, Dr. Mills (ntp author) has deprecated ntpdate, and
indeed, he will be removing it completely from a future release.
In addition to helping those without a handy ntp server, pool.ntp.org
actually helps to minimize "wear and tear" on the popular NTP servers.
Congratulations are in order to Mr. von Bidder for coming up with this
great system.
The one thing that is pushing me to upgrade is Subversion. According
to Subversion's website, you need a 2.X binary to run the Apache plugin.
This may be the first really big push for 2.X.
As another user pointed out, you don't need to have Apache 2 running as
your webserver if you want to access
Subversion.
You can do one of the following:
Run Apache 1.x as your webserver on port 80, and then have Apache 2.x
running side-by-side as a separate server and have it listen on port
3690, the port that
IANA
has reserved for the Subversion protocol.
Instead of Apache, run the lightweight Subversion server
svnserve. It's quite simple to set up compared to Apache,
but can only grant blanket read/write permissions. Also, you can't
fine-tune
permissions on a per-directory basis like you can with Apache.
If you have pre-existing accounts on your system, you can tunnel
through ssh via the svn+ssh://host/path/to/repo pragma which will
authenticate itself via ssh and use the Unix file permissions on the
repository.
If you are the only one accessing your repository, you can even use
the
file:///path/to/repo pragma and forego a server altogether.
Each method has its benefits and disadvantages,
you will want to evaluate all of them and choose one best suited to your
business logic.
Also, you definitely want to read over the upcoming O'Reily book Version Control with Subversion (see Chapter 6, "Server
Configuration"). Good luck.
svnadmin comes with a command that you run on your repository
called list-unused-dblogs, it will tell you what Berkeley DB
log files are unused, which you can then delete. But usually people will
want to just run:
svnadmin list-unused-dblogs repository | xargs rm
All of this is moot if you are running Berkeley DB 4.2 or greater -- it
cleans unused log files automatically.
Quite hard to share repositories
Decentralized repositories is one feature Subversion does not
have (yet). But take a look at SVK
which is what the Subversion developers currently recommends to anyone
looking for this feature.
No way to mark your branches (if you accidentally check out the
directory containing your branches, you just got 50 gigs of 99.9%
identical files...)
Which is why the current best practice is to lay out your repository
like this:
/ /trunk /tags /branches
This way, you put your main trunk in/trunk, and all your
branches would go into/branches.
Now when you go to check something out, check it out from the
appropriate directory.
We'd like to move to Subversion, but can't, until they get annotate
('svn blame') fully working, because GCC developers spend a lot of time
doing "revision-control archaeology".
Just curious, 'svn blame' was added 2003-10. What about it is not
working for you?
It bothers me a bit that all the files are now in a big database.
When you used PostgreSQL, MySQL, or Oracle, does it bother you that your
data is in a big database? Why do you worry so much about Subversion
then?
A good thing about CVS is that you can see what files and modules are
available using regular unix tools, and if things get messed up in some
way you can always fall back to the rcs commands or in the worst case
edit the,v file by hand and extract the latest version.
It is a good thing that you were able to hand-edit CVS repositories when
they got corrupted -- because corrupt CVS repositories are a dime a
dozen.
I've been using Subversion since January 2002 (yes, a full two years
before 1.0 came out.) and I have never, ever, ever seen a
corrupt repository or heard about one on the mailing lists.
When someone did claim that they thought Subversion corrupted their
repositories, the Subversion devs dropped everything to make sure this
wasn't the case. AFAIK, it has never happened. (Usually it was the
person using multiple servers to access their repo or putting their repo
on a network share (Berkeley DB doesn't work over NFS/AFS/CIFS.))
Let me quote a Slasdot posting of mine from a couple of years ago:
...there is nothing that the dev team values more than the integrity
of your data. Nothing. This means that once something has been comitted, it will never be
lost.
Q: And yet you've been famously cool about Linux.
A: Re-implementing what I designed in 1979 is not interesting to me personally.
[...]
Q: All right, you win. What are you doing for fun these days?
A: I'm figuring out a meditation wall for my apartment in New York.
Eight feet high by 12 feet wide, with an array of overlapping rear
projectors, each with a tiny Linux box and connected by gigabit
Ethernet.
Fascinating.
Linux is 1979 technology and yet runs the projectors for his meditation
wall -- built by a Walt Disney Imagineer and the inventor of massively
parallel supercomputing.
I should like to ask Mr. Joy why these projectors are not running Mac OS
X or even Solaris. Perhaps he owes a greater debt to those kids 20 years
his junior than he imagines?
In addition to the good advice proffered by the article, I should also
like to add that using good libraries can make a world of difference.
For example, for the C program that I'm writing right now, I decided to
use
GLib
-- the base utillity library used by
GTK.
I initially chose it for portability reasons, but soon discovered it had
a wealth of cool stuff in it. In addition to providing the standard data
structures (trees, hashes, linked lists), it also has a string type
(
GString,
) which handles a lot of the string issues that C
programmers get bogged down with.
A lot of the gotchas (buffer overflows, et. al.) mentioned in this
article have to do with these string issues, and using GLib's GString
data type has enabled me to avoid those.
In addition to all this, I'm using XML as the storage format for my
program, mostly because
libxml takes care of the file parsing issues so I don't have to.
Bottom line, choose your libraries carefully, they can make a world of
difference.
Although it was mentioned in the article, I think it should be
emphasized that the SI definition of the kilogram, unlike their
definitions of the meter and second, cannot be reproduced -- or rather, reproduced exactly.
This is quite important, as it is neccessary for the
standards governing body in each country to have a
very precise reference weight of their own.
Since there is only one reference object for the kilogram, everything
else is just a copy -- and even if it is a first generation copy, errors
are bound to creep in.
The redefinition of the kg is long overdue, mad props to the scientists
working on this.
Seriously, though, how, other than using it for real, might one test
subversion? And how would you recover from the bugs that will be in there
without devoting your life to it for a few weeks?
You raise some serious concerns, let me try and alleviate those fears.
I've been using Subversion for a few months now (since revision 1210 or so),
and let me to tell you, there is nothing that the dev team values more
than the integrity of your data. Nothing. This means that once
something has been comitted, it will never be lost.
Does this mean your data is guaranteed with an alpha-quality system? No. But
let me tell you, in 6 months I've not seen it happen once. Oh sure, there
have been a few times when the DB schema changed, and the format of the
dumpfile (more on that in a bit) changed on you, but these things were
discussed well in advance on the dev list and not only did you have plenty
of opportunity to prep your data for the change, there were ways for you to
convert your data after the fact.
If you are the sort of person that likes to tweak around with your data in
the repository (if you come from a CVS background -- you have to be) and
gets the heeby-jeebies from having your data stored in a non-accessible
format, let me ask you this, do you worry about the fact that you have data
stored in Oracle/Postgres/Sybase/MySQL? No? Then why worry about the
Subversion repository at all?
Of course, the dev team has provided you with some nice backup tools, for
example, the normal Unix cp command can be used to make
hot-backups of your repostories, a very cool trick. In addition, there is an
svnadmin command that has a "dump" feature that allows you to store
your repository in a text file, if you worry about Subversion trashing your
data, keep regular dumps of your repository.
Of course, all is not rosy. I would like to see a patchsets feature, and I
really miss "cvs annotate" (but "svn blame" is scheduled to be added after
the 1.0 release), and of course, the db has a tendency to lock up every once
in a while (you can fix it easily with db_recover) but by and large, these
are things I can live with.
After using this system for a while, I've come to one conclusion: it works.
And it works better than CVS. Forget the years of bad habits you learned on
CVS, once you start using Subversion, you will start to think about SCM
systems in a whole new way. Try it out.
The same problems I had with trying to learn Expect, I had trying to learn CVS: lack of good online tutorials & documentation.
Richard Stallman (a man with whom I disagree on a great many topics) said it best: He had heard so many good things about Perl, and wanted to learn the language, but when he started looking for online tutorials, the ones he found were far and few in between, and not to mention of very low quality. Everybody kept telling him to buy the (O'Reilly) "books", but he wanted online stuff, stuff that just wasn't available.
When I wanted to learn Expect, I asked around, and posted to the newsgroup, on where would be a good place to learn, everybody replied, "get the Exploring Expect book." When I told them I couldn't afford it, I just got a "tough luck" and a shrug.
I have been wanting to learn how to use CVS for quite some time now, and I'm sure this book is great for someone that can afford to shell out the $40 bucks for it, but I can't, so can anyone point me to some good docs?
For those of you considering purchasing a calculator from TI, I would strongly recommend you look at an HP instead.
Switching to an HP from TI is like converting from DOS to Unix. The RPN method of calculation alone should be enough for you to switch. HPs are much, much, much more programmer friendly than the TI's.
As far as the argument goes for the TI-92, an oversized monster that retails for about $300US, I would say to you that you should look at a laptop/handheld instead for that kind of money.
A calculator is a calculator, it is not a computer. If you want to purchase a computer try Dell. If you want to purchase a calculator, then I recommend the HP series.
I'm not even going to go into the fact most (if not all) of the functionality that are introduced in the newer TI models have been around in the HPs for several years.
But when it comes down to it, having the single correct tool always beats any mutli-tool that will be ever made.
I was thinking about purchasing a Leatherman Wave a while back, but I balked when I saw the $70 price tag. I purchased the micra for $15 instead, and for a little bit more cash ($250) I got myself a good toolbox and a nice set of tools. When I don't have my toolbox around, the micra might come in handy, but like the guy said, having the correct tool always beats using a multi-tool.
What every good hacker should have in their toolbox:
flashlight
working gloves
flat head screw drivers (3 sizes)
philips screw drivers (2 sizes)
a set of mini-screw drivers
pliers (various)
hammer
pen, pencil, notepad
ratchet set
electrical tape, duct tape, drafting tape
tape measure
level (comes in handy sometimes)
wire strippers
flush cutters (also called diagonal cuttters)
a drill with screwdriver bits (a must)
assorted computer tools (RAM pullers, etc.)
Obviously there is more I could add to this, but this is a start. If you are gonna spend $100 for a multi-purpose tool, considering making additions to your toolbox instead.
Slashdot Mirror
NTPD isn't good enough for me -- bad weather on the Internet has caused my server to loose synchronization one too many times,
Your NTP setup is misconfigured if this is the case.
The NTP daemon has many algorithms built in to measure jitter (how "off" a clock is from what NTP thinks is the realtime) and factors in network delay as well. (Run ntpq -p to see a list of time servers that your NTP client is accessing and their associated jitter/delay/offset values.)
NTP's primary job is to poll various time servers, figure out which ones are good and use that data to set your clock. This so called "bad weather" you refer to should not be a problem for NTP if it is setup correctly.
As others have mentioned in this thread, you should set up one or two primary NTP servers that probe external servers (preferably from the pool.) and then have your interval servers probe those site-local time servers.
Thomas
They need special tools to make simple text websites?
I have found that you don't need to have specialized tools or make special websites for mobile devices as long as you follow the standards and generally accepted web design principles.
Case in point: I was able to surf on Google on my BlackBerry just fine, even before they added a special mobile section. Google more or less used sane HTML+CSS and I really didn't have any major issues with them.
Other sites however, were doing funky things with JavaScript and Flash and other non-standard or ill-conceived technologies (e.g. by making their site completely useless unless you were running MSIE 6.x at exactly 1024x768 with ActiveX enabled) so I was never able to visit them at all.
No special tool can compensate for lack of common sense
Thomas
With 6.2, csup is even better...
/usr/ports tree and src distribution of the OS in sync with the official repositories using it. It is very similar to rsync, but takes advantage of CVS source code repositories (FreeBSD is stored in CVS).
To elaborate
CVSup is *the* way to update the software and the OS on FreeBSD. You keep your
It is a great tool, and really the only downside to using it is that it was written in Modula-3. Building CVSup from sources required a *lot* of time and was unnecessarily complex. To remedy this, the author of CVSup released a language called ezm3, which is basically a stripped down version of the Modula-3 source base that "contains only those components which are required for building and running CVSup". So to build CVSup, you first built ezm3.
As you can imagine, getting Modula-3 compiled on your system (even if it is a stripped down version of Modula-3), just to run CVSup was seen as overkill. But what really prompted work on csup (according to the authors) was because "the Modula-3 runtime environment was not ported to all the architectures supported by the various *BSD projects, and it was becoming increasingly harder to find people for maintaining the code."
csup is a rewrite of the CVSup software in C. I It is pretty fast, but currently supports checkout mode only -- not that big a deal, since most people only us CVSup to keep their ports and OS src trees in sync with the upstream repositories. Furthermore, since it is written in C, this has allowed them to put it in the base FreeBSD distribution instead of shipping it as a separate package.
One of the better worm analysis papers I've read was "Reflections on Witty" by Nicholas Weaver and Dan Ellis (of MITRE), published in the June 2004 issue of ;login, the
Usenix
magazine.
Rather than a dissection of the worm itself, the authors give a detailed analysis of the author/attacker of Witty.
Some insights about the worm author that Weaver and Ellis proposed:
The authors' conclusion is somewhat alarming, they reason that Witty represents a new generation of virus/worm authors: motivated, skilled and malicious individuals who are experts at what they do.
ThomasOf course most of the projects collapsed! VCs dump money into lots of projects with the full knowledge that the vast majority won't come close to turning a profit.
False.
Steve Bourne gave a talk last year at Columbia University about his Venture Capital company, El Dorado Ventures (it's a fascinating story how he went from writing Unix shells to becoming a VC). I forget the exact details, but trust me when I say that VC firms most certainly do not expect their projects to fail. Out of all the proposals that come their way, they allow a very small fraction to give one hour presentations to the VC firm partners. From those, they select an even smaller percentage to actually fund.
IIRC, roughly half the projects fail.
It's the handful that do that make a VC company a fortune.
Perhaps. Still referring to Dr. Bourne's talk, out of the half that do not fail, a majority of those are successful and give the VC firms fairly good returns on their investment. A very small fraction of those are "astronomically successful" and give the VC firm a very good return on their investment. He did emphasize however that the number of projects in this last group was quite small.
Overall, I got the impression that they thoroughly screen the projects that they invest in and I'm fairly certain other VC firms do the exact same thing.
You make a mistake in thinking that VC firms "gamble" with their capital, i.e. that they put a million dollars each into 10 companies, expect 9 to fail, and the 10th to return 100 million. This is most certainly not the case. Partners in VC firms did not get their positions by throwing huge sums of cash around so easily.
ThomasFascinating.
I was at Columbia University last week for a meeting sponsored by the local ACM chapter and LXNY, the speaker was Stephen Bourne (he who is sh).
At some point during his excellent talk on the history of Unix and his place in it, someone asked what he thought was the reason for the success of the operating system, and without hesitating, he talked about the room where all the terminals were located (he never specifically referred to it as the "Unix room" though) and how when you released software it was used immediately by those in the room and if something broke, you were called "idiot" (and probably worse) by your peers -- it was in your best interest to make sure you didn't put out junk as you really didn't have that dilution of responsibility that engineers have in a large corporation where the design team is in one wing of the building, the coders are in another, and the testers in yet another location, etc.
It was a great speech, anyone who hasn't seen Dr. Bourne speak should do so, he is an excellent source of insight into the early years of Unix and software engineering in general. He is now working for a venture capital firm and roughly a third of his talk was spent talking about that, it's a testament to his great speaking skills that most of the people in the room didn't lose interest when he switched topics like that (I'm convinced that most hackers suffer from ADD).
Thomas
I fail to see how this is a Subversion problem. The developers (almost none of whom get paid to work on the project) shouldn't be required to compile binaries for every operating system out there. That should be the job of your OS's package maintainer.
I think you're abusing the word "unstable" here. Subversion may use the latest and greatest versions of some libraries, but I don't think any are in alpha or beta status. (Could you point out any that are?)
Now, if you are having problems with your dependencies not being up to date, take that up with your package maintainer, whoever that may be.
False.
Subversion most certainly allows you to configure permissions on a per-user basis. It even goes so far as to allow you to fine-tune those permissions on a directory level (i.e. /src/foo is read-writeable while /src/bar is only readable and /src/quux is off-limits).
Don't place the blame for your failure to thoroughly read the documentation on Subversion.
This issue has been beaten to death several times on the mailing lists. Please read the archives.
And who said you have to upgrade your webserver to run Subversion? You can run Apache 1 and 2 just fine on the same machine, just use a different port for Apache 2.
Overall, I'm not very impressed with your inability to read documentation before you make uneducated statements like "People told me that svn supported various things, and convinced me to make the upgrade; they were largely incorrect, and this "CVS replacement" doesn't really deserve to be at 1.0, let alone 1.1."
Subversion, like any other tool, requires a bit of effort to switch over to. But the Subversion devs are smart people who have dealt with (and solved) all of the issues that you brought up. It is not perfect, but it is being actively developed and baseless complaining doesn't help anyone. In future, I advise you to read the docs completely, and ask the proper questions in the proper channels before you begin to criticize.
Don't get me wrong, Subversion has its share of problems. Some of these can be fixed, others require significant design overhauls before they can be addressed. But unfounded claims such as yours shouldn't need to be addressed several times per week just because you can't be bothered to look into them properly.
Thomas
It is a very big deal if you've used Subversion for any appreciable amount of time. See my other post in this thread for a more detailed overview of BDB vs. FSFS. Or just take a look at the Greg Hudson FSFS document.
There is the little note; "Note that the data files created by fsfs repositories are still in a binary format, and are not human editable!"
Which brings up the question, why do you want your repositories to be human editable? With CVS, you needed it because CVS regularly screwed up your repository, with Subversion, that's guaranteed not to happen.
Also, when you use apps that use Berkeley DB, PostgreSQL, MySQL, Oracle, MS SQL, Sybase, or DB2 as a backend, does it bother you that your data is not human editable? Why should you worry so much about Subversion then?
And can it do hot backup, with guaranteed atomicity?
Yes, "svnadmin hotcopy" works just fine.
Thomas
One of the bigger changes that users of 1.0.x will see when upgrading is Greg Hudson's awesome new FSFS filesystem.
Subversion uses a db-like transactional filesystem to store your files, up until v1.1, Subversion used Berkeley DB to implement this filesystem. But BDB was somewhat of a headache for many Subversion users. Some issues:
With FSFS this problem is gone.
This never happens with FSFS.
Of course there are a ton of other nice fixes and improvements to 1.1, but FSFS shines above the rest. Also, there are rumors that FSFS will soon become the default filesystem in Subversion, I for one will welcome that change.
For more information about FSFS, Greg Hudson's original FSFS document is required reading.
I'm sorry if this post comes off as Berkeley DB bashing, I really didn't intend for it to be like that. To be fair, I think that Subversion put DB to use in ways that perhaps it was not intended to, and coupled with the fact that Berkeley DB is mostly a commercial product, I can sort of see why an opensource project like Subversion would take backseat to Sleepycat's paying customers. (I should probably mention that Sleepycat recently placed one of their employees as a "Subversion liaison" to help resolve BDB bugs/issues quicker.)
Thomas
I remember hearing a few years ago that the folks who ran tick and tock asked that only second-tier time servers sync to them, and that all the "leaf nodes" sync to a second-tier server.
I heard something similar a while back, but in this case, the guilty parties were sticking ntpdate(1) into a cronjob and pointing it at the time servers, having it run at the top of every hour. =-(
In response, I posted the following notice. I'm reproducing it here (without updates or corrections), in the hopes that may be helpful:
In addition to helping those without a handy ntp server, pool.ntp.org actually helps to minimize "wear and tear" on the popular NTP servers. Congratulations are in order to Mr. von Bidder for coming up with this great system.
Thomas
As another user pointed out, you don't need to have Apache 2 running as your webserver if you want to access Subversion. You can do one of the following:
-
Run Apache 1.x as your webserver on port 80, and then have Apache 2.x
running side-by-side as a separate server and have it listen on port
3690, the port that
IANA
has reserved for the Subversion protocol.
-
Instead of Apache, run the lightweight Subversion server
svnserve. It's quite simple to set up compared to Apache,
but can only grant blanket read/write permissions. Also, you can't
fine-tune
permissions on a per-directory basis like you can with Apache.
-
If you have pre-existing accounts on your system, you can tunnel
through ssh via the svn+ssh://host/path/to/repo pragma which will
authenticate itself via ssh and use the Unix file permissions on the
repository.
-
If you are the only one accessing your repository, you can even use
the
file:///path/to/repo pragma and forego a server altogether.
Each method has its benefits and disadvantages, you will want to evaluate all of them and choose one best suited to your business logic. Also, you definitely want to read over the upcoming O'Reily book Version Control with Subversion (see Chapter 6, "Server Configuration"). Good luck.Thomas
Database & log files take up a LOT of space.
svnadmin comes with a command that you run on your repository called list-unused-dblogs, it will tell you what Berkeley DB log files are unused, which you can then delete. But usually people will want to just run:
All of this is moot if you are running Berkeley DB 4.2 or greater -- it cleans unused log files automatically.Quite hard to share repositories
Decentralized repositories is one feature Subversion does not have (yet). But take a look at SVK which is what the Subversion developers currently recommends to anyone looking for this feature.
No way to mark your branches (if you accidentally check out the directory containing your branches, you just got 50 gigs of 99.9% identical files...)
Which is why the current best practice is to lay out your repository like this:
This way, you put your main trunk inYou did read the online Subversion O'Reilly book, didn't you?
No distributed development
I don't know what you mean by this, and how it differs from your "shared repositories" point above. Can you disambiguate?
Thomas
Just curious, 'svn blame' was added 2003-10. What about it is not working for you?
Thomas
When you used PostgreSQL, MySQL, or Oracle, does it bother you that your data is in a big database? Why do you worry so much about Subversion then?
A good thing about CVS is that you can see what files and modules are available using regular unix tools, and if things get messed up in some way you can always fall back to the rcs commands or in the worst case edit the ,v file by hand and extract the latest version.
It is a good thing that you were able to hand-edit CVS repositories when they got corrupted -- because corrupt CVS repositories are a dime a dozen.
I've been using Subversion since January 2002 (yes, a full two years before 1.0 came out.) and I have never, ever, ever seen a corrupt repository or heard about one on the mailing lists. When someone did claim that they thought Subversion corrupted their repositories, the Subversion devs dropped everything to make sure this wasn't the case. AFAIK, it has never happened. (Usually it was the person using multiple servers to access their repo or putting their repo on a network share (Berkeley DB doesn't work over NFS/AFS/CIFS.))
Let me quote a Slasdot posting of mine from a couple of years ago:
My opinion has not changed in the past two years.Thomas
A: Re-implementing what I designed in 1979 is not interesting to me personally.
[...]
Q: All right, you win. What are you doing for fun these days?
A: I'm figuring out a meditation wall for my apartment in New York. Eight feet high by 12 feet wide, with an array of overlapping rear projectors, each with a tiny Linux box and connected by gigabit Ethernet.
Fascinating.
Linux is 1979 technology and yet runs the projectors for his meditation wall -- built by a Walt Disney Imagineer and the inventor of massively parallel supercomputing.
I should like to ask Mr. Joy why these projectors are not running Mac OS X or even Solaris. Perhaps he owes a greater debt to those kids 20 years his junior than he imagines?
Thomas
Paul Graham (of Bayesian filtering and Lisp fame) wrote an excellent article called Java's Cover.
It is about why he thinks Java is bad technology -- despite never having used the language. Very interesting read.
Thomas
For example, for the C program that I'm writing right now, I decided to use GLib -- the base utillity library used by GTK.
I initially chose it for portability reasons, but soon discovered it had a wealth of cool stuff in it. In addition to providing the standard data structures (trees, hashes, linked lists), it also has a string type ( GString, ) which handles a lot of the string issues that C programmers get bogged down with.
A lot of the gotchas (buffer overflows, et. al.) mentioned in this article have to do with these string issues, and using GLib's GString data type has enabled me to avoid those.
There is another library similar to GLib, The Apache Portable Runtime, used in the Apache webserver, and also in Subversion.
In addition to all this, I'm using XML as the storage format for my program, mostly because libxml takes care of the file parsing issues so I don't have to.
Bottom line, choose your libraries carefully, they can make a world of difference.
Thomas
Since there is only one reference object for the kilogram, everything else is just a copy -- and even if it is a first generation copy, errors are bound to creep in.
The redefinition of the kg is long overdue, mad props to the scientists working on this.
Seriously, though, how, other than using it for real, might one test subversion? And how would you recover from the bugs that will be in there without devoting your life to it for a few weeks?
You raise some serious concerns, let me try and alleviate those fears.
I've been using Subversion for a few months now (since revision 1210 or so), and let me to tell you, there is nothing that the dev team values more than the integrity of your data. Nothing. This means that once something has been comitted, it will never be lost.
Does this mean your data is guaranteed with an alpha-quality system? No. But let me tell you, in 6 months I've not seen it happen once. Oh sure, there have been a few times when the DB schema changed, and the format of the dumpfile (more on that in a bit) changed on you, but these things were discussed well in advance on the dev list and not only did you have plenty of opportunity to prep your data for the change, there were ways for you to convert your data after the fact.
If you are the sort of person that likes to tweak around with your data in the repository (if you come from a CVS background -- you have to be) and gets the heeby-jeebies from having your data stored in a non-accessible format, let me ask you this, do you worry about the fact that you have data stored in Oracle/Postgres/Sybase/MySQL? No? Then why worry about the Subversion repository at all?
Of course, the dev team has provided you with some nice backup tools, for example, the normal Unix cp command can be used to make hot-backups of your repostories, a very cool trick. In addition, there is an svnadmin command that has a "dump" feature that allows you to store your repository in a text file, if you worry about Subversion trashing your data, keep regular dumps of your repository.
Of course, all is not rosy. I would like to see a patchsets feature, and I really miss "cvs annotate" (but "svn blame" is scheduled to be added after the 1.0 release), and of course, the db has a tendency to lock up every once in a while (you can fix it easily with db_recover) but by and large, these are things I can live with.
After using this system for a while, I've come to one conclusion: it works. And it works better than CVS. Forget the years of bad habits you learned on CVS, once you start using Subversion, you will start to think about SCM systems in a whole new way. Try it out.
Actually, dark yellow urine is not good at all.
Read the running newsgroups/mailing lists, you will soon find out that the clearer the color of the urine, the more hydrated your are.
If your urine is dark yellow, it means you aren't getting enough water, and that can't be a good thing.
The same problems I had with trying to learn Expect, I had trying to learn CVS: lack of good online tutorials & documentation.
Richard Stallman (a man with whom I disagree on a great many topics) said it best: He had heard so many good things about Perl, and wanted to learn the language, but when he started looking for online tutorials, the ones he found were far and few in between, and not to mention of very low quality. Everybody kept telling him to buy the (O'Reilly) "books", but he wanted online stuff, stuff that just wasn't available.
When I wanted to learn Expect, I asked around, and posted to the newsgroup, on where would be a good place to learn, everybody replied, "get the Exploring Expect book." When I told them I couldn't afford it, I just got a "tough luck" and a shrug.
I have been wanting to learn how to use CVS for quite some time now, and I'm sure this book is great for someone that can afford to shell out the $40 bucks for it, but I can't, so can anyone point me to some good docs?
--
N. Thomas
Switching to an HP from TI is like converting from DOS to Unix. The RPN method of calculation alone should be enough for you to switch. HPs are much, much, much more programmer friendly than the TI's.
As far as the argument goes for the TI-92, an oversized monster that retails for about $300US, I would say to you that you should look at a laptop/handheld instead for that kind of money.
A calculator is a calculator, it is not a computer. If you want to purchase a computer try Dell. If you want to purchase a calculator, then I recommend the HP series.
I'm not even going to go into the fact most (if not all) of the functionality that are introduced in the newer TI models have been around in the HPs for several years.
--
N. Thomas
From personal experience, E on Solaris (2.5 and 2.6) is slow, extremely buggy, and crashes very, very, very, often. I hope 0.16 bucks this trend.
--
N. Thomas
I have to read anything posted by 'the monkey flying around in my butt'
Just trying to provide some comic relief on a (usually) touchy issue. =-)
--
N. Thomas
nthomas@cise.ufl.edu
I was thinking about purchasing a Leatherman Wave a while back, but I balked when I saw the $70 price tag. I purchased the micra for $15 instead, and for a little bit more cash ($250) I got myself a good toolbox and a nice set of tools. When I don't have my toolbox around, the micra might come in handy, but like the guy said, having the correct tool always beats using a multi-tool.
What every good hacker should have in their toolbox:
Obviously there is more I could add to this, but this is a start. If you are gonna spend $100 for a multi-purpose tool, considering making additions to your toolbox instead.