my team is in charge of the technological foundations for all the Internet related apps pushed by our employer. Linux / Apache / Tomcat is used EVERYWHERE for all our online banking and trading systems.
In my shop where we've been running Linux servers for several years without any need for support we are going to migrate our boxes to a RHEL derivative based on the terms of the RHEL EULA which allow recompilation of the sources to create a Linux distro as long as it does not use the name or image of Red Hat.
As they are all based on RHEL 3 we will factor lots of stuff, the admin will be very similar, so will the automated install using kickstart.
And to boot we will not have to worry about some critical components like a JVM being only available on RHEL for example, if it runs on RHEL it has a 0.9999999 probability of doing so too on one of the clones.
And for some apps like Oracle we will go with RHEL since they impose it to us. But in the end we will not get commercial supports for the 70 or so servers we've been running on 6.1, 6.2 and 7.3 without support for all those years.
Well there is a startup that has emerged from the ENST Bretagne and that focuses on Turbo Codes, it is called Turboconcept and you might find one of its creator more good looking.
abcde as offered by Fink has a cddafs frontend which will copy the AIFF tracks from the mounted audio CD and use that as input to the ripper process. The version of oggenc offered by Fink can use AIFF/AIFC tracks as input and produce Ogg Vorbis files.
try fink.
Looks like a job for the great SkipDoctor!
At least if the special chemical is just on a layer and not dissolved in the platic.
Re:Anyone interested in extending this concept?
on
Geocoding All Content
·
· Score: 1
Concerning GeoCoord I have about 4 million records in the NIMA/GeoNet category and performance of searches is not different from the one I had with 10000 records.
For scalability I use a peano code over the whole space, thus allowing a one dimensional search and therefore b-trees indices are very good. MySQL just scales very well (or has so far.).
And my machine is only a 750 Mhz Athlon with 640 Mb of ram, and it's running GeoCoord as a side order, this is my main machine for email/dev/etc.
Re:Anyone interested in extending this concept?
on
Geocoding All Content
·
· Score: 1
I am having the same type of thought for GeoCoord.
But no clear way came through yet...
Well Moneo is really a wide scale operation of the banks to get paid for what they can't now, namely the cash you carry.
Moneo works this way, with your credit card (visa/MC), your bank will offer you to subscribe to Moneo for a yearly fee (around 10 EUR/USD), if you do so you can load up virtual cash onto your credit card (smart cards in France), up to 100 EUR.
In order for a shop to accept Moneo payments, they need a terminal rented by their bank for a monthly fee. The terminal will accept either credit cards or Moneo or both. You give your card, the terminal asks for your choice of Moneo or Credit and you can proceed with the transaction. Please note that the bank receives a fee for each payment done on the terminal, this fee being paid by the seller. If your balance is considered low by the terminal you will be offered a reloading of cash onto your card, this is something that interest the seller as this time he will receive a fee paid by the bank if your reload cash at his terminal.
If we sum up the whole system:
* customer pays a yearly fee for Moneo. * shop owner rents a terminal to its bank for a monthly fee. * on each payment a small fee is paid by the shop owner to the bank * on each refill the bank pays a small fee to the shop owner * if you loose your credit card with moneo, the credit card might be barred but the Moneo cash can still be used (you might loose up to 100 EUR)
So the real question is, why not simply make shop owners accept credit card payments for real small fees instead of setting up such a system ? The answer is simple, because the Moneo system is all profit for the banks, not for the consumer or shop owner, the BANKS!
And in order to deploy rapidly the Moneo system, the german technology was choosen (Geldkarte, 56 bit DES crypto!!!!), which means no PKI and rather weak crypto.... But the banks don't care, it's not their money, and very often all card loss insurances will not cover the money loaded onto Moneo....
With all thos elements my choice is clear, Moneo, NO!
Slashdot Mirror
This is exactly the problem OSS (http://github.com/hbs/oss) is trying to solve!
Was he A9's chair man?
Here it is. http://www.iroise.net/WebShare.tar.gz
I just translated it from French to English.
This is provided as is with no support, source should be enough.
It is based on Apache 2 (2.0.53), mod_perl. It uses several perl modules (check source) and memcached.
Hi,
I've written a Web based file management solution. It is based on Apache 2 with mod_dav and a bunch of Perl modules to do the auth/authz.
It uses our Active Directory to authenticate users and manages a set of groups and shares (it is called WebShare).
Anybody can create a group, add users to it, create a share and assign R or W or R/W permissions to an existing group.
This is some sort of self-service WebDav repository.
I'd be glad to share it with anybody wanting it.
Seems to me that A and B have to end at MD5 block boundaries otherwise md5(A+Z) != md5(B+Z).
Indeed, that's why ETOPS is said to mean
Engines Turn Or Passengers Swim...
It may be compulsory to carry it but it does not have to be readable.
I guess I'll microwave mine as soon as I get it, good luck for the identity theft then!
AS I already own Macs I would not switch, but I would try to make my company switch...
Well we do not accept money from anonymous cowards ;-)
Hi,
my team is in charge of the technological foundations for all the Internet related apps pushed by our employer. Linux / Apache / Tomcat is used EVERYWHERE for all our online banking and trading systems.
Access to the legacy system is also done in Java.
I also clearly think we're not alone doing so.
I know at least four projects of this kind, namely CentOS, White Box Linux, Tao Linux and Fermi Linux LTS from Fermilab.
As they are all based on RHEL 3 we will factor lots of stuff, the admin will be very similar, so will the automated install using kickstart.
And to boot we will not have to worry about some critical components like a JVM being only available on RHEL for example, if it runs on RHEL it has a 0.9999999 probability of doing so too on one of the clones.
And for some apps like Oracle we will go with RHEL since they impose it to us. But in the end we will not get commercial supports for the 70 or so servers we've been running on 6.1, 6.2 and 7.3 without support for all those years.
Anybody else going for this strategy?Well there is a startup that has emerged from the ENST Bretagne and that focuses on Turbo Codes, it is called Turboconcept and you might find one of its creator more good looking.
abcde as offered by Fink has a cddafs frontend which will copy the AIFF tracks from the mounted audio CD and use that as input to the ripper process. The version of oggenc offered by Fink can use AIFF/AIFC tracks as input and produce Ogg Vorbis files. try fink.
How about you mount a WebDAV Volume using the Finder and make iCal store the Calendar locally?
Using symlinks can also help.
And it can be fully integrated into SAMBA using cupssmbadd, even handles automatic driver download.
Mathias.
Looks like a job for the great SkipDoctor! At least if the special chemical is just on a layer and not dissolved in the platic.
Concerning GeoCoord I have about 4 million records in the NIMA/GeoNet category and performance of searches is not different from the one I had with 10000 records.
For scalability I use a peano code over the whole space, thus allowing a one dimensional search and therefore b-trees indices are very good. MySQL just scales very well (or has so far.).
And my machine is only a 750 Mhz Athlon with 640 Mb of ram, and it's running GeoCoord as a side order, this is my main machine for email/dev/etc.
I am having the same type of thought for GeoCoord. But no clear way came through yet...
Well Moneo is really a wide scale operation of the banks to get paid for what they can't now, namely the cash you carry.
Moneo works this way, with your credit card (visa/MC), your bank will offer you to subscribe to Moneo for a yearly fee (around 10 EUR/USD), if you do so you can load up virtual cash onto your credit card (smart cards in France), up to 100 EUR.
In order for a shop to accept Moneo payments, they need a terminal rented by their bank for a monthly fee. The terminal will accept either credit cards or Moneo or both. You give your card, the terminal asks for your choice of Moneo or Credit and you can proceed with the transaction. Please note that the bank receives a fee for each payment done on the terminal, this fee being paid by the seller. If your balance is considered low by the terminal you will be offered a reloading of cash onto your card, this is something that interest the seller as this time he will receive a fee paid by the bank if your reload cash at his terminal.
If we sum up the whole system:
* customer pays a yearly fee for Moneo.
* shop owner rents a terminal to its bank for a monthly fee.
* on each payment a small fee is paid by the shop owner to the bank
* on each refill the bank pays a small fee to the shop owner
* if you loose your credit card with moneo, the credit card might be barred but the Moneo cash can still be used (you might loose up to 100 EUR)
So the real question is, why not simply make shop owners accept credit card payments for real small fees instead of setting up such a system ? The answer is simple, because the Moneo system is all profit for the banks, not for the consumer or shop owner, the BANKS!
And in order to deploy rapidly the Moneo system, the german technology was choosen (Geldkarte, 56 bit DES crypto!!!!), which means no PKI and rather weak crypto.... But the banks don't care, it's not their money, and very often all card loss insurances will not cover the money loaded onto Moneo....
With all thos elements my choice is clear, Moneo, NO!