There are several reasons why, even in smaller groups, using git is advantageous (even if you have only yourself, no other contributors). I'm not going to name them all, but in my experience (I've used RCS, CVS, SVN and now git), some of the more compelling advantages are that you can:
- Actually permanently erase/fix bad commits from the repository without a painful full dump/tricky edit/restore cycle on the repository. I suppose everyone has some of those occasional moments sometime: "Aaargh, I meant to commit only this one file, not this tar.gz file that happened to be in the wrong place at the right time." Git allows you to correct the mistake without bloat in the repository. - Patch management (instead of keeping around a bunch of patch files, simply create branches for every patch file you'd normally keep) made easy and trackable. - And related to patch management: commit early, commit often, then cleanup/merge commits before actually committing them "for real" to the bleeding edge version.
For small groups it means that you simply setup a central git repository everyone pushes to. You get all the benefits of DVCS and classic central management, i.e. it allows you to have your cake and eat it too.
For tomography reconstructions one typically needs SVD (Singular Value Decomposition) which are of n^2 sizes. E.g. consider a reconstructable image of 128 x 128 = 16384 pixels total, this needs (temporary) processing matrices of size 16384 x 16384, which, as you can see, grows rather fast with even moderate reconstruction grids.
Another reason is that the buyer wants to get the customer base, so they can then slow down and phase out the earlier product and offer an 'upgrade' to their main product. Quite. Two notable examples are Lucent (buying and killing Livingston, then buying Ascend; resistance is futile), and Cisco (which does this all the time; most recent examples: wireless and VOIP).
If the firewall allows you to either turn ICMP off completely or pass everything ICMP, then the better option IMO is to pass-along ICMP and then decide on the individual devices which requests you deem worthy a reply.
If the firewall allows you to discriminate amongst different types of ICMP, well, great, block the ones you consider a risk. But not all firewalls give you those options.
I admit I haven't tried using the external editor facility of the other mailsystems you mentioned, but my usual (personal) gripe about most of them is that it is usually quite impossible to get the complete message (including all the header fields) inside the editor in a single window. It allows for editing header and body without ever leaving the editor, which, is a requirement to be able to process and edit so quickly. Any reaching for the mouse or tab-key between replying to different mails kills the eight-second per mail regime.
Mutt does allow you to do exactly that and saves you a bundle of time in the process (even adding a custom one-time-headerfield is painless this way).
Try mutt. It still beats the pants off of everything in the known world when it comes to properly formatting and replying to emails (since it allows you to use your favourite editor). It's the only way to properly trim quotes, still reply with 2 words and sending the mail, in under 8 seconds.
The problem is that the error message is set by icmp, and many, many routers & firewalls block all sorts of icmp messages. You don't know if the recipient didn't receive your packet, or if the icmp error message was blocked. Well, routers rarely block icmp, but a lot of misconfigured firewalls do, yes.
Routers rarely drop those packets silently. The largest problem stems from PCs running firewall software and the self-appointed "firewalladministrator" subsequently feeling all snug and safe when he confidently *blackholes* incoming ICMP traffic under the assumption that it is a Good Thing (tm) when you are in "stealthmode" where others can't even ping you.
What they're forgetting (well, actually, they never knew) is that blocking incoming ICMP traffic also blocks MTU notifications from those routers that don't fragment (according to your own instructions in the TCP stream). Consequently you'll never know when you're sending with too large an MTU.
In the old days MTUs could be anywhere between 576 and 1500 (due to SLIP and PPP connections in the path). The current proliferation of VPNs makes this issue relevant once again.
Given that DNA tests become more mainstream, it would be rather interesting to see how large a percentage of the population actually is a chimera. If it turns out to be "popular", DNA tests could lose a lot of their credibility (in which case DNA-tests-at-the-counter become a hazard instead of a benefit).
Checking my svk tree (converted from cvs), I notice that in 1994 the "man procmailex" manpage included with the procmail distro already contains a dynamic E-mail-me-the-file-I-ask-for example.
Which isn't what this patent is about. This patent is about running a message through a text classification algorithm to determine what kind of message it's likely to be, pulling a canned response from a database if it matches a known category and sending that response, otherwise flagging it for human attention. Did the example do all of these things? If not, it isn't useful prior art. Checking the same svk tree, I see that SmartList was included in the procmail distro prior to 1994, and SmartList *did* (and does) do all of those things. It contains a fairly elaborate weighted parsing system which tries to respond with canned replies in response to natural language requests, albeit in the domain of mailinglist and file transfer operations.
Checking my svk tree (converted from cvs), I notice that in 1994 the "man procmailex" manpage included with the procmail distro already contains a dynamic E-mail-me-the-file-I-ask-for example.
All people talk about is Asterisk. Meanwhile there's the
OpenSource solution (even GPL) called Yate;
which handles a magnitude larger number of calls than Asterisk on the same hardware, it has the (currently still unique) perfect NAT-proof algorithm for
SIP, it has excellent support for H.323, and, last but not least, the company supporting it insists to do paid work only when it results in (new) GPLed code.
Yate handles business-logic integration just fine with predefined hooks (I used a PostgreSQL backend to integrate it with).
Because blinking ads are a nuisance and a clear sign of bad taste.
On the topic of knowing, just to let you know: I know more (about grammar) than you do, please check your signature and find the two occurrences of "then" that should have been replaced with "than".
Re:problem with large storage mp3 players
on
80 Gig MP3 Player
·
· Score: 1
Having these calls available to non-root opens up a can of worms. The system provided looks clean, except he should limit its execution with yet another capability.
Slashdot Mirror
There are several reasons why, even in smaller groups, using git is advantageous (even if you have only yourself, no other contributors). I'm not going to name them all, but in my experience (I've used RCS, CVS, SVN and now git), some of the more compelling advantages are that you can:
- Actually permanently erase/fix bad commits from the repository without a painful full dump/tricky edit/restore cycle on the repository. I suppose everyone has some of those occasional moments sometime: "Aaargh, I meant to commit only this one file, not this tar.gz file that happened to be in the wrong place at the right time." Git allows you to correct the mistake without bloat in the repository.
- Patch management (instead of keeping around a bunch of patch files, simply create branches for every patch file you'd normally keep) made easy and trackable.
- And related to patch management: commit early, commit often, then cleanup/merge commits before actually committing them "for real" to the bleeding edge version.
For small groups it means that you simply setup a central git repository everyone pushes to. You get all the benefits of DVCS and classic central management, i.e. it allows you to have your cake and eat it too.
Frequently, the best documentation for an application is the string command.
It's Open Source. UTSL, no need to resort to strings.
For tomography reconstructions one typically needs SVD (Singular Value Decomposition) which are of n^2 sizes. E.g. consider a reconstructable image of 128 x 128 = 16384 pixels total, this needs (temporary) processing matrices of size 16384 x 16384, which, as you can see, grows rather fast with even moderate reconstruction grids.
By Monty Python: The Funniest Joke in the World
Facebook uses PostgreSQL as a backend, not MySQL, and PostgreSQL doesn't have a 48-bit datatype, so in their case it's either 32-bit or 64-bit.
If the firewall allows you to either turn ICMP off completely or pass everything ICMP, then the better option IMO is to pass-along ICMP and then decide on the individual devices which requests you deem worthy a reply.
If the firewall allows you to discriminate amongst different types of ICMP, well, great, block the ones you consider a risk. But not all firewalls give you those options.
I admit I haven't tried using the external editor facility of the other mailsystems you mentioned, but my usual (personal) gripe about most of them is that it is usually quite impossible to get the complete message (including all the header fields) inside the editor in a single window. It allows for editing header and body without ever leaving the editor, which, is a requirement to be able to process and edit so quickly. Any reaching for the mouse or tab-key between replying to different mails kills the eight-second per mail regime.
Mutt does allow you to do exactly that and saves you a bundle of time in the process (even adding a custom one-time-headerfield is painless this way).
Try mutt. It still beats the pants off of everything in the known world when it comes to properly formatting and replying to emails (since it allows you to use your favourite editor). It's the only way to properly trim quotes, still reply with 2 words and sending the mail, in under 8 seconds.
Routers rarely drop those packets silently. The largest problem stems from PCs running firewall software and the self-appointed "firewalladministrator" subsequently feeling all snug and safe when he confidently *blackholes* incoming ICMP traffic under the assumption that it is a Good Thing (tm) when you are in "stealthmode" where others can't even ping you.
What they're forgetting (well, actually, they never knew) is that blocking incoming ICMP traffic also blocks MTU notifications from those routers that don't fragment (according to your own instructions in the TCP stream). Consequently you'll never know when you're sending with too large an MTU.
In the old days MTUs could be anywhere between 576 and 1500 (due to SLIP and PPP connections in the path). The current proliferation of VPNs makes this issue relevant once again.
Given that DNA tests become more mainstream, it would be rather interesting to see how large a percentage of the population actually is a chimera. If it turns out to be "popular", DNA tests could lose a lot of their credibility (in which case DNA-tests-at-the-counter become a hazard instead of a benefit).
Which isn't what this patent is about. This patent is about running a message through a text classification algorithm to determine what kind of message it's likely to be, pulling a canned response from a database if it matches a known category and sending that response, otherwise flagging it for human attention. Did the example do all of these things? If not, it isn't useful prior art. Checking the same svk tree, I see that SmartList was included in the procmail distro prior to 1994, and SmartList *did* (and does) do all of those things. It contains a fairly elaborate weighted parsing system which tries to respond with canned replies in response to natural language requests, albeit in the domain of mailinglist and file transfer operations.
Checking my svk tree (converted from cvs), I notice that in 1994 the "man procmailex" manpage included with the procmail distro already contains a dynamic E-mail-me-the-file-I-ask-for example.
Check out Yate, it's open source, and scalable, and is in use in many callcenters in Europe without problems.
All people talk about is Asterisk. Meanwhile there's the OpenSource solution (even GPL) called Yate; which handles a magnitude larger number of calls than Asterisk on the same hardware, it has the (currently still unique) perfect NAT-proof algorithm for SIP, it has excellent support for H.323, and, last but not least, the company supporting it insists to do paid work only when it results in (new) GPLed code.
Yate handles business-logic integration just fine with predefined hooks (I used a PostgreSQL backend to integrate it with).
Because blinking ads are a nuisance and a clear sign of bad taste.
On the topic of knowing, just to let you know: I know more (about grammar) than you do, please check your signature and find the two occurrences of "then" that should have been replaced with "than".
The Empeg has solved this rather efficiently.
Having these calls available to non-root opens up a can of worms. The system provided looks clean, except he should limit its execution with yet another capability.
And yet, both are still an easy match for the Empeg with it's unparalleled hackability and features.
The standard defines how much a kilogram is, so by definition, that makes a gram 1/1000th of that.