The article mentioned that 50% of internet traffic flows through the state of Va. Given these new laws, it sounds to me like a good place to setup a honeypot farm. Imagine a beowulf cluster of honeypots...:-)
Sadly, the vote with your wallet solution will ensure that the BIOS borg win. There are far more people that will buy new PeeCees with this crap on it than those of that know better.
Ok, my memory is not completely clear on this. However, I don't recall there being any way to get HAM in non-interlaced mode. I remember looking for any way to get rid of the flicker. I thought it was a limitation of the graphics hardware, not the monitor. I could be wrong. Are you speaking in generalities, or based on experience with actual Amiga hardware?
Oh yeah, HAM mode was great - if you liked going blind. It was Interlaced rendering it nearly useless. If you think setting your PC monitor at 60Hz is bad, try 30Hz. Ugh!
I owned an Amiga 2000 and enjoyed it thoroughly. It served it's purpose. Now it is just a piece of computer history. Ooops! Sorry! I hope the Amiga bigots aren't reading this.:-)
BTW, I forgot to mention how sad it was to see the blundering corporate giant Micron gobble up Rendition, only to see them fade away in beauraucratic dust.
I absolutely agree! I was a big fan of Rendition. They had the greatest bang for the buck - my first add-on card was 2nd gen Verite card (Diamond Stealth V220). This article was a total waste of time. I could have written it just based on my (fading) memory.
I'm glad to see Dreamworks has put creativity on the corporate calander, like the latest Chipzilla releases. I'm sure they will inspire artistic vision with their accounting ledger.
OK. Here is a gaping plot hole. The whole reason the humans became batteries is because the machines could not use solar energy anymore. Yet in Revolutions, you see Neo and Trinity fly over the clouds and see the sun.
So... Are the machines so infinitely stupid that they could not mount thier solar arrays on large towers?
Re:Especially in the fog of marketese that is .NET
on
Advanced .NET Remoting
·
· Score: 1
First you must tell me the problem. Problems using remove object technologies can often be solved in much simpler ways.
For example, I had a need for a very simple remote procedure call in a past job. It was only one procedure with fairly simple inputs. I didn't want to suffer the pain of Corba. Instead, I wrote a simple socket interface and protocol to send the requests. The cost of coding that solution was less than the cost of learning and deploying Corba, as well as forcing users to deploy Corba as well.
Why bring in a 10-ton coal-mine dumptruck to haul a shovel-full of sand?
Re:I'll tell you what he suggests...
on
Advanced .NET Remoting
·
· Score: 2, Informative
Ironically, I have witnessed something close to what you describe. I work for a company that has a HUGE India workforce - roughly 1/3 of the company. The company was founded by an Indian, so I can't bitch too much.:-|
Anyway, India was initially used for data gathering, which involved taking large catalogs and entering the data manually. To speed this up they would scan the catalog pages and view them electronically.
When PDFs starting entering the process, guess what they did. This is no joke...
Print PDF -> Scan printed pages -> View scanned pages -> Enter data manually
All of this India outsourcing is going to come full circle when the (rotten) fruits of their labor become apparent.
As a Software Engineer in a 1/3 India-labor company, I am not afraid. Sure they can pay 4 of them for 1 of me, but the mythical man-month applies here. The sum of the parts does not equal the whole.
Re:Especially in the fog of marketese that is .NET
on
Advanced .NET Remoting
·
· Score: 1, Insightful
I can take a guess...
.NET remoting is the new name for DCOM. They changed the name to lure a bunch more unsuspecting saps into using their pointless technology.
For roughly 10 years now I've seen the promotion of remote object technologies. The pain and suffering they inflict is almost always greater than the supposed benefits.
In case you think I'm just.NET-bashing, I feel the same way about EJBs.
Well said! I was going to post a reply saying the same thing. Personally, I think EJBs are evil and should be purged from the face of the planet. IMHO, they offer very little value, yet introduce a tremendous performance penalty. The article mentions that EJB 2.0 introduced local interfaces. I thought the whole reason for using EJBs was to allow for seamless remote access.
I have been happily coding J2EE apps sans EJBs with great success.
The article got one thing right. The greatest impact on performance is a good application design.
I learned this the hard way. I had the United Devices cancer research agent running on my laptop. I unfortunately did not realize the power penalty of running this app in the background until I was on an airplane and ran out of battery in
In terms of wear and tear on your hardware, I would suspect it would be minimal, if you compare it to leaving the machine on running idle.
BTW, I know SETI paved the way for this technology, but feel something like UD research has far more potential benefit to society than SETI.
I have a modern nForce2 system crammed into a Gateway GP6-333 case. I call this a practical case mod because I had to whip out the dremel tool to make things fit, but it was purely for practical reasons, not aesthetic reasons. I had to cut room for the power supply, and also had to cut holes for all the on-board connectors on my mobo.
Despite what the poster said, power supplies are no longer immune to Moore's law. I had to put a new PS in the case to support the power requirements of a modern AMD CPU. It seems a PS can now only survive 2-3 upgrades.
I also salvaged the CD-ROM drive from the GP6, but put in a middle-aged CD burner.
The main goal of this system was to minimize cost. It is a Win98 system purpose-built to run all the old kids games that were targeted for Win95/98 and do not run on Win2K+. It's kind of weird booting Win98 on such a smokin' fast system. Sadly, the Win98 install and hardware discovery algorithms do not benefit much from the speedy hardware.
Sorry - no. I don't remember all the details - it was a couple years ago. I do know that we were using PHP3 for the app and the client was IE5.0. It was the worst kind of problem - intermittent.
I disagree. There are times when a web developer DOES need to get down and dirty with HTTP. I can think of two intances (off the top of my head) that I ran across:
IE's disasterous handling of mime types and Content-Disposition
Bug in IE client that was dropping packets. I had to view HTTP packets in ethereal to figure that one out
I found O'Reilly's HTTP: The Definitive Guide, 2002 invaluable for solving the first problem.
I worked in the HP-UX compiler group at HP, so I have a pretty good idea of what you are talking about and can appreciate what you are saying. We were a (hefty) cost center attached to the hardware sales. Our greatest value was to deliver better benchmark scores.
I witnessed bloated organizations supporting lots of engineers that did not contribute enough work to subsidize their salaries. When I was there in the 90's, HP was famous for hiring Phd's straight out of college. Good at pontificating. Not so good at implementing.
The Phd motto: When the going gets tough, write a whitepaper.:-/
I guess my real point of the matter is, if you aren't turning a profit at what you are doing, you are either in a doomed business, or you are inefficient. My comments above speak to the inefficiencies that permeate organizations like the one you described.
Ummmm. The last time we tried to buy some Sun servers, they were pretty freakin' expen$ive! If you aren't turning a profit off $1M systems, then you have too much dead-weight. That's what happened to DEC - too many chiefs and not enough rowers.
Slashdot Mirror
The article mentioned that 50% of internet traffic flows through the state of Va. Given these new laws, it sounds to me like a good place to setup a honeypot farm. Imagine a beowulf cluster of honeypots... :-)
Sadly, the vote with your wallet solution will ensure that the BIOS borg win. There are far more people that will buy new PeeCees with this crap on it than those of that know better.
You will be assimilated.
...to call the idiots that enacted this law retarded?
Actually, that would be unfair to retarded people.
Never mind.
Ok, my memory is not completely clear on this. However, I don't recall there being any way to get HAM in non-interlaced mode. I remember looking for any way to get rid of the flicker. I thought it was a limitation of the graphics hardware, not the monitor. I could be wrong. Are you speaking in generalities, or based on experience with actual Amiga hardware?
Oh yeah, HAM mode was great - if you liked going blind. It was Interlaced rendering it nearly useless. If you think setting your PC monitor at 60Hz is bad, try 30Hz. Ugh!
:-)
I owned an Amiga 2000 and enjoyed it thoroughly. It served it's purpose. Now it is just a piece of computer history. Ooops! Sorry! I hope the Amiga bigots aren't reading this.
BTW, I forgot to mention how sad it was to see the blundering corporate giant Micron gobble up Rendition, only to see them fade away in beauraucratic dust.
I absolutely agree! I was a big fan of Rendition. They had the greatest bang for the buck - my first add-on card was 2nd gen Verite card (Diamond Stealth V220). This article was a total waste of time. I could have written it just based on my (fading) memory.
I'm glad to see Dreamworks has put creativity on the corporate calander, like the latest Chipzilla releases. I'm sure they will inspire artistic vision with their accounting ledger.
OK. Here is a gaping plot hole. The whole reason the humans became batteries is because the machines could not use solar energy anymore. Yet in Revolutions, you see Neo and Trinity fly over the clouds and see the sun.
So... Are the machines so infinitely stupid that they could not mount thier solar arrays on large towers?
First you must tell me the problem. Problems using remove object technologies can often be solved in much simpler ways.
For example, I had a need for a very simple remote procedure call in a past job. It was only one procedure with fairly simple inputs. I didn't want to suffer the pain of Corba. Instead, I wrote a simple socket interface and protocol to send the requests. The cost of coding that solution was less than the cost of learning and deploying Corba, as well as forcing users to deploy Corba as well.
Why bring in a 10-ton coal-mine dumptruck to haul a shovel-full of sand?
Ironically, I have witnessed something close to what you describe. I work for a company that has a HUGE India workforce - roughly 1/3 of the company. The company was founded by an Indian, so I can't bitch too much. :-|
Anyway, India was initially used for data gathering, which involved taking large catalogs and entering the data manually. To speed this up they would scan the catalog pages and view them electronically.
When PDFs starting entering the process, guess what they did. This is no joke...
Print PDF -> Scan printed pages -> View scanned pages -> Enter data manually
All of this India outsourcing is going to come full circle when the (rotten) fruits of their labor become apparent. As a Software Engineer in a 1/3 India-labor company, I am not afraid. Sure they can pay 4 of them for 1 of me, but the mythical man-month applies here. The sum of the parts does not equal the whole.
I can take a guess...
.NET remoting is the new name for DCOM. They changed the name to lure a bunch more unsuspecting saps into using their pointless technology.
.NET-bashing, I feel the same way about EJBs.
For roughly 10 years now I've seen the promotion of remote object technologies. The pain and suffering they inflict is almost always greater than the supposed benefits.
In case you think I'm just
The Horror
Yay! Now you have an unmaintainable pile of poop sitting on top of a language with enough holes to drive a truck through.
Well said! I was going to post a reply saying the same thing. Personally, I think EJBs are evil and should be purged from the face of the planet. IMHO, they offer very little value, yet introduce a tremendous performance penalty. The article mentions that EJB 2.0 introduced local interfaces. I thought the whole reason for using EJBs was to allow for seamless remote access.
I have been happily coding J2EE apps sans EJBs with great success.
The article got one thing right. The greatest impact on performance is a good application design.
I learned this the hard way. I had the United Devices cancer research agent running on my laptop. I unfortunately did not realize the power penalty of running this app in the background until I was on an airplane and ran out of battery in
In terms of wear and tear on your hardware, I would suspect it would be minimal, if you compare it to leaving the machine on running idle.
BTW, I know SETI paved the way for this technology, but feel something like UD research has far more potential benefit to society than SETI.
I have a modern nForce2 system crammed into a Gateway GP6-333 case. I call this a practical case mod because I had to whip out the dremel tool to make things fit, but it was purely for practical reasons, not aesthetic reasons. I had to cut room for the power supply, and also had to cut holes for all the on-board connectors on my mobo.
Despite what the poster said, power supplies are no longer immune to Moore's law. I had to put a new PS in the case to support the power requirements of a modern AMD CPU. It seems a PS can now only survive 2-3 upgrades.
I also salvaged the CD-ROM drive from the GP6, but put in a middle-aged CD burner.
The main goal of this system was to minimize cost. It is a Win98 system purpose-built to run all the old kids games that were targeted for Win95/98 and do not run on Win2K+. It's kind of weird booting Win98 on such a smokin' fast system. Sadly, the Win98 install and hardware discovery algorithms do not benefit much from the speedy hardware.
Holy Mackarel! 170KB/s download speed. Principles aside indeed!
Sorry - no. I don't remember all the details - it was a couple years ago. I do know that we were using PHP3 for the app and the client was IE5.0. It was the worst kind of problem - intermittent.
- IE's disasterous handling of mime types and Content-Disposition
- Bug in IE client that was dropping packets. I had to view HTTP packets in ethereal to figure that one out
I found O'Reilly's HTTP: The Definitive Guide, 2002 invaluable for solving the first problem.That is just WAY too funny! /. needs a special category for humor that goes above and beyond the rest.
I worked in the HP-UX compiler group at HP, so I have a pretty good idea of what you are talking about and can appreciate what you are saying. We were a (hefty) cost center attached to the hardware sales. Our greatest value was to deliver better benchmark scores.
:-/
I witnessed bloated organizations supporting lots of engineers that did not contribute enough work to subsidize their salaries. When I was there in the 90's, HP was famous for hiring Phd's straight out of college. Good at pontificating. Not so good at implementing.
The Phd motto: When the going gets tough, write a whitepaper.
I guess my real point of the matter is, if you aren't turning a profit at what you are doing, you are either in a doomed business, or you are inefficient. My comments above speak to the inefficiencies that permeate organizations like the one you described.
I suspect we would see the Java equivalent of Mono - let's call it Latte.
Ummmm. The last time we tried to buy some Sun servers, they were pretty freakin' expen$ive! If you aren't turning a profit off $1M systems, then you have too much dead-weight. That's what happened to DEC - too many chiefs and not enough rowers.