I have an idea. It's either incredibly naive and stupid or brilliant. You have the RIAA logging onto P2P networks and scanning the network for people redistributing copy right material. Then they subpoena ISPs for the name's of those people using the IP address at the date and time they detected them redistributing their copy right material. Next they sue ma and pop for ridiculous amounts of money. Instead of going to court they effectively force them to settle out of court for a few thousand dollars. Why not just turn the tables on them with the same exact tactics? First get as many people to participate in this as possible. A 1,000 people would be a good goal. Next have everyone make a recording of something remotely sounding like music. And now comes the hard part; identify an RIAA IP address in advance. Subpoena their ISP for their identity. Next take them to court and sue for $1 million seeking damages for redistributing your copy right work. The only *evidence* is your word. With 1,000 individuals doing this, they would be mounting a collective $1 billion dollar lawsuit. Ironically, some of the cases would make it to court and in all or nearly all cases the plaintiff would fail. However, it would create a precedence that more evidence is needed than simple "computer evidence" being supplied by the plaintiff in P2P redistribution lawsuits. This would all be used to achieve a cookie cutter way of short circuiting their law suits against ma and pop. Stupid or not?
Thanks for the info. I am a little amazed that the + operator is being deprecated. At the same time I am surprised that Oracle 8 and previous versions did not allow ANSI SQL join operations. The only time that I use the ANSI join is when doing a full outer join, which is rarely needed.
I've used both syntaxes and I prefer the + operator. It takes less characters and is usually more clear. It still works in 10g, so I doubt that it is going away any time soon.
After searching google I haven't found any SQL, Oracle functions, or syntax extenstions being deprecated. I don't doubt that it is possible, but I am curious as to specifically what you are refering to and to which version(s) of Oracle it applies to.
Lastly even if something is being depreicated, I'm sure it will be around till the end of time. I'm not using anything too crazy.
The primary table, trans, has several million rows. Charge has about a million rows. The only table returning few rows are those inner selects from dual.
I consider myself a SQL god. Okay, that's a bit strong. Seriously though, what is so limited about SQL? Take a look at the following SQL statment that I wrote.
select aging_desc, decode(deposit_desc,'Calling Card','Authcode','Ethernet','Dialin',deposit_desc) as deposit_desc, (sum(nvl(charges_not_paid,0)) - sum(nvl(overpayments_left,0)))/100 as grand_total from ( select all1.acct, all1.mindex, all1.aging_desc, all1.inv_date, all1.deposit_desc, nvl(charges.scharge_amt,0) as charge_amt, nvl(trans_charges.spaidoff_chargeamt, 0) as paid_off_amt, nvl(credits.charge_credits,0) as credit_amt, nvl(trans_credits.scredit_processed_a mt,0) as credit_processed, nvl(credits.charge_credits,0) - nvl(trans_credits.scredit_processed_amt,0) as credit_not_processed, nvl(charges.scharge_amt,0) - nvl(trans_charges.spaidoff_chargeamt,0) - nvl(trans_credits.scredit_processed_amt,0) - (nvl(credits.charge_credits,0) - nvl(trans_credits.scredit_processed_amt,0)) as charges_not_paid, overpayments.soverpayment as overpayments_amt, overpayments.samt_consumed as overpayments_consumed, overpayments.sleft as overpayments_left from (
select acct, i2.inv_date, deposit_desc, mindex, aging_desc,
i2.inv_date || '-' || deposit_desc || '-' || acct as combiner
from inv i1, acct,
(
select distinct deposit_desc
from (
select deposit_billnum_type, deposit_desc, deposit_type
from deposit_type
union
select 'U', 'Unknown', 'U'
from dual
)
),
(
select add_months('01-SEP-04',0) as inv_date,
'Current Due' as aging_desc,
0 as mindex
from dual
union
select add_months('01-SEP-04',-1), 'Past 1-30', 1 from dual
union
select add_months('01-SEP-04',-2), 'Past 31-60', 2 from dual
union
select add_months('01-SEP-04',-3), 'Past 61-90', 3 from dual
union
select add_months('01-SEP-04',-4), 'Past 91-120', 4 from dual
union
select add_months('01-SEP-04',-5), 'Past 121+', 5 from dual
) i2
where inv_acct = acct and acct_type = 'S' and inv_flags is null
and i1.inv_date = '01-SEP-04'
order by acct, i2.inv_date, deposit_desc ) all1, (
select inv_acct, greatest(inv_date, add_months('01-SEP-04',-5)) as inv_date,
deposit_desc,
greatest(inv_date, add_months('01-SEP-04',-5)) || '-' || deposit_desc
|| '-' || inv_acct as combiner,
sum(charge_amt) as scharge_amt
from (
select i1.inv_acct, i1.inv_date, nvl(deposit_desc,'Unknown') as deposit_desc,
sum(nvl(charge_amt,0)) as charge_amt
from inv i1, charge, deposit_type, acct, inv i2
where i1.inv_flags is null and i1.inv = charge_inv
and charge_billnum_type = deposit_billnum_type(+)
and i1.inv_acct = acct and acct_type = 'S' and
acct = i2.inv_acct and i2.inv_date = '01-SEP-04' and
i2.inv_flags is null and charge_amt > 0
group by i1.inv_acct, i1.inv_date, nvl(deposit_desc,'Unknown'), i1.inv_acct
union all
select i1.inv_acct, i3.inv_date, nvl(deposit_desc,'Unknown') as deposit_desc,
-1*sum(nvl(t1.trans_amt,0)) as credit_processed_amt
from inv i1, charge c1, trans t1, deposit_type, acct, inv i2, trans t2, charge c2, inv i3
where i1.inv_flags is null and i1.inv = c1.charge_inv(+)
and t1.trans_credit = c1.charge
and t1.trans_valid is null and c2.charge_billnum_type = deposit_billnum_type(+)
and i1.inv_acct = acct and acct_type = 'S' and i2.inv_acct = acct
and i2.inv_date = '01-SEP-04' and i2.inv_flags is null
and t1.trans = t2.trans_tran_src(+) and t2.trans_valid is null
and t1.trans_charge = c2.charge and c2.charge_inv = i3.inv and
i3.inv_flags is null
group by i1.inv_acct, i3.inv_date, nvl(deposit_desc,'Unknown')
union all
select i1.inv_acct, i1.inv_date, nvl(deposit_desc,'Unknown') as deposit_desc,
sum(nvl(
I'm sure this will never be read or moderated, but here goes.
There are some better battery technologies in the pipeline. For instance Zinc Matrix Power, Inc is working on a rechargeable alkaline-zinc battery that has about twice the energy density of lithium ion battery--600 watt hours/liter versus 385 watt hours/liter. They have already done field testing and Intel corporations is showing interest in them.
Also lithium polymer batteries promise to have higher energy densities and be available by 2005.
Anyone know what the heck they are going to do with all those wireless cards? Surely they aren't going to continue to sit at the warehouse.
The article also mentions nothing about what is going to happen to the institution and companies involved. Is it just me or are news articles a little week now a days? or is it that peoples' attention span has shorten and so too must the articles?
Solar cells do use an inordinate amount of energy to make. However, they do produce more energy over their lifetime than it takes to produce them. In renewables, this is often expressed in the number of months for energy payback. Currently this is in the neighborhood of a few years. http://www.autobahn.mb.ca/~het/energy/solar.html (scroll down to Solar Payback section).
It is cool that someone is researching ways of turning biomass into methanol and doing it in an economical and energy efficient way. This is not entirely significant to the overall energy sustainability issue. If all cars were to run off of methanol produced from biomass that was 100% efficient in its conversion, the amount of biomass needed would be enormous and not obtainable. Photosynthesis is not particularly efficient. Sugar cane is about the most efficient and it has a solar efficiency of about 1%!! Solar cells are around 15% and some lab cells are reaching towards 30%. http://www.aeiveos.com/~bradbury/Papers/Photosynth eticEfficiency.html
The choice for power in general and for cars will have to come from an environmentally favorable and sustainable source. Liquid hydrocarbons are easy to deal with--we have the refueling infrastructure, combustion engines are proven, and they have high energy densities allowing cars to go 100s of miles before refueling. Unless some unforeseen breakthrough comes in batteries, future cars will be fuel cell based. In the interim hybrid gas/electric cars will become popular as oil becomes scarce or gasoline/diesel becomes expensive.
There are several types of fuel cells, but I predict that the hydrogen fuel cells will win out. The hydrogen will initially come from reformed hydrocarbons and eventually through electrolysis.
Where will all this electricity come from you ask? Electrolysis of water is not cheap! The electrical generating capacity will have to be doubled, which will make for a hard transition. Current electrical demand world wide is growing at about 1-2% per year.
Natural gas will continue to be utilized until it is no longer viable. Natural gas burns clean and produces relatively little CO2. How much longer until it is not viable is in debate, but it is less than 80 years.
Coal is currently declining in usage, but this could change as natural gas becomes scarce. Coal produces a TON of CO2 in comparison to natural gas, but through breakthroughs in CO2 sequesterization it may become feasible economically and environmentally. We have 1,000s of years worth of coal left.
Methane hydrates on the ocean floor could possibly be mined. The US and Japan are researching this. Methane is 25x more of a green house gas than CO2 and a lot of it escapes trying to capture the methane hydrates. However, there is an enormous about of energy stored in these hydrates. The amount is in dispute, but it is said to be more than all other conventual hydrocarbons combined!
The long term will probably lead towards wind and solar generation. More emphasis will probably be on wind generation. Wind generation has one of the fastest paybacks. In certain prime areas, the cost of produced electricity can easily compete with conventional fossil fuels. In part, this is why the wind industry is growing at about 25%/year. In the US, Kansas alone is prime for an install base of 121,900 MegaWatts, http://www.awea.org/projects/kansas.html !
I agree. Most of my professional work has been with Java. I think those are the same reasons that people flock to Java--the clear and consise documentation, and extensive *standard* API that comes with any Java installation. People might complain that the standard JRE installation is getting relatively HUGE, but that is a good thing. For example, the more that is *standard* the less I have to worry about looking at code that uses three different regular expression packages!
And in deploying applications, its great if you don't have to worry about class path's to additional JARs.
Rant following: Who ever came up with the extensions directory needs to be shot. On occasion we have had difficulty tracking down particularily hard bugs because multiple versions of a package were stuck in the extensions directory. And there was a need for both versions, but someone failed to realize that there was already one in the extensions directory. We have found out the hard way that you cannot expect different OS JVM's to load in extension JARs in the same order from platform to platform. The solution is simple, simply move both jars out of the extensions directory and add the needed jar to the classpath of the application/utility.
To further deal with startup mess (executable JARs do not go far enough) for multiple OSs I have written an ingenous startup script. If you want a copy of it, just email me.:)
Today is not a good day.. I accidently hit enter on the last comment.:(
Generally the higher the frequencies the more dangerous RF exposure is to human flesh. Microwave frequencies are a lot more dangerous than HF (link helpful in finding more information reguarding this issue.
I made a mistake in units. The 33cm (902-928Mhz) band has 26 MHz and not 26 kHz of bandwidth. It would be capable of supporting a WiFi like digital spread spectrum channel needing 22 MHz of bandwidth. Sorry for any confusion.
With a little time and effort almost any American can get an amateur radio technician class license from the FCC. It does not allow you to transmit 1500 watts at 2.4Ghz! The 2.4Ghz band is unlicensed and the max transmittion power is 100 milliwatts. The closest microwave frequencies are 902-928 MHz and 1.24-1.3Ghz. You should note that there is only 26 kHz and 60 MHz of bandwidth available respectively. Thus the 23cm (1.24-1.3Ghz) band is the only choice for applications similiar to WiFi. 802.11b eats up 22 MHz of bandwidth.
With what little knowledge that I have concerning radio theory, it should be possible to modify an access point or WiFi card and get it on the 23cm band. It might even be easier considering that 1.24 Ghz is almost a harmonic (half) of 2.4Ghz.
If you do manage to do such a thing, there would be a few requirements concerning identification. The access point would need to broadcast your callsign; this might be fullfilled with your callsign as the SID. The data traffic could not be encrypted, the data could not be offensive, and you must have control over the equipment.
Slashdot Mirror
I have an idea. It's either incredibly naive and stupid or brilliant. You have the RIAA logging onto P2P networks and scanning the network for people redistributing copy right material. Then they subpoena ISPs for the name's of those people using the IP address at the date and time they detected them redistributing their copy right material. Next they sue ma and pop for ridiculous amounts of money. Instead of going to court they effectively force them to settle out of court for a few thousand dollars. Why not just turn the tables on them with the same exact tactics? First get as many people to participate in this as possible. A 1,000 people would be a good goal. Next have everyone make a recording of something remotely sounding like music. And now comes the hard part; identify an RIAA IP address in advance. Subpoena their ISP for their identity. Next take them to court and sue for $1 million seeking damages for redistributing your copy right work. The only *evidence* is your word. With 1,000 individuals doing this, they would be mounting a collective $1 billion dollar lawsuit. Ironically, some of the cases would make it to court and in all or nearly all cases the plaintiff would fail. However, it would create a precedence that more evidence is needed than simple "computer evidence" being supplied by the plaintiff in P2P redistribution lawsuits. This would all be used to achieve a cookie cutter way of short circuiting their law suits against ma and pop. Stupid or not?
Thanks for the info. I am a little amazed that the + operator is being deprecated. At the same time I am surprised that Oracle 8 and previous versions did not allow ANSI SQL join operations. The only time that I use the ANSI join is when doing a full outer join, which is rarely needed.
I've used both syntaxes and I prefer the + operator. It takes less characters and is usually more clear. It still works in 10g, so I doubt that it is going away any time soon.
Out of curiosity, what is deprecated?
After searching google I haven't found any SQL, Oracle functions, or syntax extenstions being deprecated. I don't doubt that it is possible, but I am curious as to specifically what you are refering to and to which version(s) of Oracle it applies to.
Lastly even if something is being depreicated, I'm sure it will be around till the end of time. I'm not using anything too crazy.
The primary table, trans, has several million rows. Charge has about a million rows. The only table returning few rows are those inner selects from dual.
I consider myself a SQL god. Okay, that's a bit strong. Seriously though, what is so limited about SQL? Take a look at the following SQL statment that I wrote.
select aging_desc,
decode(deposit_desc,'Calling Card','Authcode','Ethernet','Dialin',deposit_desc) as deposit_desc,
(sum(nvl(charges_not_paid,0)) - sum(nvl(overpayments_left,0)))/100 as grand_total
from
(
select all1.acct, all1.mindex, all1.aging_desc, all1.inv_date, all1.deposit_desc,
nvl(charges.scharge_amt,0) as charge_amt,
nvl(trans_charges.spaidoff_chargeamt, 0) as paid_off_amt,
nvl(credits.charge_credits,0) as credit_amt,
nvl(trans_credits.scredit_processed_a mt,0) as credit_processed,
nvl(credits.charge_credits,0) - nvl(trans_credits.scredit_processed_amt,0) as credit_not_processed,
nvl(charges.scharge_amt,0) - nvl(trans_charges.spaidoff_chargeamt,0) -
nvl(trans_credits.scredit_processed_amt,0) -
(nvl(credits.charge_credits,0) - nvl(trans_credits.scredit_processed_amt,0)) as charges_not_paid,
overpayments.soverpayment as overpayments_amt,
overpayments.samt_consumed as overpayments_consumed,
overpayments.sleft as overpayments_left
from (
select acct, i2.inv_date, deposit_desc, mindex, aging_desc,
i2.inv_date || '-' || deposit_desc || '-' || acct as combiner
from inv i1, acct,
(
select distinct deposit_desc
from (
select deposit_billnum_type, deposit_desc, deposit_type
from deposit_type
union
select 'U', 'Unknown', 'U'
from dual
)
),
(
select add_months('01-SEP-04',0) as inv_date,
'Current Due' as aging_desc,
0 as mindex
from dual
union
select add_months('01-SEP-04',-1), 'Past 1-30', 1 from dual
union
select add_months('01-SEP-04',-2), 'Past 31-60', 2 from dual
union
select add_months('01-SEP-04',-3), 'Past 61-90', 3 from dual
union
select add_months('01-SEP-04',-4), 'Past 91-120', 4 from dual
union
select add_months('01-SEP-04',-5), 'Past 121+', 5 from dual
) i2
where inv_acct = acct and acct_type = 'S' and inv_flags is null
and i1.inv_date = '01-SEP-04'
order by acct, i2.inv_date, deposit_desc
) all1,
(
select inv_acct, greatest(inv_date, add_months('01-SEP-04',-5)) as inv_date,
deposit_desc,
greatest(inv_date, add_months('01-SEP-04',-5)) || '-' || deposit_desc
|| '-' || inv_acct as combiner,
sum(charge_amt) as scharge_amt
from (
select i1.inv_acct, i1.inv_date, nvl(deposit_desc,'Unknown') as deposit_desc,
sum(nvl(charge_amt,0)) as charge_amt
from inv i1, charge, deposit_type, acct, inv i2
where i1.inv_flags is null and i1.inv = charge_inv
and charge_billnum_type = deposit_billnum_type(+)
and i1.inv_acct = acct and acct_type = 'S' and
acct = i2.inv_acct and i2.inv_date = '01-SEP-04' and
i2.inv_flags is null and charge_amt > 0
group by i1.inv_acct, i1.inv_date, nvl(deposit_desc,'Unknown'), i1.inv_acct
union all
select i1.inv_acct, i3.inv_date, nvl(deposit_desc,'Unknown') as deposit_desc,
-1*sum(nvl(t1.trans_amt,0)) as credit_processed_amt
from inv i1, charge c1, trans t1, deposit_type, acct, inv i2, trans t2, charge c2, inv i3
where i1.inv_flags is null and i1.inv = c1.charge_inv(+)
and t1.trans_credit = c1.charge
and t1.trans_valid is null and c2.charge_billnum_type = deposit_billnum_type(+)
and i1.inv_acct = acct and acct_type = 'S' and i2.inv_acct = acct
and i2.inv_date = '01-SEP-04' and i2.inv_flags is null
and t1.trans = t2.trans_tran_src(+) and t2.trans_valid is null
and t1.trans_charge = c2.charge and c2.charge_inv = i3.inv and
i3.inv_flags is null
group by i1.inv_acct, i3.inv_date, nvl(deposit_desc,'Unknown')
union all
select i1.inv_acct, i1.inv_date, nvl(deposit_desc,'Unknown') as deposit_desc,
sum(nvl(
I'm sure this will never be read or moderated, but here goes.
There are some better battery technologies in the pipeline. For instance Zinc Matrix Power, Inc is working on a rechargeable alkaline-zinc battery that has about twice the energy density of lithium ion battery--600 watt hours/liter versus 385 watt hours/liter. They have already done field testing and Intel corporations is showing interest in them.
Also lithium polymer batteries promise to have higher energy densities and be available by 2005.
Anyone know what the heck they are going to do with all those wireless cards? Surely they aren't going to continue to sit at the warehouse.
The article also mentions nothing about what is going to happen to the institution and companies involved. Is it just me or are news articles a little week now a days? or is it that peoples' attention span has shorten and so too must the articles?
Solar cells do use an inordinate amount of energy to make. However, they do produce more energy over their lifetime than it takes to produce them. In renewables, this is often expressed in the number of months for energy payback. Currently this is in the neighborhood of a few years. http://www.autobahn.mb.ca/~het/energy/solar.html (scroll down to Solar Payback section).
h eticEfficiency.html
It is cool that someone is researching ways of turning biomass into methanol and doing it in an economical and energy efficient way. This is not entirely significant to the overall energy sustainability issue. If all cars were to run off of methanol produced from biomass that was 100% efficient in its conversion, the amount of biomass needed would be enormous and not obtainable. Photosynthesis is not particularly efficient. Sugar cane is about the most efficient and it has a solar efficiency of about 1%!! Solar cells are around 15% and some lab cells are reaching towards 30%. http://www.aeiveos.com/~bradbury/Papers/Photosynt
The choice for power in general and for cars will have to come from an environmentally favorable and sustainable source. Liquid hydrocarbons are easy to deal with--we have the refueling infrastructure, combustion engines are proven, and they have high energy densities allowing cars to go 100s of miles before refueling. Unless some unforeseen breakthrough comes in batteries, future cars will be fuel cell based. In the interim hybrid gas/electric cars will become popular as oil becomes scarce or gasoline/diesel becomes expensive.
There are several types of fuel cells, but I predict that the hydrogen fuel cells will win out. The hydrogen will initially come from reformed hydrocarbons and eventually through electrolysis.
Where will all this electricity come from you ask? Electrolysis of water is not cheap! The electrical generating capacity will have to be doubled, which will make for a hard transition. Current electrical demand world wide is growing at about 1-2% per year.
Natural gas will continue to be utilized until it is no longer viable. Natural gas burns clean and produces relatively little CO2. How much longer until it is not viable is in debate, but it is less than 80 years.
Coal is currently declining in usage, but this could change as natural gas becomes scarce. Coal produces a TON of CO2 in comparison to natural gas, but through breakthroughs in CO2 sequesterization it may become feasible economically and environmentally. We have 1,000s of years worth of coal left.
Methane hydrates on the ocean floor could possibly be mined. The US and Japan are researching this. Methane is 25x more of a green house gas than CO2 and a lot of it escapes trying to capture the methane hydrates. However, there is an enormous about of energy stored in these hydrates. The amount is in dispute, but it is said to be more than all other conventual hydrocarbons combined!
The long term will probably lead towards wind and solar generation. More emphasis will probably be on wind generation. Wind generation has one of the fastest paybacks. In certain prime areas, the cost of produced electricity can easily compete with conventional fossil fuels. In part, this is why the wind industry is growing at about 25%/year. In the US, Kansas alone is prime for an install base of 121,900 MegaWatts, http://www.awea.org/projects/kansas.html !
I agree. Most of my professional work has been with Java. I think those are the same reasons that people flock to Java--the clear and consise documentation, and extensive *standard* API that comes with any Java installation. People might complain that the standard JRE installation is getting relatively HUGE, but that is a good thing. For example, the more that is *standard* the less I have to worry about looking at code that uses three different regular expression packages!
:)
And in deploying applications, its great if you don't have to worry about class path's to additional JARs.
Rant following:
Who ever came up with the extensions directory needs to be shot. On occasion we have had difficulty tracking down particularily hard bugs because multiple versions of a package were stuck in the extensions directory. And there was a need for both versions, but someone failed to realize that there was already one in the extensions directory. We have found out the hard way that you cannot expect different OS JVM's to load in extension JARs in the same order from platform to platform. The solution is simple, simply move both jars out of the extensions directory and add the needed jar to the classpath of the application/utility.
To further deal with startup mess (executable JARs do not go far enough) for multiple OSs I have written an ingenous startup script. If you want a copy of it, just email me.
Today is not a good day.. I accidently hit enter on the last comment. :(
Generally the higher the frequencies the more dangerous RF exposure is to human flesh. Microwave frequencies are a lot more dangerous than HF (link helpful in finding more information reguarding this issue.
I made a mistake in units. The 33cm (902-928Mhz) band has 26 MHz and not 26 kHz of bandwidth. It would be capable of supporting a WiFi like digital spread spectrum channel needing 22 MHz of bandwidth. Sorry for any confusion.
With a little time and effort almost any American can get an amateur radio technician class license from the FCC. It does not allow you to transmit 1500 watts at 2.4Ghz! The 2.4Ghz band is unlicensed and the max transmittion power is 100 milliwatts. The closest microwave frequencies are 902-928 MHz and 1.24-1.3Ghz. You should note that there is only 26 kHz and 60 MHz of bandwidth available respectively. Thus the 23cm (1.24-1.3Ghz) band is the only choice for applications similiar to WiFi. 802.11b eats up 22 MHz of bandwidth.
Digital Spread Spectrum is still in its infancies in the amateur radio community. However, progress is being made.
With what little knowledge that I have concerning radio theory, it should be possible to modify an access point or WiFi card and get it on the 23cm band. It might even be easier considering that 1.24 Ghz is almost a harmonic (half) of 2.4Ghz.
If you do manage to do such a thing, there would be a few requirements concerning identification. The access point would need to broadcast your callsign; this might be fullfilled with your callsign as the SID. The data traffic could not be encrypted, the data could not be offensive, and you must have control over the equipment.