One of the common citations that are bandied about is that Linux admins make more than their Windows counterparts. But, the evidence seems to contradict this "wisdom". Most of the Linux admin jobs that I see posted offer lower salaries than comprable Windows admin positions. Surveys, such as this, also indicate that Linux admins are actually paid less than their MCSE counterparts. This naturally begs the question, are Linux admins truely more expensive than the Windows admins?
Another issue is the "difficulty" of administrering Linux, as compared to Windows. While, there are some valid arguements to support this hypothesis, there are also some important details that are seemingly ignored. That is, the difficulty is in fact due to unfamiliarity. Windows admins are unfamiliar with Linux and it is therefore more difficult for them to administer it. But, were these Windows admins born knowing how to administer Windows? Is Windows truely so simple that they can do it without any prior knowledge?
No! The fact is that the Windows admins have had specific training in administering Windows. They have gone to classes, MCSE Boot Camps, seminars all about how to manage Windows. They also have a bookshelf FULL of Windows administration books that they have studied. Now, after all that, Windows is familiar and relatively easy for them to administer. I challenge anyone who makes the difficulty claim to build a bookshelf of equal size to their Windows one. If these people read just as many books on Linux as they have on Windows Administration, they would not find it any more difficult than Windows. This would likely be true even without any Linux classes or Linux Boot Camps.
It has been proven by a legion of CNEs who find Novell no more difficult, in many cases far easier to manage than Windows. Yet The same Windows admins will say that Netware is MUCH harder to manage than Windows.
Also, on the subject of training etc. These TCO reports always factor in the expense of Linux training. However, they do not seem to factor in the cost of Windows training. Let's not forget that the books and the classes and the MCSE boot camps cost a lot of money. Even if that money has already been spent, it must be factored into the TCO. These MCSEs were not born knowing how to administer Windows 2000. It costed thousands of dollars each to raise this generation of MCSEs. In most cases these training courses were paid for by the companies. How can they be simply ignored by the TCO studies? Are these MCSEs going to live forever, or are they going to be replaced by a new generation that will have to aslo be trained at a cost of thousands per head?
I was only able to get the first page before the Slashdotting killed it. Here ya go...
Computers offer the best and most impressive gaming graphics, besting any other console found on today's market; however as of late we have the PC losing some ground as a gaming platform due to impressive development efforts from the popular console makers; a relatively new system with a powerful graphics card offers the most realistic graphics you'll ever lay your eyes on.
Not satisfied with that, PC gamers are always looking for the next best thing to enhance their visual experience. Some might purchase a flat screen monitor; others may choose a faster graphics card which handles higher resolutions. Now that your system is decked out to the hilt, what's next? Well, companies like eDimensional hope you will eventually add some 3D Gaming glasses to the mix.
3D glasses have been out for some time now, but the technology is getting better with every release. Companies like NVIDIA continue to update drivers to improve the 3D gaming experience, which has many companies believing that some day all gamers will own a pair. So is this really the next best thing, or will this leave you looking like a geek for nothing?
Today I'll be reviewing a pair of 3D glasses made by a company called eDimensional. The company was founded in 2000, mainly focusing on enhancing the multimedia experience. They call their 3D technology E-D, and promise it to supply you with an amazing submersive 3D environment. One of the main reasons I decided to review this product was to see how it compared to the DTI 2015XLS 3D LCD Display I reviewed not so long ago, if you can recall that expensive gadget costs nothing less but $1700.
How It Works
I don't know the technical lingo to explain how 3D works, but I'll sum it up as best I can. Basically, people have two eyes and your eyes see things from a perspective when looking at objects depending on their locations, which is called binocular disparity. One eye sees one side of an object, and the other eye sees the other side. Your brain uses both views to create one three dimensional image. So this means the depth you actually see is just a perception of what the brain thinks it is; it may not actually be the true look of an image. Pretty weird stuff, eh?
Anyhow, the E-D system shows you a two eye view from your computer monitor. The depth-of-field is simulated using shutter-glasses with lenses that can alternate between clean and opaque (blocks light). While using the glasses, a left eye image is first displayed on a computer monitor, and the shutter-glasses left lens is clear, while the right lens is dark. The image on the monitor is then switched to the right-eye view, and the lens of the shutter-glasses is reversed. This switching occurs many times per second, fast enough for your eyes not to notice it. Your brain fuses the separate images together to create 3D. Yes, it's just your brains perception of what the image should look like. Pretty neat how we can trick the brain, don't you think?
Nothing, that's what! Contrary to many of these other posts, speech to text is a much better solution.
People seem to be forgetting that speech to text is the back-end for this lip service anyway. In order for it to work, speach is interpreted by a computer which then maps the interpreted speech to canned lip movements. The canned lip movements require cpu horsepower to drive the graphics and they need a large screen for it to be readable. These two reasons are why it is only available on a laptop.
With the speech to text scenario; speech is interpreted by a computer and is matched to canned pieces of text. So far, pretty much the same. But, now the text is output to just about any screen, including the text screens of today's cell phones.
Basically the speech to text would be an automated TTY/TDD system. TTY/TDD has been in use and has proven highly effective for decades.
To answer your question, there is NOTHING wrong with speech to text. However, you won't draw too many VCs with it. Now, put a computerized talking head on it and extoll the greatness of its virtues and you may well be able to sucker in a few VCs. And afterall, isn't that what it's all about?
As it states federal law says that they are allowed to do this. More worrisome is the list of "affiliates", which is usually included in these disclaimers. Most of the policies pose "affiliates" in such a way as to suggest that they are only internal departments and subsidiary companies. But, the fact is that affiliates also include marketing organizations and a lot more.
In a few cases the banks actually have a subsidiary marketing company whose product is marketing lists. In these cases the information is shared with the "affiliates" for "legitimate business purposes" but, the "affiliates" then turn around and resell your information to anyone with the cash.
Recently, I was contacted by a mortgage telemarketer, which I have never done business with. they had ALL of my data including transaction history. When I told them I wasn't interested and that their information was inaccurate they actually had the gall to ask me to correct the inaccurate data. The schmuck says, "We pay a lot of money to get this information and if we aren't getting the right information we need to know about it and you need to help us fix it.". Naturally, I advised him to get bent but it is still infuriating that ANYONE can get this information.
The problem goes further too. It's not just marketing companies that are working against us. The government is as well. No, I'm not a conspiracy theorist.
Few people realize that numerous government agencies provide personal information including your Social Security number to companies "with a legitimate business need for that information". They list examples of companies with legitimate business needs and the first example on the list is marketing companies.
Of course it sucks! But, the genie is out of the bottle.
The article states "We all want big books" but, I want to knwo if this is true. Lately I've been getting tired of suffering through these massive books that are being published of late. Most especially vexing is that it seems that many/most of these 1000+ page books are artificially inflated, size wise. They don't seem to have any more really valuable content than books half their size. Compound this with the fact that the wordy inflation of the books seems to make them much harder reads, not to mention taking an eternity to get through it.
So, I ask the Slashdot crowd; Do you really want big/bigger books? Or, is 300 pages plenty, provided the information is in there?
However, the right way to do it would be to simulate it with aero/hydrodynamic fluid simulation software first
Hmm, perhaps that is the right way but, there's a lot more to it. Fluid dynamics and boat design is really an art, bordering on alchemy. Sure heavy duty hardware doing fluid dynamic simulations factors into it but, theres a lot more as well. Also, you need to be such an artist to make it work. Simply having the hardware and software to do such simulations is woefully inadequate.
If you want the best boat design you need to take a cue from the professionals. In this case you probably want to do what Team OneWorld did with their America's Cup boat. Just pilfer the plans from other peoples designs. The work's already been done for you so, it saves you from having to do all that expensive testing and prototyping.
There have been a lot of new GPUs and video cards lately but, this one is a little unusual. Although this chip doesn't have quite as high a performance level as some of the newest cards, it also doesn't require a frickin liquid nitrogen refridgeration unit in order to operate safely. In fact, compared with the newest video cards, its small heat sink and fan seem down right anemic. That's a good thing.
It seems a little odd to compare BOA and Apache. Granted Apache is the web server of choice so a comparison is not too bizarre but, it is still an apples to oranges comparison.
Boa is much smaller than Apache. This seems like a good thing on the surface, especially for embedded applications, as was suggested in the article. But, Boa is slower and much less functional than Apache. They really aren't comparable servers.
No, I'm afraid that this is not the case. While it is true about the Location Bar not showing the drive letter, this is not new. Windows 98-XP show a similar behavior if they are using recent versions of Internet Explorer. There is a configuration option that allows you to select whether you want the full path (including drive letter) displayed or not.
If you look at this screen shot, you will see that the location bar displays My Computer\yada\yada. However, if you examine the contents of the directory in the pane below, you will notice the hard drive, which is displayed as "C:" along with its usage statistics.
Microsoft's drive letter analogy/concept has a deep rooted history. Users have grown accustomed to this analogy and it is highly unlikely that Microsoft will cahnge it in the future. Most average users that are used to drive letters find the mount point tree that is used in Unix to be almost incomprehensible.
Now, having said all that, it is really impossible to tell what the future holds. Remember that Longhorn is supposed to use a new file system. This new file system is not yet functional in the alpha release so there's no telling what it will actually look like. None the less, if I had to bet, I'd bet that drive letters will continue to be used in Microsoft OSes for a long long long time, regardless of the underlying file system.
With a good amount of hose you could clear your yard of any leaf litter. Also, by plugging the hose into the intake side, with a small inline filter, you could have a central vacuum system for your home.
I definitely want good graphics but, the cooling problems that these new cards bring with them is just getting ridiculous.
What you describe sounds like Knoppix "Cheat Codes". These are simply parameters that can be entered at boot time to disable problematic detection of a particular component. So far, the only thing I've seen any problem detecting correctly has been CardBus on certain laptops.
The "Not so reassuring article", doesn't look so bad to me.
He was appointed to the USAID, note the "I", as in International Development. This is an obscure trade board with little or no policy making power that is likely to do little more that waste some more money. It's not as if he was appointed to head the USDA. Also, the fact the you'd go looking for GWB connections with this rather screams your conspiracy theorist paranoia, eh?
Now, if I was in Russia I might be concerned that this guy is going to push a bunch of mutant corn down my throat but, in Niceville, USA he's not going to have much impact.
Of course, if genetically engineered food escapes into the wild, even on another continent, it will eventually come back to haunt us.
This is not the first time that there have been mix-ups with genetically engineered crops. Such mix-ups are becoming entirely too frequent. Although no injuries have happened to date, that we know of, this is a dangerous situation.
The frightening thing is that this is very likely to become far more common as more and more genetically engineered crops are developed and their use becomes more widespread. So far, the mix-ups have been caught, or so we hope. But, the likelyhood of such crops escaping into the consumer market and the wild is rapidly increasing and the unknown dangers that go with them are frightening.
Man has always tampered with nature with many disaterous results to show for it. The transplanting of non-native species has almost always resulted in a proliferation of the species which then becomes a niusance. Think killer bees, cane toads, rabies, lethal yellowing, dutch elm disease, citrus canker etc...
No one knows what negative effects these genetically altered crops will present in the future. All that we do know is that the opportunity for disaster is enormous.
You ran an experiment to test two different kernels and used two totally different processors? Don't you think that you should have been using identical hardware for this test?
Your "testing" is of no value at all. That is, if you actually did these tests. I suspect this is simply a crafty little troll.
It means that you won't see too much speed-up on your desktop machine. But, if you run a big server that does multiple processes at once, say Oracle, you could see significant performance gains.
In a reply on lkml to Aaron Lehmann's praising of the contest results of the latest 2.5-mm kernel Andrew Morton [interview] explains some of the important performance and design differences between the 2.4 stable series and the 2.5 development series accompanied by illustrating benchmarks.
Most significant gains can be expected at the high end such as large machines, large numbers of threads, large disks, large amounts of memory etc. [...] For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. [...] Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster.
From: Aaron Lehmann To: linux-kernel Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest Date: Mon Nov 11 2002 - 18:04:53 AKST
On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote: > Here are the latest contest (http://contest.kolivas.net) benchmarks up to and > including 2.5.47.
This is just great to see. Most previous contest runs made me cringe when I saw how -mm and recent 2.5 kernels were faring, but it looks like Andrew has done something right in 2.5.47-mm1. I hope the appropriate get merged so that 2.6.0 has stunning performance across the board.
From: Andrew Morton To: linux-kernel mailing list Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest Date: Tue Nov 12 2002 - 02:04:23 AKST Aaron Lehmann wrote: > > On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote: > > Here are the latest contest (http://contest.kolivas.net) benchmarks up to and > > including 2.5.47. > > This is just great to see. Most previous contest runs made me cringe > when I saw how -mm and recent 2.5 kernels were faring, but it looks > like Andrew has done something right in 2.5.47-mm1. I hope the appropriate get merged so that 2.6.0 has stunning performance across > the board.
Tuning of 2.5 has really hardly started. In some ways, it should be tested against 2.3.99 (well, not really, but...)
It will never be stunningly better than 2.4 for normal workloads on normal machines, because 2.4 just ain't that bad.
What is being addressed in 2.5 is the areas where 2.4 fell down: large machines, large numbers of threads, large disks, large amounts of memory, etc. There have been really big gains in that area.
For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. Quite a lot of work has gone into "fairness" issues: allowing tasks to make equal progress when the machine is under load. Not stalling tasks for unreasonable amounts of time, etc. Simple operations such as copying a forest of files from one part of the disk to another have taken a bit of a hit from this. (But copying them to another disk got better).
Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster. Significantly slower when there are several processes causing a lot of swapout. That is one area where fairness really hurts throughput. The old `make -j30 bzImage' with mem=128M takes 1.5x as long with 2.5. Because everyone makes equal progress.
Most of the VM gains involve situations where there are large amounts of dirty data in the machine. This has always been a big problem for Linux, and I think we've largely got it under control now. There are still a few issues in the page reclaim code wrt this, but they're fairly obscure (I'm the only person who has noticed them;))
There are some things which people simply have not yet noticed.
Andrea's kernel is the fastest which 2.4 has to offer; let's tickle its weak spots:
Run mke2fs against six disks at the same time, mem=1G:
2.4.20-rc1aa1: 0.04s user 13.16s system 51% cpu 25.782 total 0.05s user 31.53s system 63% cpu 49.542 total 0.05s user 29.04s system 58% cpu 49.544 total 0.05s user 31.07s system 62% cpu 50.017 total 0.06s user 29.80s system 58% cpu 50.983 total 0.06s user 23.30s system 43% cpu 53.214 total
2.5.47-mm2: 0.04s user 2.94s system 48% cpu 6.168 total 0.04s user 2.89s system 39% cpu 7.473 total 0.05s user 3.00s system 37% cpu 8.152 total 0.06s user 4.33s system 43% cpu 9.992 total 0.06s user 4.35s system 42% cpu 10.484 total 0.04s user 4.32s system 32% cpu 13.415 total
Write six 4G files to six disks in parallel, mem=1G:
2.4.20-rc1aa1: 0.01s user 63.17s system 7% cpu 13:53.26 total 0.05s user 63.43s system 7% cpu 14:07.17 total 0.03s user 65.94s system 7% cpu 14:36.25 total 0.01s user 66.29s system 7% cpu 14:38.01 total 0.08s user 63.79s system 7% cpu 14:45.09 total 0.09s user 65.22s system 7% cpu 14:46.95 total
2.5.47-mm2: 0.03s user 53.95s system 39% cpu 2:18.27 total 0.03s user 58.11s system 30% cpu 3:08.23 total 0.02s user 57.43s system 30% cpu 3:08.47 total 0.03s user 54.73s system 23% cpu 3:52.43 total 0.03s user 54.72s system 23% cpu 3:53.22 total 0.03s user 46.14s system 14% cpu 5:29.71 total
Compile a kernel while running `while true;do;./dbench 32;done' against the same disk. mem=128m:
2.5.46: Throughput 19.3907 MB/sec (NB=24.2383 MB/sec 193.907 MBit/sec) Throughput 16.6765 MB/sec (NB=20.8456 MB/sec 166.765 MBit/sec) make -j4 bzImage 412.16s user 36.92s system 83% cpu 8:55.74 total
2.5.47-mm2: Throughput 15.0539 MB/sec (NB=18.8174 MB/sec 150.539 MBit/sec) Throughput 21.6388 MB/sec (NB=27.0485 MB/sec 216.388 MBit/sec) make -j4 bzImage 413.88s user 35.90s system 94% cpu 7:56.68 total - fifo_batch strikes again
It's the "doing multiple things at the same time" which gets better; the straightline throughput of "one thing at a time" won't change much at all.
In a reply on lkml to Aaron Lehmann's praising of the contest results of the latest 2.5-mm kernel Andrew Morton [interview] explains some of the important performance and design differences between the 2.4 stable series and the 2.5 development series accompanied by illustrating benchmarks.
Most significant gains can be expected at the high end such as large machines, large numbers of threads, large disks, large amounts of memory etc. [...] For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. [...] Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster.
From: Aaron Lehmann
To: linux-kernel
Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest
Date: Mon Nov 11 2002 - 18:04:53 AKST
On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote:
> Here are the latest contest (http://contest.kolivas.net) benchmarks up to and
> including 2.5.47.
This is just great to see. Most previous contest runs made me cringe
when I saw how -mm and recent 2.5 kernels were faring, but it looks
like Andrew has done something right in 2.5.47-mm1. I hope the
appropriate get merged so that 2.6.0 has stunning performance across
the board.
From: Andrew Morton
To: linux-kernel mailing list
Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest
Date: Tue Nov 12 2002 - 02:04:23 AKST
Aaron Lehmann wrote:
>
> On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote:
> > Here are the latest contest (http://contest.kolivas.net) benchmarks up to and
> > including 2.5.47.
>
> This is just great to see. Most previous contest runs made me cringe
> when I saw how -mm and recent 2.5 kernels were faring, but it looks
> like Andrew has done something right in 2.5.47-mm1. I hope the
> appropriate get merged so that 2.6.0 has stunning performance across
> the board.
Tuning of 2.5 has really hardly started. In some ways, it should be
tested against 2.3.99 (well, not really, but...)
It will never be stunningly better than 2.4 for normal workloads on
normal machines, because 2.4 just ain't that bad.
What is being addressed in 2.5 is the areas where 2.4 fell down:
large machines, large numbers of threads, large disks, large amounts
of memory, etc. There have been really big gains in that area.
For the uniprocessors and small servers, there will be significant
gains in some corner cases. And some losses. Quite a lot of work
has gone into "fairness" issues: allowing tasks to make equal progress
when the machine is under load. Not stalling tasks for unreasonable
amounts of time, etc. Simple operations such as copying a forest
of files from one part of the disk to another have taken a bit of a
hit from this. (But copying them to another disk got better).
Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably
faster. Significantly slower when there are several processes causing a
lot of swapout. That is one area where fairness really hurts throughput.
The old `make -j30 bzImage' with mem=128M takes 1.5x as long with 2.5.
Because everyone makes equal progress.
Most of the VM gains involve situations where there are large amounts
of dirty data in the machine. This has always been a big problem
for Linux, and I think we've largely got it under control now. There
are still a few issues in the page reclaim code wrt this, but they're
fairly obscure (I'm the only person who has noticed them;))
There are some things which people simply have not yet noticed.
Andrea's kernel is the fastest which 2.4 has to offer; let's tickle
its weak spots:
Run mke2fs against six disks at the same time, mem=1G:
2.4.20-rc1aa1:
0.04s user 13.16s system 51% cpu 25.782 total
0.05s user 31.53s system 63% cpu 49.542 total
0.05s user 29.04s system 58% cpu 49.544 total
0.05s user 31.07s system 62% cpu 50.017 total
0.06s user 29.80s system 58% cpu 50.983 total
0.06s user 23.30s system 43% cpu 53.214 total
2.5.47-mm2:
0.04s user 2.94s system 48% cpu 6.168 total
0.04s user 2.89s system 39% cpu 7.473 total
0.05s user 3.00s system 37% cpu 8.152 total
0.06s user 4.33s system 43% cpu 9.992 total
0.06s user 4.35s system 42% cpu 10.484 total
0.04s user 4.32s system 32% cpu 13.415 total
Write six 4G files to six disks in parallel, mem=1G:
2.4.20-rc1aa1:
0.01s user 63.17s system 7% cpu 13:53.26 total
0.05s user 63.43s system 7% cpu 14:07.17 total
0.03s user 65.94s system 7% cpu 14:36.25 total
0.01s user 66.29s system 7% cpu 14:38.01 total
0.08s user 63.79s system 7% cpu 14:45.09 total
0.09s user 65.22s system 7% cpu 14:46.95 total
2.5.47-mm2:
0.03s user 53.95s system 39% cpu 2:18.27 total
0.03s user 58.11s system 30% cpu 3:08.23 total
0.02s user 57.43s system 30% cpu 3:08.47 total
0.03s user 54.73s system 23% cpu 3:52.43 total
0.03s user 54.72s system 23% cpu 3:53.22 total
0.03s user 46.14s system 14% cpu 5:29.71 total
Compile a kernel while running `while true;do;./dbench 32;done' against
the same disk. mem=128m:
2.4.20-rc1aa1:
Throughput 17.7491 MB/sec (NB=22.1863 MB/sec 177.491 MBit/sec)
Throughput 16.6311 MB/sec (NB=20.7888 MB/sec 166.311 MBit/sec)
Throughput 17.0409 MB/sec (NB=21.3012 MB/sec 170.409 MBit/sec)
Throughput 17.4876 MB/sec (NB=21.8595 MB/sec 174.876 MBit/sec)
Throughput 15.3017 MB/sec (NB=19.1271 MB/sec 153.017 MBit/sec)
Throughput 18.0726 MB/sec (NB=22.5907 MB/sec 180.726 MBit/sec)
Throughput 18.2769 MB/sec (NB=22.8461 MB/sec 182.769 MBit/sec)
Throughput 19.152 MB/sec (NB=23.94 MB/sec 191.52 MBit/sec)
Throughput 14.2632 MB/sec (NB=17.8291 MB/sec 142.632 MBit/sec)
Throughput 20.5007 MB/sec (NB=25.6258 MB/sec 205.007 MBit/sec)
Throughput 24.9471 MB/sec (NB=31.1838 MB/sec 249.471 MBit/sec)
Throughput 20.36 MB/sec (NB=25.45 MB/sec 203.6 MBit/sec)
make -j4 bzImage 412.28s user 36.90s system 15% cpu 47:11.14 total
2.5.46:
Throughput 19.3907 MB/sec (NB=24.2383 MB/sec 193.907 MBit/sec)
Throughput 16.6765 MB/sec (NB=20.8456 MB/sec 166.765 MBit/sec)
make -j4 bzImage 412.16s user 36.92s system 83% cpu 8:55.74 total
2.5.47-mm2:
Throughput 15.0539 MB/sec (NB=18.8174 MB/sec 150.539 MBit/sec)
Throughput 21.6388 MB/sec (NB=27.0485 MB/sec 216.388 MBit/sec)
make -j4 bzImage 413.88s user 35.90s system 94% cpu 7:56.68 total
What the hell is this?? Your comment has too few characters per line (currently 38.6).
Doing assembly dumps on object code isn't terribly exciting. Doing this on trojans is perhaps even less so, even on Linux.
But, referring to doing this on native Windows code is not a good idea at all. Remember the EULA, simply having the Windows code on your disk constitutes acceptance of the EULA and reverse engineering by assembly dumps is explicitly defined as a violation of the EULA. In other words you are setting yourself in a position for major legal problems.
The only legitimate way to reverse engineer software is the method used by the Samba team. You must look at the input and look at the output and then determine your OWN method of achieving the same result.
This is the only legal way to do it. If you even glance at an assembly dump of the actual software, you are no longer virgin. Thus ANYTHING that you produce afterwards the even vaguely resembles the operation of the original software will place you in a losing position, legally.
Avoid assembly dumps of MS code!
Don't allow yourself to be taken advantage of.
on
Helping Your Ex-Employer?
·
· Score: 5, Insightful
As Cliff stated, you don't want to burn any bridges. Even those that you desperately want to burn, should be maintained. You never know who or when you will need someone in your future.
At the same time do not let anyone take advantage of you. You said that this was a former employer. This immediately releases you of ANY responsibility or obligation to them, you don't work for them anymore!
This could be a slightly grey area if you had recently, within a couple of weeks, left the job on your own accord and the failed system was your responsibility. But, even here there is no REAL responsibility, simply a matter of your own moral feelings on the matter. But, you stated that this emplyer became former 5 months ago. No matter what the reason for your departure there is absolutely positively no obligation on your part after this period of time.
The next time you are presented with this situation, stop for a moment and think. First what are your feelings? Simply, do you want to do it or not? Secondly, review your current situation. Are you working somewhere else and are really to busy to spare the time or perhaps it may be a conflict of interest if you are working for a competitor now. In your case, you stated that you are unemployed so these would not be a problem here. You have time and there are no conflicts.
So, having decided that you can do it and that you want to do it, the next step is to specify the terms of a short term contract. Yes, contract. Even if it is only verbal you are still entering into a contract with this company. You need to come to an agreement on the type and amount of reimbursement for your time. You also need to agree to a set of milestones, if you will, that will be used to determine the successful completion of the contract.
For example, the situation that you related should have gone like this... Yes Jane, I am confident that I can resolve your problem. As it happens I am available to do consulting work of this kind, right now. My fee is $100 per hour for this type of work and I do charge travel time at that rate.
Janes response will likely be: "Wow, I don't want to pay that much." To which you should reply: "I certainly understand that but, that is a competitive rate in the industry and it is what I charge. I suspect from what you have told me so far that it might take 6 hours to fix your problem." At that point she will either say flat out no, and move on to another consultant, or she will say that she has to get back to you. This will give her time to get approval for the expenditure and also get estimates from other consultants. If she calls back make sure that she is in agreement to pay you for fixing the problem and that she fully expects to pay at LEAST $600.
Of course, Jane might decide to try to bully you when you advise her of your rate. She might say something like: "What?? $100 an hour?? No way. You built this system and it has never be right! It's your responsibility and I expect you to fix it immediately! I'm not paying you to fix your own mistakes. In fact, if you don't fix it, we will probably sue you!"
Your response to this should be: "I understand that you feel it is my responsibility, Jane. However, I do not work for you anymore therefore, it is NOT my responsibility. I'm sorry that you feel that I did not build the system properly however, the fact that it has worked for several months without me suggests that it was in fact, working properly. Even so, it is still not my responsibility anymore. But, I would be glad to look at it for you, as a consultant.
Finally, if Jane says that they are going to sue you, end the discussioin right then and there. Say: "I am afraid that, under the circumstances, I will not be able to assist you with your problem. I wish you the best of luck with it. Thank you for calling." click.... Naturally, this assumes that you do indeed not have any contractual liability to the problem. In your specific case, after 5 months, you didn't.
One of the common citations that are bandied about is that Linux admins make more than their Windows counterparts. But, the evidence seems to contradict this "wisdom". Most of the Linux admin jobs that I see posted offer lower salaries than comprable Windows admin positions. Surveys, such as this, also indicate that Linux admins are actually paid less than their MCSE counterparts. This naturally begs the question, are Linux admins truely more expensive than the Windows admins?
Another issue is the "difficulty" of administrering Linux, as compared to Windows. While, there are some valid arguements to support this hypothesis, there are also some important details that are seemingly ignored. That is, the difficulty is in fact due to unfamiliarity. Windows admins are unfamiliar with Linux and it is therefore more difficult for them to administer it. But, were these Windows admins born knowing how to administer Windows? Is Windows truely so simple that they can do it without any prior knowledge?
No! The fact is that the Windows admins have had specific training in administering Windows. They have gone to classes, MCSE Boot Camps, seminars all about how to manage Windows. They also have a bookshelf FULL of Windows administration books that they have studied. Now, after all that, Windows is familiar and relatively easy for them to administer. I challenge anyone who makes the difficulty claim to build a bookshelf of equal size to their Windows one. If these people read just as many books on Linux as they have on Windows Administration, they would not find it any more difficult than Windows. This would likely be true even without any Linux classes or Linux Boot Camps.
It has been proven by a legion of CNEs who find Novell no more difficult, in many cases far easier to manage than Windows. Yet The same Windows admins will say that Netware is MUCH harder to manage than Windows.
Also, on the subject of training etc. These TCO reports always factor in the expense of Linux training. However, they do not seem to factor in the cost of Windows training. Let's not forget that the books and the classes and the MCSE boot camps cost a lot of money. Even if that money has already been spent, it must be factored into the TCO. These MCSEs were not born knowing how to administer Windows 2000. It costed thousands of dollars each to raise this generation of MCSEs. In most cases these training courses were paid for by the companies. How can they be simply ignored by the TCO studies? Are these MCSEs going to live forever, or are they going to be replaced by a new generation that will have to aslo be trained at a cost of thousands per head?
I was only able to get the first page before the Slashdotting killed it. Here ya go...
Computers offer the best and most impressive gaming graphics, besting any other console found on today's market; however as of late we have the PC losing some ground as a gaming platform due to impressive development efforts from the popular console makers; a relatively new system with a powerful graphics card offers the most realistic graphics you'll ever lay your eyes on.
Not satisfied with that, PC gamers are always looking for the next best thing to enhance their visual experience. Some might purchase a flat screen monitor; others may choose a faster graphics card which handles higher resolutions. Now that your system is decked out to the hilt, what's next? Well, companies like eDimensional hope you will eventually add some 3D Gaming glasses to the mix.
3D glasses have been out for some time now, but the technology is getting better with every release. Companies like NVIDIA continue to update drivers to improve the 3D gaming experience, which has many companies believing that some day all gamers will own a pair. So is this really the next best thing, or will this leave you looking like a geek for nothing?
Today I'll be reviewing a pair of 3D glasses made by a company called eDimensional. The company was founded in 2000, mainly focusing on enhancing the multimedia experience. They call their 3D technology E-D, and promise it to supply you with an amazing submersive 3D environment. One of the main reasons I decided to review this product was to see how it compared to the DTI 2015XLS 3D LCD Display I reviewed not so long ago, if you can recall that expensive gadget costs nothing less but $1700.
How It Works
I don't know the technical lingo to explain how 3D works, but I'll sum it up as best I can. Basically, people have two eyes and your eyes see things from a perspective when looking at objects depending on their locations, which is called binocular disparity. One eye sees one side of an object, and the other eye sees the other side. Your brain uses both views to create one three dimensional image. So this means the depth you actually see is just a perception of what the brain thinks it is; it may not actually be the true look of an image. Pretty weird stuff, eh?
Anyhow, the E-D system shows you a two eye view from your computer monitor. The depth-of-field is simulated using shutter-glasses with lenses that can alternate between clean and opaque (blocks light). While using the glasses, a left eye image is first displayed on a computer monitor, and the shutter-glasses left lens is clear, while the right lens is dark. The image on the monitor is then switched to the right-eye view, and the lens of the shutter-glasses is reversed. This switching occurs many times per second, fast enough for your eyes not to notice it. Your brain fuses the separate images together to create 3D. Yes, it's just your brains perception of what the image should look like. Pretty neat how we can trick the brain, don't you think?
These things always give me a head-ache. Also, how do people with glasses manage with these?
It certainly sounds like Bill, doesn't it? Of course, it might also be Steve Jobs asking about the APSL. Doh!
Nothing, that's what! Contrary to many of these other posts, speech to text is a much better solution.
People seem to be forgetting that speech to text is the back-end for this lip service anyway. In order for it to work, speach is interpreted by a computer which then maps the interpreted speech to canned lip movements. The canned lip movements require cpu horsepower to drive the graphics and they need a large screen for it to be readable. These two reasons are why it is only available on a laptop.
With the speech to text scenario; speech is interpreted by a computer and is matched to canned pieces of text. So far, pretty much the same. But, now the text is output to just about any screen, including the text screens of today's cell phones.
Basically the speech to text would be an automated TTY/TDD system. TTY/TDD has been in use and has proven highly effective for decades.
To answer your question, there is NOTHING wrong with speech to text. However, you won't draw too many VCs with it. Now, put a computerized talking head on it and extoll the greatness of its virtues and you may well be able to sucker in a few VCs. And afterall, isn't that what it's all about?
As it states federal law says that they are allowed to do this. More worrisome is the list of "affiliates", which is usually included in these disclaimers. Most of the policies pose "affiliates" in such a way as to suggest that they are only internal departments and subsidiary companies. But, the fact is that affiliates also include marketing organizations and a lot more.
In a few cases the banks actually have a subsidiary marketing company whose product is marketing lists. In these cases the information is shared with the "affiliates" for "legitimate business purposes" but, the "affiliates" then turn around and resell your information to anyone with the cash.
Recently, I was contacted by a mortgage telemarketer, which I have never done business with. they had ALL of my data including transaction history. When I told them I wasn't interested and that their information was inaccurate they actually had the gall to ask me to correct the inaccurate data. The schmuck says, "We pay a lot of money to get this information and if we aren't getting the right information we need to know about it and you need to help us fix it.". Naturally, I advised him to get bent but it is still infuriating that ANYONE can get this information.
The problem goes further too. It's not just marketing companies that are working against us. The government is as well. No, I'm not a conspiracy theorist.
Few people realize that numerous government agencies provide personal information including your Social Security number to companies "with a legitimate business need for that information". They list examples of companies with legitimate business needs and the first example on the list is marketing companies.
Of course it sucks! But, the genie is out of the bottle.
The article states "We all want big books" but, I want to knwo if this is true. Lately I've been getting tired of suffering through these massive books that are being published of late. Most especially vexing is that it seems that many/most of these 1000+ page books are artificially inflated, size wise. They don't seem to have any more really valuable content than books half their size. Compound this with the fact that the wordy inflation of the books seems to make them much harder reads, not to mention taking an eternity to get through it.
So, I ask the Slashdot crowd; Do you really want big/bigger books? Or, is 300 pages plenty, provided the information is in there?
However, the right way to do it would be to simulate it with aero/hydrodynamic fluid simulation software first
Hmm, perhaps that is the right way but, there's a lot more to it. Fluid dynamics and boat design is really an art, bordering on alchemy. Sure heavy duty hardware doing fluid dynamic simulations factors into it but, theres a lot more as well. Also, you need to be such an artist to make it work. Simply having the hardware and software to do such simulations is woefully inadequate.
If you want the best boat design you need to take a cue from the professionals. In this case you probably want to do what Team OneWorld did with their America's Cup boat. Just pilfer the plans from other peoples designs. The work's already been done for you so, it saves you from having to do all that expensive testing and prototyping.
There have been a lot of new GPUs and video cards lately but, this one is a little unusual. Although this chip doesn't have quite as high a performance level as some of the newest cards, it also doesn't require a frickin liquid nitrogen refridgeration unit in order to operate safely. In fact, compared with the newest video cards, its small heat sink and fan seem down right anemic. That's a good thing.
It seems a little odd to compare BOA and Apache. Granted Apache is the web server of choice so a comparison is not too bizarre but, it is still an apples to oranges comparison.
Boa is much smaller than Apache. This seems like a good thing on the surface, especially for embedded applications, as was suggested in the article. But, Boa is slower and much less functional than Apache. They really aren't comparable servers.
No, I'm afraid that this is not the case. While it is true about the Location Bar not showing the drive letter, this is not new. Windows 98-XP show a similar behavior if they are using recent versions of Internet Explorer. There is a configuration option that allows you to select whether you want the full path (including drive letter) displayed or not.
If you look at this screen shot, you will see that the location bar displays My Computer\yada\yada. However, if you examine the contents of the directory in the pane below, you will notice the hard drive, which is displayed as "C:" along with its usage statistics.
Microsoft's drive letter analogy/concept has a deep rooted history. Users have grown accustomed to this analogy and it is highly unlikely that Microsoft will cahnge it in the future. Most average users that are used to drive letters find the mount point tree that is used in Unix to be almost incomprehensible.
Now, having said all that, it is really impossible to tell what the future holds. Remember that Longhorn is supposed to use a new file system. This new file system is not yet functional in the alpha release so there's no telling what it will actually look like. None the less, if I had to bet, I'd bet that drive letters will continue to be used in Microsoft OSes for a long long long time, regardless of the underlying file system.
Here's hoping that Boeing doesn't acquire Armadillo Aerospace. I'd hate to see what would happen if John was launching a Delta 4.
Here is a story about a man that this surgery recently killed.
I'm glad I don't need this type of surgery.
It may take them quite some time to figure it out but, I have already done the research and know what the precise cause is.
Deceleration trauma was in fact, the cause of failure.
With a good amount of hose you could clear your yard of any leaf litter. Also, by plugging the hose into the intake side, with a small inline filter, you could have a central vacuum system for your home.
I definitely want good graphics but, the cooling problems that these new cards bring with them is just getting ridiculous.
What you describe sounds like Knoppix "Cheat Codes". These are simply parameters that can be entered at boot time to disable problematic detection of a particular component. So far, the only thing I've seen any problem detecting correctly has been CardBus on certain laptops.
The "Not so reassuring article", doesn't look so bad to me.
He was appointed to the USAID, note the "I", as in International Development. This is an obscure trade board with little or no policy making power that is likely to do little more that waste some more money. It's not as if he was appointed to head the USDA. Also, the fact the you'd go looking for GWB connections with this rather screams your conspiracy theorist paranoia, eh?
Now, if I was in Russia I might be concerned that this guy is going to push a bunch of mutant corn down my throat but, in Niceville, USA he's not going to have much impact.
Of course, if genetically engineered food escapes into the wild, even on another continent, it will eventually come back to haunt us.
This is not the first time that there have been mix-ups with genetically engineered crops. Such mix-ups are becoming entirely too frequent. Although no injuries have happened to date, that we know of, this is a dangerous situation.
The frightening thing is that this is very likely to become far more common as more and more genetically engineered crops are developed and their use becomes more widespread. So far, the mix-ups have been caught, or so we hope. But, the likelyhood of such crops escaping into the consumer market and the wild is rapidly increasing and the unknown dangers that go with them are frightening.
Man has always tampered with nature with many disaterous results to show for it. The transplanting of non-native species has almost always resulted in a proliferation of the species which then becomes a niusance. Think killer bees, cane toads, rabies, lethal yellowing, dutch elm disease, citrus canker etc...
No one knows what negative effects these genetically altered crops will present in the future. All that we do know is that the opportunity for disaster is enormous.
The first part of the Gnutella2 specs are finally up.
Go go Slashdot....
You ran an experiment to test two different kernels and used two totally different processors? Don't you think that you should have been using identical hardware for this test?
Your "testing" is of no value at all. That is, if you actually did these tests. I suspect this is simply a crafty little troll.
It means that you won't see too much speed-up on your desktop machine. But, if you run a big server that does multiple processes at once, say Oracle, you could see significant performance gains.
Try it again.
;))
In a reply on lkml to Aaron Lehmann's praising of the contest results of the latest 2.5-mm kernel Andrew Morton [interview] explains some of the important performance and design differences between the 2.4 stable series and the 2.5 development series accompanied by illustrating benchmarks.
Most significant gains can be expected at the high end such as large machines, large numbers of threads, large disks, large amounts of memory etc. [...] For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. [...] Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster.
From: Aaron Lehmann
To: linux-kernel
Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest
Date: Mon Nov 11 2002 - 18:04:53 AKST
On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote:
> Here are the latest contest (http://contest.kolivas.net) benchmarks up to and
> including 2.5.47.
This is just great to see. Most previous contest runs made me cringe when I saw how -mm and recent 2.5 kernels were faring, but it looks like Andrew has done something right in 2.5.47-mm1. I hope the appropriate get merged so that 2.6.0 has stunning performance across the board.
From: Andrew Morton
To: linux-kernel mailing list
Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest
Date: Tue Nov 12 2002 - 02:04:23 AKST
Aaron Lehmann wrote:
>
> On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote:
> > Here are the latest contest (http://contest.kolivas.net) benchmarks up to and
> > including 2.5.47.
>
> This is just great to see. Most previous contest runs made me cringe
> when I saw how -mm and recent 2.5 kernels were faring, but it looks
> like Andrew has done something right in 2.5.47-mm1. I hope the appropriate get merged so that 2.6.0 has stunning performance across
> the board.
Tuning of 2.5 has really hardly started. In some ways, it should be tested against 2.3.99 (well, not really, but...)
It will never be stunningly better than 2.4 for normal workloads on
normal machines, because 2.4 just ain't that bad.
What is being addressed in 2.5 is the areas where 2.4 fell down: large machines, large numbers of threads, large disks, large amounts
of memory, etc. There have been really big gains in that area.
For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. Quite a lot of work has gone into "fairness" issues: allowing tasks to make equal progress when the machine is under load. Not stalling tasks for unreasonable
amounts of time, etc. Simple operations such as copying a forest of files from one part of the disk to another have taken a bit of a hit from this. (But copying them to another disk got better).
Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster. Significantly slower when there are several processes causing a lot of swapout. That is one area where fairness really hurts throughput. The old `make -j30 bzImage' with mem=128M takes 1.5x as long with 2.5. Because everyone makes equal progress.
Most of the VM gains involve situations where there are large amounts of dirty data in the machine. This has always been a big problem
for Linux, and I think we've largely got it under control now. There are still a few issues in the page reclaim code wrt this, but they're
fairly obscure (I'm the only person who has noticed them
There are some things which people simply have not yet noticed.
Andrea's kernel is the fastest which 2.4 has to offer; let's tickle its weak spots:
Run mke2fs against six disks at the same time, mem=1G:
2.4.20-rc1aa1:
0.04s user 13.16s system 51% cpu 25.782 total
0.05s user 31.53s system 63% cpu 49.542 total
0.05s user 29.04s system 58% cpu 49.544 total
0.05s user 31.07s system 62% cpu 50.017 total
0.06s user 29.80s system 58% cpu 50.983 total
0.06s user 23.30s system 43% cpu 53.214 total
2.5.47-mm2:
0.04s user 2.94s system 48% cpu 6.168 total
0.04s user 2.89s system 39% cpu 7.473 total
0.05s user 3.00s system 37% cpu 8.152 total
0.06s user 4.33s system 43% cpu 9.992 total
0.06s user 4.35s system 42% cpu 10.484 total
0.04s user 4.32s system 32% cpu 13.415 total
Write six 4G files to six disks in parallel, mem=1G:
2.4.20-rc1aa1:
0.01s user 63.17s system 7% cpu 13:53.26 total
0.05s user 63.43s system 7% cpu 14:07.17 total
0.03s user 65.94s system 7% cpu 14:36.25 total
0.01s user 66.29s system 7% cpu 14:38.01 total
0.08s user 63.79s system 7% cpu 14:45.09 total
0.09s user 65.22s system 7% cpu 14:46.95 total
2.5.47-mm2:
0.03s user 53.95s system 39% cpu 2:18.27 total
0.03s user 58.11s system 30% cpu 3:08.23 total
0.02s user 57.43s system 30% cpu 3:08.47 total
0.03s user 54.73s system 23% cpu 3:52.43 total
0.03s user 54.72s system 23% cpu 3:53.22 total
0.03s user 46.14s system 14% cpu 5:29.71 total
Compile a kernel while running `while true;do;./dbench 32;done' against
the same disk. mem=128m:
2.4.20-rc1aa1:
Throughput 17.7491 MB/sec (NB=22.1863 MB/sec 177.491 MBit/sec)
Throughput 16.6311 MB/sec (NB=20.7888 MB/sec 166.311 MBit/sec)
Throughput 17.0409 MB/sec (NB=21.3012 MB/sec 170.409 MBit/sec)
Throughput 17.4876 MB/sec (NB=21.8595 MB/sec 174.876 MBit/sec)
Throughput 15.3017 MB/sec (NB=19.1271 MB/sec 153.017 MBit/sec)
Throughput 18.0726 MB/sec (NB=22.5907 MB/sec 180.726 MBit/sec)
Throughput 18.2769 MB/sec (NB=22.8461 MB/sec 182.769 MBit/sec)
Throughput 19.152 MB/sec (NB=23.94 MB/sec 191.52 MBit/sec)
Throughput 14.2632 MB/sec (NB=17.8291 MB/sec 142.632 MBit/sec)
Throughput 20.5007 MB/sec (NB=25.6258 MB/sec 205.007 MBit/sec)
Throughput 24.9471 MB/sec (NB=31.1838 MB/sec 249.471 MBit/sec)
Throughput 20.36 MB/sec (NB=25.45 MB/sec 203.6 MBit/sec)
make -j4 bzImage 412.28s user 36.90s system 15% cpu 47:11.14 total
2.5.46:
Throughput 19.3907 MB/sec (NB=24.2383 MB/sec 193.907 MBit/sec)
Throughput 16.6765 MB/sec (NB=20.8456 MB/sec 166.765 MBit/sec)
make -j4 bzImage 412.16s user 36.92s system 83% cpu 8:55.74 total
2.5.47-mm2:
Throughput 15.0539 MB/sec (NB=18.8174 MB/sec 150.539 MBit/sec)
Throughput 21.6388 MB/sec (NB=27.0485 MB/sec 216.388 MBit/sec)
make -j4 bzImage 413.88s user 35.90s system 94% cpu 7:56.68 total - fifo_batch strikes again
It's the "doing multiple things at the same time" which gets better; the
straightline throughput of "one thing at a time" won't change much at all.
Corner cases....
Slashdot smashes Kernel Trap server. Again!
;))
There are some things which people simply have not yet noticed.
Andrea's kernel is the fastest which 2.4 has to offer; let's tickle
its weak spots:
Run mke2fs against six disks at the same time, mem=1G:
2.4.20-rc1aa1:
0.04s user 13.16s system 51% cpu 25.782 total
0.05s user 31.53s system 63% cpu 49.542 total
0.05s user 29.04s system 58% cpu 49.544 total
0.05s user 31.07s system 62% cpu 50.017 total
0.06s user 29.80s system 58% cpu 50.983 total
0.06s user 23.30s system 43% cpu 53.214 total
2.5.47-mm2:
0.04s user 2.94s system 48% cpu 6.168 total
0.04s user 2.89s system 39% cpu 7.473 total
0.05s user 3.00s system 37% cpu 8.152 total
0.06s user 4.33s system 43% cpu 9.992 total
0.06s user 4.35s system 42% cpu 10.484 total
0.04s user 4.32s system 32% cpu 13.415 total
Write six 4G files to six disks in parallel, mem=1G:
2.4.20-rc1aa1:
0.01s user 63.17s system 7% cpu 13:53.26 total
0.05s user 63.43s system 7% cpu 14:07.17 total
0.03s user 65.94s system 7% cpu 14:36.25 total
0.01s user 66.29s system 7% cpu 14:38.01 total
0.08s user 63.79s system 7% cpu 14:45.09 total
0.09s user 65.22s system 7% cpu 14:46.95 total
2.5.47-mm2:
0.03s user 53.95s system 39% cpu 2:18.27 total
0.03s user 58.11s system 30% cpu 3:08.23 total
0.02s user 57.43s system 30% cpu 3:08.47 total
0.03s user 54.73s system 23% cpu 3:52.43 total
0.03s user 54.72s system 23% cpu 3:53.22 total
0.03s user 46.14s system 14% cpu 5:29.71 total
Compile a kernel while running `while true;do;./dbench 32;done' against
the same disk. mem=128m:
2.4.20-rc1aa1:
Throughput 17.7491 MB/sec (NB=22.1863 MB/sec 177.491 MBit/sec)
Throughput 16.6311 MB/sec (NB=20.7888 MB/sec 166.311 MBit/sec)
Throughput 17.0409 MB/sec (NB=21.3012 MB/sec 170.409 MBit/sec)
Throughput 17.4876 MB/sec (NB=21.8595 MB/sec 174.876 MBit/sec)
Throughput 15.3017 MB/sec (NB=19.1271 MB/sec 153.017 MBit/sec)
Throughput 18.0726 MB/sec (NB=22.5907 MB/sec 180.726 MBit/sec)
Throughput 18.2769 MB/sec (NB=22.8461 MB/sec 182.769 MBit/sec)
Throughput 19.152 MB/sec (NB=23.94 MB/sec 191.52 MBit/sec)
Throughput 14.2632 MB/sec (NB=17.8291 MB/sec 142.632 MBit/sec)
Throughput 20.5007 MB/sec (NB=25.6258 MB/sec 205.007 MBit/sec)
Throughput 24.9471 MB/sec (NB=31.1838 MB/sec 249.471 MBit/sec)
Throughput 20.36 MB/sec (NB=25.45 MB/sec 203.6 MBit/sec)
make -j4 bzImage 412.28s user 36.90s system 15% cpu 47:11.14 total
2.5.46:
Throughput 19.3907 MB/sec (NB=24.2383 MB/sec 193.907 MBit/sec)
Throughput 16.6765 MB/sec (NB=20.8456 MB/sec 166.765 MBit/sec)
make -j4 bzImage 412.16s user 36.92s system 83% cpu 8:55.74 total
2.5.47-mm2:
Throughput 15.0539 MB/sec (NB=18.8174 MB/sec 150.539 MBit/sec)
Throughput 21.6388 MB/sec (NB=27.0485 MB/sec 216.388 MBit/sec)
make -j4 bzImage 413.88s user 35.90s system 94% cpu 7:56.68 total
So here's the text.......
In a reply on lkml to Aaron Lehmann's praising of the contest results of the latest 2.5-mm kernel Andrew Morton [interview] explains some of the important performance and design differences between the 2.4 stable series and the 2.5 development series accompanied by illustrating benchmarks. Most significant gains can be expected at the high end such as large machines, large numbers of threads, large disks, large amounts of memory etc. [...] For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. [...] Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster. From: Aaron Lehmann To: linux-kernel Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest Date: Mon Nov 11 2002 - 18:04:53 AKST On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote: > Here are the latest contest (http://contest.kolivas.net) benchmarks up to and > including 2.5.47. This is just great to see. Most previous contest runs made me cringe when I saw how -mm and recent 2.5 kernels were faring, but it looks like Andrew has done something right in 2.5.47-mm1. I hope the appropriate get merged so that 2.6.0 has stunning performance across the board. From: Andrew Morton To: linux-kernel mailing list Subject: Re: [BENCHMARK] 2.5.47{-mm1} with contest Date: Tue Nov 12 2002 - 02:04:23 AKST Aaron Lehmann wrote: > > On Tue, Nov 12, 2002 at 10:31:38AM +1100, Con Kolivas wrote: > > Here are the latest contest (http://contest.kolivas.net) benchmarks up to and > > including 2.5.47. > > This is just great to see. Most previous contest runs made me cringe > when I saw how -mm and recent 2.5 kernels were faring, but it looks > like Andrew has done something right in 2.5.47-mm1. I hope the > appropriate get merged so that 2.6.0 has stunning performance across > the board. Tuning of 2.5 has really hardly started. In some ways, it should be tested against 2.3.99 (well, not really, but...) It will never be stunningly better than 2.4 for normal workloads on normal machines, because 2.4 just ain't that bad. What is being addressed in 2.5 is the areas where 2.4 fell down: large machines, large numbers of threads, large disks, large amounts of memory, etc. There have been really big gains in that area. For the uniprocessors and small servers, there will be significant gains in some corner cases. And some losses. Quite a lot of work has gone into "fairness" issues: allowing tasks to make equal progress when the machine is under load. Not stalling tasks for unreasonable amounts of time, etc. Simple operations such as copying a forest of files from one part of the disk to another have taken a bit of a hit from this. (But copying them to another disk got better). Generally, 2.6 should be "nicer to use" on the desktop. But not appreciably faster. Significantly slower when there are several processes causing a lot of swapout. That is one area where fairness really hurts throughput. The old `make -j30 bzImage' with mem=128M takes 1.5x as long with 2.5. Because everyone makes equal progress. Most of the VM gains involve situations where there are large amounts of dirty data in the machine. This has always been a big problem for Linux, and I think we've largely got it under control now. There are still a few issues in the page reclaim code wrt this, but they're fairly obscure (I'm the only person who has noticed them
What the hell is this?? Your comment has too few characters per line (currently 38.6).
Doing assembly dumps on object code isn't terribly exciting. Doing this on trojans is perhaps even less so, even on Linux.
But, referring to doing this on native Windows code is not a good idea at all. Remember the EULA, simply having the Windows code on your disk constitutes acceptance of the EULA and reverse engineering by assembly dumps is explicitly defined as a violation of the EULA. In other words you are setting yourself in a position for major legal problems.
The only legitimate way to reverse engineer software is the method used by the Samba team. You must look at the input and look at the output and then determine your OWN method of achieving the same result.
This is the only legal way to do it. If you even glance at an assembly dump of the actual software, you are no longer virgin. Thus ANYTHING that you produce afterwards the even vaguely resembles the operation of the original software will place you in a losing position, legally.
Avoid assembly dumps of MS code!
As Cliff stated, you don't want to burn any bridges. Even those that you desperately want to burn, should be maintained. You never know who or when you will need someone in your future.
At the same time do not let anyone take advantage of you. You said that this was a former employer. This immediately releases you of ANY responsibility or obligation to them, you don't work for them anymore!
This could be a slightly grey area if you had recently, within a couple of weeks, left the job on your own accord and the failed system was your responsibility. But, even here there is no REAL responsibility, simply a matter of your own moral feelings on the matter. But, you stated that this emplyer became former 5 months ago. No matter what the reason for your departure there is absolutely positively no obligation on your part after this period of time.
The next time you are presented with this situation, stop for a moment and think. First what are your feelings? Simply, do you want to do it or not? Secondly, review your current situation. Are you working somewhere else and are really to busy to spare the time or perhaps it may be a conflict of interest if you are working for a competitor now. In your case, you stated that you are unemployed so these would not be a problem here. You have time and there are no conflicts.
So, having decided that you can do it and that you want to do it, the next step is to specify the terms of a short term contract. Yes, contract. Even if it is only verbal you are still entering into a contract with this company. You need to come to an agreement on the type and amount of reimbursement for your time. You also need to agree to a set of milestones, if you will, that will be used to determine the successful completion of the contract.
For example, the situation that you related should have gone like this... Yes Jane, I am confident that I can resolve your problem. As it happens I am available to do consulting work of this kind, right now. My fee is $100 per hour for this type of work and I do charge travel time at that rate.
Janes response will likely be: "Wow, I don't want to pay that much." To which you should reply: "I certainly understand that but, that is a competitive rate in the industry and it is what I charge. I suspect from what you have told me so far that it might take 6 hours to fix your problem." At that point she will either say flat out no, and move on to another consultant, or she will say that she has to get back to you. This will give her time to get approval for the expenditure and also get estimates from other consultants. If she calls back make sure that she is in agreement to pay you for fixing the problem and that she fully expects to pay at LEAST $600.
Of course, Jane might decide to try to bully you when you advise her of your rate. She might say something like: "What?? $100 an hour?? No way. You built this system and it has never be right! It's your responsibility and I expect you to fix it immediately! I'm not paying you to fix your own mistakes. In fact, if you don't fix it, we will probably sue you!"
Your response to this should be: "I understand that you feel it is my responsibility, Jane. However, I do not work for you anymore therefore, it is NOT my responsibility. I'm sorry that you feel that I did not build the system properly however, the fact that it has worked for several months without me suggests that it was in fact, working properly. Even so, it is still not my responsibility anymore. But, I would be glad to look at it for you, as a consultant.
Finally, if Jane says that they are going to sue you, end the discussioin right then and there. Say: "I am afraid that, under the circumstances, I will not be able to assist you with your problem. I wish you the best of luck with it. Thank you for calling." click.... Naturally, this assumes that you do indeed not have any contractual liability to the problem. In your specific case, after 5 months, you didn't.