No, it's because C++, in the form of "cfront", was free.
Bell Labs also created a language called "C+@", which was more dynamic, like Java. A small company called Unir Tech ended up with the rights and built a commercial semi-interpreted system in the early 1990s. Nobody knows about that because it was proprietary.
Their stock is in a screaming dive. Closed at $7.77 today, down from $22 at peak.
Their VCs want their money back.
Before they can sue Linux users over copyright violations, they have to beat IBM and Novell and Red Hat and Damlier-Chrysler or AutoZone.
They're losing against IBM, and the other suits aren't going anywhere yet.
IBM's law firm is Cravath, the big hammer of corporate litigation. Cravath puts huge teams of lawyers on the job and has an organized process for not missing anything and not making mistakes.
Nobody wins a weak suit against Cravath.
SCO has never sued a Linux user that didn't have a previous contract with SCO. If they try, any such suit can be stalled until the big lawsuits are settled, for the same reason the Red Hat lawsuit is on hold.
Because SCO has been sueing their own customers, it's dangerous to become an SCO customer. SCO sales have thus tanked.
Most cell phones only use 4800 to 9600 bits/sec for voice. If you can't get voice over 38Kb/s (which is all that "56K" modems actually deliver upstream) you're doing something wrong.
Some notes on how to do VOIP over dialup..
You have to be dialed up to get incoming calls, but that's not too bad.
I tend to agree with much of the above. But I think that Java and C# are the "next big languages" for the present.
Strostrup does say that he's reasonably happy with the basic language. I don't agree. If the basic language was OK, there wouldn't be a need for C#, etc.
C++ has some major outstanding problems, dating from early bad design decisions. Not just C legacy problems, either. Here's a few of them:
The original C++ language had no templates, no exceptions, no run time type info, and no references. This led to a horrible programming style in the early years, with big ugly macros, no standard way of handling errors, wide use of unchecked downcasts, and "this" as an assignable pointer. Much of that legacy lives on in running code.
You can't implement safe smart pointers in C++.
No matter how hard you try, you can't make auto_ptr work right. It's been formally revised three times, without success. The problem is that you have to let a raw C pointer out of the encapsulation to do anything with the object, and that pointer isn't "special" to the language. There needs to be a const-like attribute that says "this pointer can't be deleted or copied to an outer scope". Then you can build safe encapsulations.
Iterators and references were both afterthoughts. They should have been a fundamental part of the language. C's ambiguous syntax for pointers, which makes a pointer to an object and a pointer within an array
indistinguishable, shouldn't have been perpetuated in C++.
A major effort should have been made to make built-in arrays obsolete. Even today, you still see extensive use of C arrays in C++ code. They should be unnecessary. To this day, you can't say "no C arrays or pointers allowed in C++ code" on a project. If you could, there'd be far fewer buffer overflows.
None of this is being fixed in C++. That's the problem
There's no safety conflict between better bumpers and safety. It's a minor cost issue; better bumpers added about $21 per car in the 1980s. But repair parts are a big profit center for car makers, so they want body parts to break.
There's something of a styling issue. Useful bumpers need to extend a bit beyond the vehicle, which some stylists don't like. There's also the bumper height problem. Bumper heights are standardized for US cars, but not for SUVs and light trucks. This is a big "compatibility" problem.
That is one little hack away from luggage that explodes when you phone it up. How long do you think luggage containing an active phone will be allowed?
That's what explosives detection machines are for.
For a few years in the 1980s, cars had to have good bumpers. Vehicles had to survive a 5MPH collision with very limited damage.
The auto industry fought the 5MPH no-damage bumper standard hard. and it was reduced to 2.5MPH and weakened in other ways under Republican administrations.
Then came "integrated bumpers" and "bumperless cars". Those things can be totalled at very low speeds. Damages in minor collisions soared.
Here's the
Institute for Highway Safety on the "$3000 light replacement" issue. They write: "The Institute's continuing series of 5 mph bumper tests show that
today's flimsy bumpers can result in substantial and expensive
damage to vehicle lighting systems. For example, in March of
this year the Institute released results of front-into-angle-barrier
tests of several new models. In the tests, the housings
for the headlights on both the Acura RL and Infiniti Q45 broke
and had to be replaced. Largely because of the cost of the
headlamp assembly, the damage to the Q45 in the angle-barrier impact totaled $2,661."
That's probably the source of the "$3000" figure.
The lack of a tough bumper standard coupled with the crashworthyness requirement means that the car's crumple zones crumple in minor collisions. Hence the big repair bills.
D is Walter Bright's improvement on C++. Bright wrote the original Zortech C++ compiler, which was one of the first real C++ compilers, as opposed to a front-end for a C compiler. D is really too similar to the other C++ variants to get much traction.
C++ itself is undergoing a revision. But the plans for it aren't that good.
The big problem with the C++ committee is that most of the members don't want to admit the language has major problems. Neither does Strostrup, who has written that only minor corrections are needed. If that was really true, we wouldn't need all those variants on C++ (Java, D, C#, Objective-C, Managed C++, etc.)
The committee is dominated by people who like doing cool things with templates. Most of the attention is focused on new features for extending the language via templates. It's possible to coerce the C++ template system into running programs at compile time (see Blitz). Painfully.
LISP went down this dead end, where the language was taken over by people who wanted to extend the language with cool macros. (See the MIT
Loop Macro.) We all know what happened to LISP.
What isn't happening is any serious attempt to make C++ a safer language. C++ is the the only major language that provides abstraction without memory safety. That's why it causes so much trouble. C++ objects must be handled very carefully, or they break the memory model. This usually results in bad pointers or buffer overflows. Java, etc. are protected against that.
This is the basic reason that writing C++ is hard.
It's not fundamentally necessary to give up performance for memory safety. I've written a note on "strict mode" for C++, an attempt to deal with the problem. I'm proposing reference counts with compile-time optimization, rather than garbage collection. The model is close to that of Perl's runtime, which handles this well.
Garbage collection doesn't really fit well to a language with destructors, because the destructors are called at more or less random times. Microsoft's Managed C++ does that, and the semantics of destructors are painful.
With reference counts, destructor behavior is repeatable and predictable, so you can allocate resources (open files, windows) in constructors and have things work. The main problem with reference counts is overhead, but with compiler optimization support and a way to take a safe non-reference-counted pointer from a reference counted object, you can get the overhead way down
and reference count updates out of almost all inner loops.
C++ itself isn't that bad. The language could be fixed. But I don't see it happening. Microsoft has gone off in a different direction with C#. SGI, HP, DEC, Bell Labs, SCO, and Sun are defunct or in no position to drive standards any more.
What C++ needs is some hardass in a position to slam a fist on the table and say "Fix it so our software doesn't crash all the time". It doesn't have one.
There's an indicator on the TSA-openable lock that turns red when it's opened with the master key. So you have some idea of what's going on.
The next step should be to put a clock in the thing, so you know when it was opened. That helps place blame.
You ought to be able to call your luggage on your cell phone and get its location. Wherify has announced a product for this, but isn't yet shipping.
Another option is to go private, with the company taking on debt to buy out the VCs. For a profitable company, that's an option. For Google, it makes sense, because they don't need to raise money for expansion. Arguably, Google is a mature company, not a growth stock - most of their growth is behind them.
The end result of going private would be a company owned by the founders, paying off some large bonds out of profits.
With interest rates so low, that's a good option right now.
Exactly. It's not a big flaw, either. It's a few bits of state that look different in user and kernel mode, and can't be faked from user mode. VMware has to scan code for instructions that look at those bits, and patch around the problem.
This is a delicate process, because they have to support self-modifying code, code in data spaces, code on the stack, data that looks like code, and similar annoyances. That's where the hacks become ugly.
This problem could be fixed in hardware, and, I think, AMD did so in their 64-bit implementation. Does anyone know for sure?
Incidentally, this has nothing to do with Palladium; it's a design bug dating back to the Intel 386.
This is another one of those pork programs pushed through by Southern legislators. The Old Dominion University maglev is one car on a single 3/4 mile stretch of totally straight track. And the bozos building it can't even make that work.
Similar maglevs have been built. Birmingham Airport had one from the mid 1980s to 1995. It was too hard to maintain, and was replaced with a cable-driven system.
Even as a pork program, the Old Dominion University system sucks.
Better taxpayer-supported overpriced transit systems have been built at Southern universities. The Morgantown, West Virginia Group Rapid Transit System is a futuristic system started during the Nixon administration and opened in 1975. It's automated, with 3.6 miles of line, five stations, and little eight-person cars. It's an advanced system; all stations are "offline", and cars pull off the main line to stop at stations, rather than blocking the main tracks.
It actually works, but it's way overbuilt for the usage it gets.
It's not clear what's going on here. If it's an x86 CPU emulator, this is quite possible, but it will be slow. If most code is executing natively, it's necessary to use the hacks VMware does. (IA-32 machines don't hypervise properly, but they're close. That's why VMware is possible, but a horrible hack. Compare VM for IBM mainframes, where the hardware was done right.) The review says that there are no benchmarks because this is a pre-release version.
Actually, if you want to run virtual machines, the way to go might be the AMD 64-bit machines, which supposedly have the proper hardware support virtual IA-32 machines. Has anybody tried that yet?
This sounds like the stuff we see in sci.inventors.
"I have this great valuable idea, but am too clueless to make it work and too clueless to read a few books about the technology".
Anyway.
Short-range inductive power transmission works reasonably well. It's commonly used to recharge electric shavers and toothbrushes. Considerable power can be transferred this way. The GM EV1 electric car used an inductive charger, where a flat "paddle" containing a coil was inserted into a rectangular slot in the car.
Efficiency improves with frequency. The EV1 charger ran at 400KHz or so. But you have to take precautions not to become an RF emitter, and get FCC type approval. If you stay with 60Hz, that's usually not a problem.
Coil area helps. If you can use large diameter coils, bigger than the air gap between them, it will probably work.
If you don't need much power but want directionality, one interesting option might be to have a bright light aimed at a solar cell. You'll be lucky to get 1% efficiency. If that's enough, you're done. It's safe.
If you need very little power but have room for a physically large antenna, you might be able to build something that runs off ambient RF fields. Just make a big flat coil, wire it to a diode, and see what comes out. The output will vary enormously depending on how close you are to a transmitter. If you're lucky, you might be able to power a clock.
I have a Panasonic monitor that doesn't have a tuner, and a DVD player that doesn't have a tuner.
Works fine.
I just don't see what's so compelling about broadcast TV. I see it at the gym and in hotels, but after ten minutes, I've lost interest. Most of the content is boring, and the commercial interruptions are too annoying. I can't imagine how anybody with a working brain could watch several hours per day of that stuff. Even Slashdot is more interesting.
Wierd. You're right. "The Corporation" is SCO, not Baystar. And redemption of the preferred stock is at the "face amount" of $1000 per share. So this isn't really relevant right now.
Here's the key clause, from SCO's SEC filing on the deal.
If the Closing Sales Price of the Common Stock is less than $10.50 (as adjusted to reflect any stock dividends, distributions, combinations, reclassifications and other similar transactions effected by the Corporation in respect to its Common Stock) for at least twenty (20) consecutive trading days, the Corporation shall have the right to redeem any shares of Series A-1 Preferred Stock then outstanding at price per share of Series A-1 Preferred Stock equal to the Face Amount plus all accrued and unpaid Dividends thereon through the closing date of such redemption.
OK, has that happened? Almost, but not quite. Look at the closing price data. From 9 March 2004 to 2 April 2004, there's a string of 19 days with a closing price below $10.50. Now we see why SCO frantically tried a stock buyback program, which pushed the price above the threshold for a mere three days.
But there's a clause in the Baystar agreeement that prohibits SCO from doing most share repurchases.
This is going to get very ugly. Probably on Monday. When, remember, SCO finally has to disclose to IBM and the court what the claimed "infringing code" is. That deadline is tomorrow.
Everyone sued by SCO has had a previous contractual relationship with SCO. They've never made a straight copyright claim against an unaffiliated Linux user in court. So it's clear that the only people who might need insurance are SCO's customers.
Also, the Delaware court ruled, in putting the Red Hat vs. SCO suit on hold, that the Utah court was deciding the copyright issue. Based on that precedent, copyright-related suits can be expected to go on hold until IBM vs SCO is decided. So SCO is a long way from being able to enforce copyright claims against anybody. They'd have to beat IBM, then Novell, then Red Hat. Only then would Linux users have anything to worry about.
The market has picked up on this. SCO tried a stock buyback scheme to boost the the price of their stock. That worked for only a week, and bumped the price up from 9 to 11 or so. It's back to single digits today, at 9.09 today and dropping. It was 16 back in February, and 3 a year ago, before all the lawsuits.
That's surprising. Alias/Wavefront's Maya package is the leading product in the high-end animation industry today, having displaced Softimage. Arguably, it's SGI's most successful business. Yet they sold it for only $57 million.
It looks like Alias is going private, with the management buying the company with assistance from VCs. There may be other terms to this deal, but it's not clear how SGI benefits, other than the cash.
Medium-sized electric motors are already about 80%-90% efficient.
Here's a discussion of improvements in motor efficiency at Reliance Electric, a large manufacturer of motors. They're pushing towards 96% efficiency on large motors. So that's where things are in the real world. Claims for huge efficiency increases beyond those last 10-20% imply a claim of perpetual motion.
The guy behind this psuedo-motor "has been an entertainer for most of his life,
making music and producing his daughter's singing career in the US." Not a good sign.
"Japan's second largest convenience store chain" is Lawson, Inc. You might ask them if they really bought those motors.
"Extracting the energy from magnets" is an old idea from the "over unity" bozos. It never works.
If it did, it would quickly demagnetize the magnets. There's not that much energy in a permanent magnet. It's doesn't take much energy to magnetize one, after all. Here, buy a magnetizer.
Multiplying average current and average voltage to get average wattage is another classic boner.
You have to integrate the product of the instantaneous values, which requires a true wattmeter or a scope.
For anything but DC, the results are off, and for wierd waveforms, it's way off. In particular, if you have something like a tank circuit, where peak voltage occurs with minimum current, and vice versa, the power is far lower than a simple product would indicated. The "piezo" over-unity nuts went down that dead end about a decade ago.
No combination of energy-losing operations is ever going to result in an energy gain. Didn't anybody here go to engineering school?
Re:MV does NOT host atriks
on
Paid To Spam
·
· Score: 1
Slashdot Mirror
Bell Labs also created a language called "C+@", which was more dynamic, like Java. A small company called Unir Tech ended up with the rights and built a commercial semi-interpreted system in the early 1990s. Nobody knows about that because it was proprietary.
-
Their stock is in a screaming dive. Closed at $7.77 today, down from $22 at peak.
-
Their VCs want their money back.
-
Before they can sue Linux users over copyright violations, they have to beat IBM and Novell and Red Hat and Damlier-Chrysler or AutoZone.
-
They're losing against IBM, and the other suits aren't going anywhere yet.
-
IBM's law firm is Cravath, the big hammer of corporate litigation. Cravath puts huge teams of lawyers on the job and has an organized process for not missing anything and not making mistakes.
Nobody wins a weak suit against Cravath.
-
SCO has never sued a Linux user that didn't have a previous contract with SCO. If they try, any such suit can be stalled until the big lawsuits are settled, for the same reason the Red Hat lawsuit is on hold.
-
Because SCO has been sueing their own customers, it's dangerous to become an SCO customer. SCO sales have thus tanked.
So there.You have to be dialed up to get incoming calls, but that's not too bad.
Strostrup does say that he's reasonably happy with the basic language. I don't agree. If the basic language was OK, there wouldn't be a need for C#, etc.
C++ has some major outstanding problems, dating from early bad design decisions. Not just C legacy problems, either. Here's a few of them:
-
The original C++ language had no templates, no exceptions, no run time type info, and no references. This led to a horrible programming style in the early years, with big ugly macros, no standard way of handling errors, wide use of unchecked downcasts, and "this" as an assignable pointer. Much of that legacy lives on in running code.
-
You can't implement safe smart pointers in C++.
No matter how hard you try, you can't make auto_ptr work right. It's been formally revised three times, without success. The problem is that you have to let a raw C pointer out of the encapsulation to do anything with the object, and that pointer isn't "special" to the language. There needs to be a const-like attribute that says "this pointer can't be deleted or copied to an outer scope". Then you can build safe encapsulations.
-
Iterators and references were both afterthoughts. They should have been a fundamental part of the language. C's ambiguous syntax for pointers, which makes a pointer to an object and a pointer within an array
indistinguishable, shouldn't have been perpetuated in C++.
-
A major effort should have been made to make built-in arrays obsolete. Even today, you still see extensive use of C arrays in C++ code. They should be unnecessary. To this day, you can't say "no C arrays or pointers allowed in C++ code" on a project. If you could, there'd be far fewer buffer overflows.
None of this is being fixed in C++. That's the problem"Heavy and expensive"? Well, see the first linked item. Additional cost: $24 per car. Additional weight: 13 pounds per car. 1983 dollars.
There's something of a styling issue. Useful bumpers need to extend a bit beyond the vehicle, which some stylists don't like. There's also the bumper height problem. Bumper heights are standardized for US cars, but not for SUVs and light trucks. This is a big "compatibility" problem.
That's what explosives detection machines are for.
Then came "integrated bumpers" and "bumperless cars". Those things can be totalled at very low speeds. Damages in minor collisions soared.
Here's the Institute for Highway Safety on the "$3000 light replacement" issue. They write: "The Institute's continuing series of 5 mph bumper tests show that today's flimsy bumpers can result in substantial and expensive damage to vehicle lighting systems. For example, in March of this year the Institute released results of front-into-angle-barrier tests of several new models. In the tests, the housings for the headlights on both the Acura RL and Infiniti Q45 broke and had to be replaced. Largely because of the cost of the headlamp assembly, the damage to the Q45 in the angle-barrier impact totaled $2,661." That's probably the source of the "$3000" figure.
The lack of a tough bumper standard coupled with the crashworthyness requirement means that the car's crumple zones crumple in minor collisions. Hence the big repair bills.
C++ itself is undergoing a revision. But the plans for it aren't that good.
The big problem with the C++ committee is that most of the members don't want to admit the language has major problems. Neither does Strostrup, who has written that only minor corrections are needed. If that was really true, we wouldn't need all those variants on C++ (Java, D, C#, Objective-C, Managed C++, etc.)
The committee is dominated by people who like doing cool things with templates. Most of the attention is focused on new features for extending the language via templates. It's possible to coerce the C++ template system into running programs at compile time (see Blitz). Painfully. LISP went down this dead end, where the language was taken over by people who wanted to extend the language with cool macros. (See the MIT Loop Macro.) We all know what happened to LISP.
What isn't happening is any serious attempt to make C++ a safer language. C++ is the the only major language that provides abstraction without memory safety. That's why it causes so much trouble. C++ objects must be handled very carefully, or they break the memory model. This usually results in bad pointers or buffer overflows. Java, etc. are protected against that. This is the basic reason that writing C++ is hard.
It's not fundamentally necessary to give up performance for memory safety. I've written a note on "strict mode" for C++, an attempt to deal with the problem. I'm proposing reference counts with compile-time optimization, rather than garbage collection. The model is close to that of Perl's runtime, which handles this well.
Garbage collection doesn't really fit well to a language with destructors, because the destructors are called at more or less random times. Microsoft's Managed C++ does that, and the semantics of destructors are painful. With reference counts, destructor behavior is repeatable and predictable, so you can allocate resources (open files, windows) in constructors and have things work. The main problem with reference counts is overhead, but with compiler optimization support and a way to take a safe non-reference-counted pointer from a reference counted object, you can get the overhead way down and reference count updates out of almost all inner loops.
C++ itself isn't that bad. The language could be fixed. But I don't see it happening. Microsoft has gone off in a different direction with C#. SGI, HP, DEC, Bell Labs, SCO, and Sun are defunct or in no position to drive standards any more.
What C++ needs is some hardass in a position to slam a fist on the table and say "Fix it so our software doesn't crash all the time". It doesn't have one.
You ought to be able to call your luggage on your cell phone and get its location. Wherify has announced a product for this, but isn't yet shipping.
The end result of going private would be a company owned by the founders, paying off some large bonds out of profits. With interest rates so low, that's a good option right now.
This problem could be fixed in hardware, and, I think, AMD did so in their 64-bit implementation. Does anyone know for sure?
Incidentally, this has nothing to do with Palladium; it's a design bug dating back to the Intel 386.
They're probably coding COBOL-type apps in C++. That's a low-level job for low level people.
Intel's C++ compiler is also free for non-commercial use. It even runs under Linux.
Similar maglevs have been built. Birmingham Airport had one from the mid 1980s to 1995. It was too hard to maintain, and was replaced with a cable-driven system.
Even as a pork program, the Old Dominion University system sucks. Better taxpayer-supported overpriced transit systems have been built at Southern universities. The Morgantown, West Virginia Group Rapid Transit System is a futuristic system started during the Nixon administration and opened in 1975. It's automated, with 3.6 miles of line, five stations, and little eight-person cars. It's an advanced system; all stations are "offline", and cars pull off the main line to stop at stations, rather than blocking the main tracks. It actually works, but it's way overbuilt for the usage it gets.
Actually, if you want to run virtual machines, the way to go might be the AMD 64-bit machines, which supposedly have the proper hardware support virtual IA-32 machines. Has anybody tried that yet?
Anyway.
Short-range inductive power transmission works reasonably well. It's commonly used to recharge electric shavers and toothbrushes. Considerable power can be transferred this way. The GM EV1 electric car used an inductive charger, where a flat "paddle" containing a coil was inserted into a rectangular slot in the car.
Efficiency improves with frequency. The EV1 charger ran at 400KHz or so. But you have to take precautions not to become an RF emitter, and get FCC type approval. If you stay with 60Hz, that's usually not a problem.
Coil area helps. If you can use large diameter coils, bigger than the air gap between them, it will probably work.
If you don't need much power but want directionality, one interesting option might be to have a bright light aimed at a solar cell. You'll be lucky to get 1% efficiency. If that's enough, you're done. It's safe.
If you need very little power but have room for a physically large antenna, you might be able to build something that runs off ambient RF fields. Just make a big flat coil, wire it to a diode, and see what comes out. The output will vary enormously depending on how close you are to a transmitter. If you're lucky, you might be able to power a clock.
I just don't see what's so compelling about broadcast TV. I see it at the gym and in hotels, but after ten minutes, I've lost interest. Most of the content is boring, and the commercial interruptions are too annoying. I can't imagine how anybody with a working brain could watch several hours per day of that stuff. Even Slashdot is more interesting.
Wierd. You're right. "The Corporation" is SCO, not Baystar. And redemption of the preferred stock is at the "face amount" of $1000 per share. So this isn't really relevant right now.
-
If the Closing Sales Price of the Common Stock is less than $10.50 (as adjusted to reflect any stock dividends, distributions, combinations, reclassifications and other similar transactions effected by the Corporation in respect to its Common Stock) for at least twenty (20) consecutive trading days, the Corporation shall have the right to redeem any shares of Series A-1 Preferred Stock then outstanding at price per share of Series A-1 Preferred Stock equal to the Face Amount plus all accrued and unpaid Dividends thereon through the closing date of such redemption.
OK, has that happened? Almost, but not quite. Look at the closing price data. From 9 March 2004 to 2 April 2004, there's a string of 19 days with a closing price below $10.50. Now we see why SCO frantically tried a stock buyback program, which pushed the price above the threshold for a mere three days.But there's a clause in the Baystar agreeement that prohibits SCO from doing most share repurchases.
This is going to get very ugly. Probably on Monday. When, remember, SCO finally has to disclose to IBM and the court what the claimed "infringing code" is. That deadline is tomorrow.
Also, the Delaware court ruled, in putting the Red Hat vs. SCO suit on hold, that the Utah court was deciding the copyright issue. Based on that precedent, copyright-related suits can be expected to go on hold until IBM vs SCO is decided. So SCO is a long way from being able to enforce copyright claims against anybody. They'd have to beat IBM, then Novell, then Red Hat. Only then would Linux users have anything to worry about.
The market has picked up on this. SCO tried a stock buyback scheme to boost the the price of their stock. That worked for only a week, and bumped the price up from 9 to 11 or so. It's back to single digits today, at 9.09 today and dropping. It was 16 back in February, and 3 a year ago, before all the lawsuits.
After 30 years without a TV, I just can't get into it. Too many commercials. Movie rental is fine, but TV is just too irritating.
It looks like Alias is going private, with the management buying the company with assistance from VCs. There may be other terms to this deal, but it's not clear how SGI benefits, other than the cash.
The guy behind this psuedo-motor "has been an entertainer for most of his life, making music and producing his daughter's singing career in the US." Not a good sign.
"Japan's second largest convenience store chain" is Lawson, Inc. You might ask them if they really bought those motors.
"Extracting the energy from magnets" is an old idea from the "over unity" bozos. It never works. If it did, it would quickly demagnetize the magnets. There's not that much energy in a permanent magnet. It's doesn't take much energy to magnetize one, after all. Here, buy a magnetizer.
Multiplying average current and average voltage to get average wattage is another classic boner. You have to integrate the product of the instantaneous values, which requires a true wattmeter or a scope. For anything but DC, the results are off, and for wierd waveforms, it's way off. In particular, if you have something like a tank circuit, where peak voltage occurs with minimum current, and vice versa, the power is far lower than a simple product would indicated. The "piezo" over-unity nuts went down that dead end about a decade ago.
No combination of energy-losing operations is ever going to result in an energy gain. Didn't anybody here go to engineering school?
You may be right.