And you missed it being completely unusable with any 'generic' programming - i.e. c++ templates. Just what class is 'subject' again? Oh, and there is also a rather annoying aspect where you are using class names like VehicleComposite (or vehicle_composite for you CamelCase allergic folk). Hungarian notation is IMO only useful for code too simple to need it.
Funnily enough, bitkeeper was inspired by the extant patch flows, not the other way around. And with projects like Arch, Monotone, Darcs... the natural layered review process is showing up again - once the tools support it.
How is this a troll? Arch is about to do it's third stable release, with features that the svn guys are only starting to cotton onto and copy. Extensability is essentially the ease with with new functionality can be added. Ask any of the arch hackers how easy it is to add features. Talk about external use of arch in scripts, talk about mail queues, talk about hook points. Talk about any of the features that have been added first as extensions, then integrated into the core only after their design has been proven. The use of WebDAV and Apache really has nothing to do with extensability - and SVN may be very extensible... I'm not saying anything about is or isn't. Just that the webDAV stuff is unrelated.
Ok, So I'm confused. http://subversion.tigris.org/project_issues.html says that 'Severity is represented in the Priority field. Here is how priority numbers map to severity:
* P1: Prevents work from getting done, causes data loss, or BFI ("Bad First Impression" -- too embarrassing for a 1.0 release). '
I haven't used volera, but AIUI it's derived from bordermanager, which in turn harks from the Harvest project - the same place squid came from. Bordermanager has been sweet every time I've used it, but not substantively different from Squid. ISA however, doesn't share that same heritage. It's also a bundle of products, of which you'll probably only want one bit... the proxy.
Please don't spread uneeded FUD...The NT port of squid is well maintained, Guido does a great job, and we're hoping before too much longer (3.1/3.2) to have it fully integrated. Oh, and squid/NT is more flexible than ISA any day of the week. Performance wise, 10-30 concurrent users of any web application I've seen translates to way less than 30 requests per second (rule of thumb from experience), which is well within squid/NT's performance envelope.
re archive-setup, let me add that init-tree can take a previously seven-step process: create-archive create-category create- branch create-version init-tree make-log impor t
down to three: create-archive init-tree import -S -s "initial import of project foo"
Certainly. It should be straight forward to convert reload into ims into an access-control driven directive (say reload_into_ims_access allow|deny acl..).
Still, I've not seen a windows update client set no-cache on their requests to date....
What comes to mind though, is that windows update clients (both the web interface, and automatic updates) use the MS http support libraries, that are configured via the internet options control panel. And in there, the 'check every time' option results in no-cache being put on every request..
Well, the sites I run happily cache all the udpates available via windows update. The only thing that doesn't cache is the https:// transfers (which I understand to be the catalog of available fixes).
You might want to analyze exactly what is occuring in your site(s).
> Ever watch American Idol? Remember the hundreds or > thousands of really really bad singers that never > make first cut? > > That's the real world, baby. Without "assholes" > like Simon that crap would pollute our airwaves, > and lead to a general disregard for "art".
Unlike the general disregard today?
You underestimate the 'general public'. Most folk I've met are quite capable of disambiguating unfiltered 'content' and filtered content.
What really disillusions folk is when the filtered content is crap - like most mainstream CD's for instance.
I expect that given the choice of filtering their own content, or only choosing from *badly* pre-filtered content, folk will choose to filter their own, in order to actually find something good.
Thus unfiltered content will not lead to a general disregard for art - we already have that.
I can't speak for VMS - not with any accuracy anyway:}.
On WIN32, creating a process involves: * Allocating a new thread and process kernel structs (~ Same overhead as COW fork()) * Map the process to be loaded into memory (COW fork() doesn't do this, but exec() does) * Recursively resolve all unresolved symbols. - which includes looking through the oftimes long PATH variable, as win32 doesn't have a separate LD_PATH. (COW fork() doesn't do this, but exec() does) * Attach all the loaded dll's (COW fork doesn't do this. exec() has something similar, IIRC). * Finally, the WinMain function gets to run (fork() doesn't start at main again, but exec() does).
So, the fork + exec model is roughly the same overhead as CreateProcess. The fork(), serve and exit() model is much lower on unix-like os's that support COW fork() because theres less to do. And any OS that has no kernel fork() call is way behind to start with.
Hope that helps. I've probably missed something critical and will now die a flaming death. Oh well:].
> > - Much quicker to create a thread than a process. > "Much" is the nit I am picking here. The main > difference between a process and a thread is that > threads share the VM. Modern operating systems do > Copy-On-Write (COW) for process creation.
Modem UNIX-LIKE operating systems, yes. But the all-processes-descend-from-init model is not the only one in existance. In fact, Win32 doesn't have a native fork() call at all. And it does have at least one native pthreads library (http://sources.redhat.com/pthreads-win32/).
So, under Win32, thread creation is *much* faster than process creation, for a number of reasons (and COW is only part of that).
I'm not sure where focus on IP address issues has come from... but RFC 2616 and RFC 2617 explicitly discuss secure access to WWW entities, and IP address's are not the key.
IP address restrictions are of only limited use, due to HTTP's stateless behaviour. As I've noted in another post, chains of proxies will quickly eliminate any IP based restrictions.
Some steps that JSTOR could take include adding cache-control headers (must-revalidate comes to mind) to prevent cache hits occuring without the JSTOR servers knowledge, and thus allow them to perform partial validation on the actual client (i.e. by checking the Via header). Note that checking the Via header is less-than-secure, but better than simply trusting the customers proxy to be secure.
Secondly, use authentication - assign a username and password to the content, using (say) Digest authentication, which is proxy friendly. Mark the content as explicitly cachable with revalidation, and you will get 1 If-Modified-Since request per download from proxies, and be able to check the user details each time. There would be an administrative issue with this, but I'll leave creative approachs to that as an exercise.
> From the page: We're sorry. You do not have > access to JSTOR from your current location. > > It seems they have some whitelist of allowed IPs. > Why not just traverse this once every so often and > look for open proxies?
Because this isn't sufficient. There may be two or more hops in an open proxy chain. The authorised IP may be locked down tight, and only allow internal IP's to access it - so it would pass the routine check. But *any* of those internal IP's could also run a proxy server. And that proxy may not be locked down.
I get ~half my income from overseas contracts. (Contracting on Squid development, living in Australia).
I always use a written contract - on the simple basis that if the work isn't long enough to need a clear statement of who,what,where,when and for how much, it ain't worth doing for money.
Once the contract is signed, you still have to communicate often, and clearly. All contracts do is set the goal posts - it's up to you to keep your customer happy while you approach them.
By Cygnus, I presume you mean Cygwin? Cygwin and VMWare are very different beasts. A cygwin linked program is 100% a native win32 executable. No Linux, No BSD. If the server team object to open source tools per se, then you are going to be unhappy no matter what.
> It starts off easy.. Go to www.cygwin.com, click > on the download icon, run the setup.exe tool.. > > And then it all goes to hell. It's truly > inconceivable that cygwin makes you click on > this miniscule icon (for those people at high > resolutions) for each and every sub-package that > you select. It's painful to describe and painful > to perform.
And I'd love to offer resizeable windows. It's a high priority feature, when RL allows time to do it. My first focus is getting the console version operable, but the GUI contributers are aware of my desire for this. Someone will do it eventually...
> And then there's the actual download- I've found > through painful experience that many of the > mirror sites don't contain the all of the cygwin > components you selected, or don't contain an up > to date cygwin distribution, or simply die in > the middle of your transfer. In some cases if > you start downloading packages from one mirror > and finish off with packages from another > mirror, dependencies don't work out right > because the packages on each mirror are > different versions! In any of these cases you > may spend up to an hour downloading and end up > with JUNK.
Use the multiple-mirror feature. Just like apt-get , setup will intelligently select the most recent packages from multiple mirrors, and fail over in the event of errors (including MD5 validation failures).
> All this could be changed if there was a simple > "default install, everything install, minimal > install, custom install" choice like there is in > ALMOST EVERY OTHER INSTALLER.
I suggested this, but was overrulled some time ago. Whilst I am the software maintainer, the mandate is to deliver an installer that the cygwin package maintainers as a group approve of. (See the cygwin-apps list archives if you want to read up on the discussion about this).
> You should also be able to download a single > package containing the cygwin subpackages for > your desired install. Ie, cygwin-standard.zip > like the netscape days of yore (and winamp).
Tough. Not going to happen. Various reasons dictate this, including the horrendous amount of wastage this would cause. (Last count I did cygwin had 184 packages, which gives a horribly big number when you consider all the possible combinations).
> Yes I know, "fix the code yourself!" say the > ignorant slashpeople. I do fix code myself, but > this UI is so intentionally bad the author > should have to fix it himself to learn a lesson.
Actually, I inherited the code from the previous maintainer. I'm doing this as a volunteer. I reject your assertion that the GUI is intentionally bad, and suggest you research a little more before stating 'facts' that are really just opinion.
> Ah, well that would do it then, eh? I suppose it > would be pretty trivial to write a non-gui > installer, though. Pity nobody has, but it should be > relatively simple to do. Point taken, though.
It might be relatively simple to do from scratch, but unless we want a maintenance nightmare, the retrieval logic, tar logic, package database management logic, should all be shared between all variants of the installer. And given that until very recently we could not use exceptions, this presented a serious problem: The error raising mechanism for a GUI requires different information than that for a console program.
BTW: The gui installer code base has support for command line arguments, so patches to add command line package selection/mirror selection etc are relatively straight forward... without cluttering up main.cc and thus prevent reuse in the command line version.
Slashdot Mirror
And you missed it being completely unusable with any 'generic' programming - i.e. c++ templates. Just what class is 'subject' again? Oh, and there is also a rather annoying aspect where you are using class names like VehicleComposite (or vehicle_composite for you CamelCase allergic folk). Hungarian notation is IMO only useful for code too simple to need it.
Funnily enough, bitkeeper was inspired by the extant patch flows, not the other way around. And with projects like Arch, Monotone, Darcs... the natural layered review process is showing up again - once the tools support it.
So, you haven't seen http://wiki.gnuarch.org/moin.cgi/Native_20WIN32_20 Support
;)
where you can download native, non-cygwin binaries have you
How is this a troll? Arch is about to do it's third stable release, with features that the svn guys are only starting to cotton onto and copy. Extensability is essentially the ease with with new functionality can be added. Ask any of the arch hackers how easy it is to add features. Talk about external use of arch in scripts, talk about mail queues, talk about hook points. Talk about any of the features that have been added first as extensions, then integrated into the core only after their design has been proven. The use of WebDAV and Apache really has nothing to do with extensability - and SVN may be very extensible... I'm not saying anything about is or isn't. Just that the webDAV stuff is unrelated.
Ok, So I'm confused. http://subversion.tigris.org/project_issues.html says that 'Severity is represented in the Priority field. Here is how priority numbers map to severity:
e sort=1&component=subversion&issue_status=UNCONFIRM ED&issue_status=NEW&issue_status=STARTED&issue_sta tus=REOPENED&order=issues.priority shows 5 defects with severity P1.
* P1: Prevents work from getting done, causes data loss, or BFI ("Bad First Impression" -- too embarrassing for a 1.0 release). '
Yet, http://subversion.tigris.org/issues/buglist.cgi?r
Thats kinda weird.
I haven't used volera, but AIUI it's derived from bordermanager, which in turn harks from the Harvest project - the same place squid came from. Bordermanager has been sweet every time I've used it, but not substantively different from Squid. ISA however, doesn't share that same heritage. It's also a bundle of products, of which you'll probably only want one bit... the proxy.
-Rob
Please don't spread uneeded FUD...The NT port of squid is well maintained, Guido does a great job, and we're hoping before too much longer (3.1/3.2) to have it fully integrated. Oh, and squid/NT is more flexible than ISA any day of the week. Performance wise, 10-30 concurrent users of any web application I've seen translates to way less than 30 requests per second (rule of thumb from experience), which is well within squid/NT's performance envelope.
-Rob
re archive-setup, let me add that init-tree can take a previously seven-step process:- branchr t
create-archive
create-category
create
create-version
init-tree
make-log
impo
down to three:
create-archive
init-tree
import -S -s "initial import of project foo"
Certainly. It should be straight forward to convert reload into ims into an access-control driven directive (say reload_into_ims_access allow|deny acl ..).
Still, I've not seen a windows update client set no-cache on their requests to date....
What comes to mind though, is that windows update clients (both the web interface, and automatic updates) use the MS http support libraries, that are configured via the internet options control panel. And in there, the 'check every time' option results in no-cache being put on every request..
Well, the sites I run happily cache all the udpates available via windows update. The only thing that doesn't cache is the https:// transfers (which I understand to be the catalog of available fixes).
You might want to analyze exactly what is occuring in your site(s).
Cheers,
Rob
(Squid core developer)
There are more free SCM tools than CVS and subversion. Unfortunately most of them DON'T SCALE.
:})
Subversion and CVS both suffer from a single-repository design. A closer fit to (my understanding of) bitkeeper is 'arch'.
(Disclaimer: I use arch and hack on a clone thereof called barch
> Ever watch American Idol? Remember the hundreds or
> thousands of really really bad singers that never
> make first cut?
>
> That's the real world, baby. Without "assholes"
> like Simon that crap would pollute our airwaves,
> and lead to a general disregard for "art".
Unlike the general disregard today?
You underestimate the 'general public'. Most folk I've met are quite capable of disambiguating unfiltered 'content' and filtered content.
What really disillusions folk is when the filtered content is crap - like most mainstream CD's for instance.
I expect that given the choice of filtering their own content, or only choosing from *badly* pre-filtered content, folk will choose to filter their own, in order to actually find something good.
Thus unfiltered content will not lead to a general disregard for art - we already have that.
I can't speak for VMS - not with any accuracy anyway :}.
:].
On WIN32, creating a process involves:
* Allocating a new thread and process kernel structs (~ Same overhead as COW fork())
* Map the process to be loaded into memory (COW fork() doesn't do this, but exec() does)
* Recursively resolve all unresolved symbols. - which includes looking through the oftimes long PATH variable, as win32 doesn't have a separate LD_PATH. (COW fork() doesn't do this, but exec() does)
* Attach all the loaded dll's (COW fork doesn't do this. exec() has something similar, IIRC).
* Finally, the WinMain function gets to run (fork() doesn't start at main again, but exec() does).
So, the fork + exec model is roughly the same overhead as CreateProcess. The fork(), serve and exit() model is much lower on unix-like os's that support COW fork() because theres less to do. And any OS that has no kernel fork() call is way behind to start with.
Hope that helps. I've probably missed something critical and will now die a flaming death. Oh well
> It's not a resolution - it's a removal procedure
> for the flawed patch. There's no replacement in
> functionality for the original.
How ironic.
D'oh!
Has *anyone* actually read the SUN announcement.
a Q4-en-Security-2.0.1-SHP_REM.pkg or later
I quote:
===
5. Resolution
This issue is addressed in the following releases:
Intel
* http://ftp.cobalt.sun.com/pub/packages/raq4/eng/R
===
> > - Much quicker to create a thread than a process.
> "Much" is the nit I am picking here. The main
> difference between a process and a thread is that
> threads share the VM. Modern operating systems do
> Copy-On-Write (COW) for process creation.
Modem UNIX-LIKE operating systems, yes. But the all-processes-descend-from-init model is not the only one in existance. In fact, Win32 doesn't have a native fork() call at all. And it does have at least one native pthreads library (http://sources.redhat.com/pthreads-win32/).
So, under Win32, thread creation is *much* faster than process creation, for a number of reasons (and COW is only part of that).
--Rob
(Cygwin pthreads maintainer)
I'm not sure where focus on IP address issues has come from... but RFC 2616 and RFC 2617 explicitly discuss secure access to WWW entities, and IP address's are not the key.
IP address restrictions are of only limited use, due to HTTP's stateless behaviour. As I've noted in another post, chains of proxies will quickly eliminate any IP based restrictions.
Some steps that JSTOR could take include adding cache-control headers (must-revalidate comes to mind) to prevent cache hits occuring without the JSTOR servers knowledge, and thus allow them to perform partial validation on the actual client (i.e. by checking the Via header). Note that checking the Via header is less-than-secure, but better than simply trusting the customers proxy to be secure.
Secondly, use authentication - assign a username and password to the content, using (say) Digest authentication, which is proxy friendly. Mark the content as explicitly cachable with revalidation, and you will get 1 If-Modified-Since request per download from proxies, and be able to check the user details each time. There would be an administrative issue with this, but I'll leave creative approachs to that as an exercise.
> From the page: We're sorry. You do not have
> access to JSTOR from your current location.
>
> It seems they have some whitelist of allowed IPs.
> Why not just traverse this once every so often and
> look for open proxies?
Because this isn't sufficient. There may be two or more hops in an open proxy chain. The authorised IP may be locked down tight, and only allow internal IP's to access it - so it would pass the routine check. But *any* of those internal IP's could also run a proxy server. And that proxy may not be locked down.
I get ~half my income from overseas contracts. (Contracting on Squid development, living in Australia).
I always use a written contract - on the simple basis that if the work isn't long enough to need a clear statement of who,what,where,when and for how much, it ain't worth doing for money.
Once the contract is signed, you still have to communicate often, and clearly. All contracts do is set the goal posts - it's up to you to keep your customer happy while you approach them.
Methinks you mean StarPortal. Star^H^H^H^HOpenOffice was not written in Java. Google on StarPortal.
Sigh, try this instead:
i ce nsing.com/royalty/swdec.html" has the old page with the free (beer) software exclusion.
"http://web.archive.org/web/20000818062745/mp3l
has the old page with the free (beer) software exclusion.
By Cygnus, I presume you mean Cygwin? Cygwin and VMWare are very different beasts. A cygwin linked program is 100% a native win32 executable. No Linux, No BSD. If the server team object to open source tools per se, then you are going to be unhappy no matter what.
> It starts off easy.. Go to www.cygwin.com, click
> on the download icon, run the setup.exe tool..
>
> And then it all goes to hell. It's truly
> inconceivable that cygwin makes you click on
> this miniscule icon (for those people at high
> resolutions) for each and every sub-package that
> you select. It's painful to describe and painful
> to perform.
And I'd love to offer resizeable windows. It's a high priority feature, when RL allows time to do it. My first focus is getting the console version operable, but the GUI contributers are aware of my desire for this. Someone will do it eventually...
> And then there's the actual download- I've found
> through painful experience that many of the
> mirror sites don't contain the all of the cygwin
> components you selected, or don't contain an up
> to date cygwin distribution, or simply die in
> the middle of your transfer. In some cases if
> you start downloading packages from one mirror
> and finish off with packages from another
> mirror, dependencies don't work out right
> because the packages on each mirror are
> different versions! In any of these cases you
> may spend up to an hour downloading and end up
> with JUNK.
Use the multiple-mirror feature. Just like apt-get , setup will intelligently select the most recent packages from multiple mirrors, and fail over in the event of errors (including MD5 validation failures).
> All this could be changed if there was a simple
> "default install, everything install, minimal
> install, custom install" choice like there is in
> ALMOST EVERY OTHER INSTALLER.
I suggested this, but was overrulled some time ago. Whilst I am the software maintainer, the mandate is to deliver an installer that the cygwin package maintainers as a group approve of. (See the cygwin-apps list archives if you want to read up on the discussion about this).
> You should also be able to download a single
> package containing the cygwin subpackages for
> your desired install. Ie, cygwin-standard.zip
> like the netscape days of yore (and winamp).
Tough. Not going to happen. Various reasons dictate this, including the horrendous amount of wastage this would cause. (Last count I did cygwin had 184 packages, which gives a horribly big number when you consider all the possible combinations).
> Yes I know, "fix the code yourself!" say the
> ignorant slashpeople. I do fix code myself, but
> this UI is so intentionally bad the author
> should have to fix it himself to learn a lesson.
Actually, I inherited the code from the previous maintainer. I'm doing this as a volunteer. I reject your assertion that the GUI is intentionally bad, and suggest you research a little more before stating 'facts' that are really just opinion.
Rob (Cygwin setup maintainer)
> Ah, well that would do it then, eh? I suppose it
> would be pretty trivial to write a non-gui
> installer, though. Pity nobody has, but it should be
> relatively simple to do. Point taken, though.
It might be relatively simple to do from scratch, but unless we want a maintenance nightmare, the retrieval logic, tar logic, package database management logic, should all be shared between all variants of the installer. And given that until very recently we could not use exceptions, this presented a serious problem: The error raising mechanism for a GUI requires different information than that for a console program.
BTW: The gui installer code base has support for command line arguments, so patches to add command line package selection/mirror selection etc are relatively straight forward... without cluttering up main.cc and thus prevent reuse in the command line version.
Rob (Cygwin setup maintainer)