I just got an Acer Aspire 5672 a couple of weeks ago. This laptop includes a ATI Radeon Mobility x1400 graphics controller, and an Intel Pro Wireless 3945 Wifi setup. I'm running Gentoo linux on it, but theoretically this could work on any recent distribution given enough effort/determination.
The latest proprietary ATI drivers support the Mobility x1400 chipset with 3D acceleration. This is a recent development, as the drivers were released sometime in mid April. It took some finagling with my kernel configuration to get it running. IIRC, I had to enable AGPGART for ATI Radeon chipsets, and DRI/DRM in the kernel config. As for the drivers themselves, there's an ebuild that takes care of it (ati-drivers -- currently masked).
ATI also provides a distro-independent download from their web page, but I had trouble getting their package to work properly. YMMV
The Intel 3945 wireless adapter took a little bit of work, but it's running now. Intel has released a driver that seems to work nicely, but it involved a little bit more kernel wrestling, as it requires certain kernel settings to work. Most notably, it requires replacing the 802.11 code in the kernel with an upgraded / external version. With Gentoo, there's an ebuild that walks you through the whole thing (net-wireless/ipw3945 I think).
The in-kernel bluetooth support seems to work fine -- I can't remember the kernel module I had to use, but it was pretty easy to use
The Intel HD Audio works fine, but for some reason, the mixer controls are on a different audio device from the DSP. My sound was playing but ridiculously quiet until I figured this out.
The SATA hard disk works fine
I haven't touched the 5-in-1 flash media slot yet
I haven't attempted to configure ACPI yet either
I haven't figured out how to use the camera above the screen. It's an "Acer Orbicam", but according to lsusb, it's made by Logitech. I haven't yet found a USB webcam driver that works properly with it.
OK, this was initially just going to be a post about the intel 3945 WiFi and ATI Radeon x1400, but I've actually run down the features for the whole laptop.
For those who were wondering, yes, the Acer 5672 works fine with Linux given enough time/effort. Just be prepared to hit Google quite a bit, as a lot of it is still fairly cutting edge. On the whole, I'm quite happy with how it's running now, but it was by no means instant gratification.
Maybe you need to spend just a little more time in the real world. "Don't screw around with all of that stuff, it's taken care of for you at a lower level" is a wonderful philosophy, and it's useful most of the time, but when you're working on something big and important where performance sells, then mucking around with every last underlying piece of the system, whether it's polite or not, is just what you do.
How much performance gain are you going to realize? 100%? 50%? 5%? 0.5%?
One of the nice things about abstractions is that they make it easier for you to write maintainable code. In the real world, delivery dates count, and abstractions help you meet deadlines.
It's not worth spending months on hand-tuning a rendering engine if it's more cost-effective to simply throw more expensive/faster hardware at the problem. If your rendering engine is going to take an extra three months to hit the market because you've decided to hand code parts in assembly, your customers may have already walked by the time you finish--especially if they need to start rendering today. In the mean time, the three months you spend hand-tuning your rendering engine might be better spent on adding features for the next version.
Specializing your codebase for a particular platform (OS/hardware) makes sense if you need to squeeze out every last ounce of performance, but in the real world it doesn't happen in a vacuum. Specialize too much for a platform, and you might quickly find yourself locked in to using an obsolete platform. There's a tradeoff between long-term maintainability/portability and short-term performance. The more dependent your code is on a particular platform today, the more it's going to cost you when your customer wants to change platforms down the road.
Platform changes do happen. If your customers want to migrate to a new platform and you can't migrate with them, they're going to look for alternatives.
For example, if you find that you get performance boosts by using undocumented function calls in a particular version of Windows, you run the risk that those functions will change or disappear between versions--thereby breaking your application. If your TurboWord2000 doesn't run on Windows XP because of such a change, your customers aren't going to wait around for you to fix your program.
Suppose you have a CPU intensive server application written in C / C++. For performance, you decide to rewrite some of the most CPU intensive code with hand-coded inline x86 assembly. Because instruction ordering can play a big part in software performance, your hand-coded assembly might run very well on an Athlon, but then run very poorly on a Pentium4 if your instruction ordering results in a high number of pipeline flushes / stalls. Some compilers generate several CPU-specific branches of code because of this--are you willing to go to this effort? And needless to say, your code won't run on anything other than x86 hardware (unless you're willing to maintain parallel versions).
Tuning your product to work well on a particular platform makes sense, but after a point, the performance gains you'll realize are likely minimal given the tuning effort on your part. After a point, it's not worth the cost, time, or platform-dependency risks. Your time is precious, and life is short. As much as it pains me to say this, it's often more cost-effective to just throw hardware/money at the problem.
Redundancy doesn't make the individual low quality systems any more reliable, but it does help out the reliability of the system as a whole.
Let's say you have a server which is 90% reliable (or unavailable 10% of the time).
If you have two such servers working in redundant cluster, then you will only have an outage when both servers are down (p(failure) = 0.1 * 0.1 = 0.01). In other words, you've gone to 99% availability.
By adding a third server, you go to 99.9% availability (etc).
Clustering *does* add complexity though--especially when you need to replicate application state across your cluster so that it has the appearance of being a single system. In some cases, you're better off with a single reliable host such as a VAX. But if you don't need a single system image, a cluster of disposable boxes makes good economic sense.
I remember a friend at school got his hands on an OS/2 Warp Performance Beta CD. This was a low cost Beta program where you could run a fully functional prerelease version of OS/2 Warp 3, so you could see how well it ran even on low spec hardware.
The best part of the CD was the label. It showed a jet plane in flight, and the slogan:
"Arrive in Chicago sooner than expected!"
(at the time, Windows 95 had just been delayed yet again)
There was a version of OS/2 Warp which didn't include Windows -- it took advantage of the Windows 3.1 installation you already had on your computer. I think it was 'OS/2 for Windows' or 'Warp for Windows'. It came in a red box, to distinguish it from the 'full' version that came in a blue box. It was also less expensive.
If I remember, not long after Warp For Windows came out, Microsoft came out with Windows 3.11 which fixed a few bugs in 3.1. Oddly enough, it didn't work with OS/2 for Windows. I'm surprised they missed that one. <G>
(This sounds very much like our situation where I work -- in fact, I'm almost wondering if I work with this Anonymous Coward)
Anyways, open sourcing the drivers will benefit your customers, but don't expect it to be a silver bullet.
Your customers are in a competitive market and facing tight deadlines. If your driver is poorly documented and poorly supported, your customers will switch vendors long before they decide to fix your code. Fixing minor scripting errors is one thing. Fixing fundamental design flaws is quite another.
Don't expect the community to do a free code overhaul for you. Open source is driven by developers scratching their itches--whether it be a simple missing feature, or an annoying bug.
In our case, what scared us off to another vendor was the RedHat centricity of the Dialogic software. Our experience with RedHat has been that once a version becomes obsolete, it's really hard to keep up with security patches--not fun when you have a rack of 72 identical RH 6.0 telephony machines, all waiting to be rooted.
I have no doubt it would be easy to port the Dialogic system release to other Linux distributions (e.g. Gentoo, Debian) or even make it distribution-agnostic. I'm sure it all boils down to a few critical dependencies that are packaged differently between distributions (e.g. LiS, glibc, kernel version, etc). The problem is that it's not obvious where I would start, and I don't have time to really investigate. However, if this information were more readily available, it wouldn't take long for somebody to figure it out.
Open source is all about developers scratching personal itches. For me, it's getting a system release working on Gentoo. For others, it might be in building a better configurator, system alarming, or test/administrative utilities. Your main challenge will be to foster all of this, and build a community. Be very ready to help them through the initial hurdles.
One strategy might be to sponsor a group of developers who are already familiar with your products (e.g. sample hardware and solid developer support). They already know what personal itches they'd like scratched--all they need to know is where to begin.
Basically, the code was encrypted, and took steps that effectively defeated debuggers. According to the DDJ article, the code actually ran a few tests to determine if it was MS DOS or DR DOS. These tests basically crawled a few internal MS DOS data structures to determine what version of DOS was running. It was a fairly artificial test--it didn't check anything that would actually make a difference WRT compatibility.
Because of the fact they disabled debugging, encrypted the code, and used a fairly convoluted, non-obvious way of testing compatibility, it's pretty clear what Microsoft was up to.
They didn't use a very sophisticated method to determine if MS-DOS or DR-DOS was running. The fix was simple. Just lie. Perhaps the WINE folk can do the same.
It really depends what 'lie' means. In the case of DR DOS, my understanding is that they exploited some difference in how DR DOS and MS DOS implement an arcane and seldom-used system call. If they're pulling something like this with Wine, that's going to be a very tough arms race to keep up with. It's unwinnable too, depending on how far Microsoft wants to push it.
Microsoft has actually been on the losing end of this sort of thing before. Remember the great AOL/MSN Messenger interoperability battle a few years ago? Microsoft wanted to connect to AOL IM, but AOL kept blocking Microsoft. For every block AOL set up, Microsoft would figure out how to circumvent it...until finally AOL implmenented the 'nuclear option'.
Basically, AOL implemented a server-side sniffer that exploited a buffer overflow in their own IM client. MSN messenger was not bug compatible, so it didn't have this buffer overlow. They were faced with an unwelcome choice--either duplicate the same buffer overflow in MSN messenger, or concede defeat. Interoperability...or security?
Actually, it makes sense. Castle keeps were set up so that an attacker would have to climb stairs with their right side against a wall. This would make it tough for an attacker to swing a sword, since the wall would be in their way. At the same time, the right-handed defender would have no problem, since the wall was only on one side of the stairs.
The same would apply for a spiral staircase that ascended in a clockwise direction--a right-handed attacker wouldn't be able to swing a sword easily with the central post to their right side.
They're probably going to respond saying that it's an outside contractor, bla bla bla
Actually, Microsoft makes heavy use of 'temporary workers'--rather than go through the pains of actually hiring an employee, they hire contractors for extended periods of time.
Being an outside contractor to Microsoft is the next-best thing to actually being an employee.
A corporation does not totally protect its owners / employees from legal liability. Corporations do provide protection from financial risk, but they don't totally protect you from civil or criminal liability.
Corporations are legal entities, but they are unable to act on their own. Their employees and management act as agents of the corporation--they have a duty to act in ways that are in the best interest of the corporation.
If an employee, acting on behalf of the corporation, exposes the corporation to a lawsuit, then he is being negligent in his duty to the corporation--if the corporation is sued, it could in turn sue its employee to recover the damages.
You are correct. An apartment compex owner, a HOA, etc can't say you can't have a dish positioned somewhere due to how it might look. They also can not limit the number of dishes that you have installed as long as all are under the 1-meter limit.
Actually, they can request that you install your dish in a way that minimizes the aesthetic impact, but only to the extent that it does not interfere with reception.
I have a copy of 'Solid Code', also put out by Microsoft. It's actually a very sensible, no-nonsense book about writing dependable code. The book is well written full of good advice, regardless of the fact it's published by 'Microsoft Press'.
My only reservation about the book is the author's insistence on using Hungarian Notation.
In all fairness, I think there are plenty of people at Microsoft that know how to write good solid code. They probably have a few incompetent coders on staff, but I think generally their coders are very talented. They do have pretty high standards for their people.
Many of Microsoft's infamous software flaws can be traced back to their emphasis on features and ease of use, rather than quality. After all, if you ran into a bug, it was probably something you could fix by buying the next version.
Recently, they've started to focus more on quality--I hope this translates into actual results and not just lip service.
Ohm's law really only applies to linear circuits and linear elements (e.g. conductors, resistors). It doesn't apply to insulators (i.e. air) or semiconductors, which have non-linear V/I behaviour.
For an insulator such as air, you must look at its dielectric strength as well as the distance. From this, you can calculate the breakdown voltage required to generate an arc. For air, I believe it's roughly 10,000 V / inch. Of course, this depends on factors such as humidity, temperature, pressure, gas composition, etc.
If you apply a voltage below the breakdown voltage, no current flows. If you exceed the required breakdown voltage, then you get an arc. Essentially, this is a path of ionized gas, which is a very good conductor. This path is maintained as long as the voltage difference exceeds a minimum threshold (lower than the initial breakdown voltage).
After the emerge it will tell you that some files config files need to be looked at, a simple:
find/etc -iname '._cfg????_*'
Actually, you can also do:
'etc-update'
This will walk you through the config files that need to be updated, and let you decide whether you want to accept the changes wholesale, discard the changes, or manually merge them in (it will even show you the differences between old and new).
"You Red Hat guys must get sick of dependency hell..." "I'm too stupid to understand that circular dependencies can be resolved by specifying BOTH.rpms together on the command line, and that problems hardly ever occur if one uses proper Red Hat packages instead of mixing SuSE, Mandrake and Joe's Linux packages together (which the system wasn't designed for)."
Obviously, it's bad RPM Juju to mix and match RPMs from different distributions. As long as you stick with RPMs built for your specific release of RedHat, everything fits together fine. But sometimes you don't have that option.
The difference is that sooner or later, RedHat releases become obsolete, and much harder to find good RPMs for. I imagine it's pretty hard to find the latest KDE RPMs for an old Redhat 4.2 box:) I might find them on rpmfind.net, but then I also will have to manually track down a zillion dependencies, and make sure that the RPMs are all built for RH 4.2.
And it's not just old versions of RedHat. Newer versions can have the same problems. We recently installed RH ES on a 24/7 database cluster, but needed to use Postgres 7.3.x. The Redhat-supplied Postgresql was an older release, where the periodic VACUUM process would basically lock an entire table for up to an hour--in our application, that's unacceptable. We strayed from RedHat's official packages because we basically had to. We went with the PGDG RPMs compiled for our version of Enterprise Server, and they work great, but I'm dreading the day that we need the official RedHat Postgresql RPM to satisfy a dependency. RPM --nodeps --force usually works, but it's also bad RPM Juju.
With Gentoo (and Debian), you also have the best results if you stay with the packaging system. However, this much easier to do so, especially over time, because your base install never becomes obsolete. You never need to search for a package that's built for your specific release of Gentoo / Debian--if it's in the packaging system, you'll be able to install it on your machine, regardless of how long ago you did the base install.
My machine at home was originally running Gentoo 1.2, and it's been painless to keep it up to date as new packages become available.
If RedHat and the other RPM distributions were to standardize on their RPM package naming and layout, and provide an easy and reliable upgrade path between releases, that would go a long way towards getting rid of the RPM Dependency Hell problem.
Guess what, until you offer a good solution you're stuck with filters
There are several good solutions, none of which require library-wide filters. For example:
Put the internet terminals in a very visible / high traffic location so that it's easy to monitor them for abuse.
Maintain a separate set of computers for children, which *do* have filtering software.
I don't want my kids looking at Ron Jeremy on a libraries PC.
I'm sorry.... *whose* kids? If you don't want your kids surfing porn, then that's *your* responsibility as a parent to instill the right moral character in them. Don't you trust your kid to make the right decisions, even when you're not around?
If surfing porn at the library is okay, then why aren't they fighting the right to stock Hustler?
I understand that some libraries actually *do* stock magazines like Hustler. You probably have to approach the circulation desk if you want to read it though.
But let's talk magazines--if libraries shouldn't carry Hustler, what about these?
Men's Health
Cosmopolitan
Vogue
Seventeen
Maxim
National Geographic
American Rifleman
Soldier of Fortune
Which of these should the library not be allowed to stock? Why not?
Oh, how did you figure that braking and releasing would ever be better then constant braking. I mean if the wheel isnâ(TM)t moving wonâ(TM)t it have more friction then if the wheel is allowed to rotate, even a little?
Most of your braking friction comes from your brakes and pads, not your tires.
When you lock your wheels, the only thing generating friction is your tire skidding on pavement (or whatever surface you're driving on). This generates far less friction than what you can get between your brake pads and rotors, leading to a longer stopping distance. Additionally, once your wheels are sliding, you can't steer to avoid anything.
The ideal situation is to get your brakes on the *threshold* of locking up--i.e. using the maximum braking force that doesn't cause your brakes to lock. Professional drivers can do this without problem, but most average drivers have trouble, especially in an emergency situation. The usual reaction is to panic, lock the wheels, and lose control of the car.
The benefit of ABS is that it approximates threshold braking very closely, while requiring far less skill from the driver. Additionally, your wheels are still turning, so you are able to steer at the same time. In a panic stop, I doubt most drivers would even remember to use threshold braking, let alone do it effectively.
There *are* situations where a four wheel lockup will be your best option, but they're the exception. For example, on snow or gravel, a locked tire will build up a wedge of material in front of it, that will help stop you. Considering that the original question came from a Canadian driving guide, I imagine this is what they were thinking.
In most situations though, ABS will get you shorter stopping distances than manual braking will.
I agree with you, that the 'noatime' optimization could also play a role here. It may turn out to be a significant factor. I didn't mean to discount it by any means.
I found it interesting that as the number of CPUs increased, the performance gap seemed to decrease--Linux got more of a 'boost' than Windows by adding CPUs.
Finally, the performance vs. connected clients graphs are very interesting too. The Windows system has a higher performance overall, but this tends to fall off as clients are added. In contrast, the Linux server seems to have fairly flat performance curves--extra clients didn't have quite the same impact on Linux as they did on the Windows side. I'm not quite sure how to interpret that, but it's interesting...
Re:I'm always skeptical when someone tries to sell
on
What's Microsoft Up To?
·
· Score: 3, Interesting
They also set up the servers with one NIC for each CPU. The uniprocessor box had one ethernet card, while the 8-way box had eight ethernet cards. If I remember, this is similar to the Mindcraft tests, where they tested file and web serving performance on systems having four ethernet adapters. I wouldn't call this a normal real-world configuration.
Maybe there are some cases where a fileserver is connected to several separate ethernet networks, but in my mind, that's an unusual configuration. I wonder if it's a contrived test, designed to exploit a difference between the Linux and Windows kernel, especially in handling multi-cpu / multi-NIC machines.
Perhaps Windows gets a larger boost than Linux from CPU affinity, especially on the chosen hardware (e.g. the IRQs from each ethernet card are dedicated to a specific CPU). There may be some room for improvement. It might even be that Linux doesn't fully support the chipset or APIC on that particular server, and therefore can't make the same optimization.
I understand that we are closing in on the "theoretical optimal limit". SO the Evolution of algorithms is reaching its close... so we need an innovative change. a Revolutionary search algorithm. A new theory.
I don't understand. If we're already near the theoretical optimal limit, *how* are we going to find a revolutionary search algorithm?
Slashdot Mirror
OK, this was initially just going to be a post about the intel 3945 WiFi and ATI Radeon x1400, but I've actually run down the features for the whole laptop.
For those who were wondering, yes, the Acer 5672 works fine with Linux given enough time/effort. Just be prepared to hit Google quite a bit, as a lot of it is still fairly cutting edge. On the whole, I'm quite happy with how it's running now, but it was by no means instant gratification.
Replaceable you must be, or promoted you won't.
Maybe you need to spend just a little more time in the real world. "Don't screw around with all of that stuff, it's taken care of for you at a lower level" is a wonderful philosophy, and it's useful most of the time, but when you're working on something big and important where performance sells, then mucking around with every last underlying piece of the system, whether it's polite or not, is just what you do.
How much performance gain are you going to realize? 100%? 50%? 5%? 0.5%?
One of the nice things about abstractions is that they make it easier for you to write maintainable code. In the real world, delivery dates count, and abstractions help you meet deadlines.
It's not worth spending months on hand-tuning a rendering engine if it's more cost-effective to simply throw more expensive/faster hardware at the problem. If your rendering engine is going to take an extra three months to hit the market because you've decided to hand code parts in assembly, your customers may have already walked by the time you finish--especially if they need to start rendering today. In the mean time, the three months you spend hand-tuning your rendering engine might be better spent on adding features for the next version.
Specializing your codebase for a particular platform (OS/hardware) makes sense if you need to squeeze out every last ounce of performance, but in the real world it doesn't happen in a vacuum. Specialize too much for a platform, and you might quickly find yourself locked in to using an obsolete platform. There's a tradeoff between long-term maintainability/portability and short-term performance. The more dependent your code is on a particular platform today, the more it's going to cost you when your customer wants to change platforms down the road.
Platform changes do happen. If your customers want to migrate to a new platform and you can't migrate with them, they're going to look for alternatives.
For example, if you find that you get performance boosts by using undocumented function calls in a particular version of Windows, you run the risk that those functions will change or disappear between versions--thereby breaking your application. If your TurboWord2000 doesn't run on Windows XP because of such a change, your customers aren't going to wait around for you to fix your program.
Suppose you have a CPU intensive server application written in C / C++. For performance, you decide to rewrite some of the most CPU intensive code with hand-coded inline x86 assembly. Because instruction ordering can play a big part in software performance, your hand-coded assembly might run very well on an Athlon, but then run very poorly on a Pentium4 if your instruction ordering results in a high number of pipeline flushes / stalls. Some compilers generate several CPU-specific branches of code because of this--are you willing to go to this effort? And needless to say, your code won't run on anything other than x86 hardware (unless you're willing to maintain parallel versions).
Tuning your product to work well on a particular platform makes sense, but after a point, the performance gains you'll realize are likely minimal given the tuning effort on your part. After a point, it's not worth the cost, time, or platform-dependency risks. Your time is precious, and life is short. As much as it pains me to say this, it's often more cost-effective to just throw hardware/money at the problem.
One I can now look back on and laugh at:
gcc mtp.c -o mtp.c
(after having spent a lot of time debugging mtp.c, and working too quickly to make a good backup).
Redundancy doesn't make the individual low quality systems any more reliable, but it does help out the reliability of the system as a whole.
Let's say you have a server which is 90% reliable (or unavailable 10% of the time).
If you have two such servers working in redundant cluster, then you will only have an outage when both servers are down (p(failure) = 0.1 * 0.1 = 0.01). In other words, you've gone to 99% availability.
By adding a third server, you go to 99.9% availability (etc).
Clustering *does* add complexity though--especially when you need to replicate application state across your cluster so that it has the appearance of being a single system. In some cases, you're better off with a single reliable host such as a VAX. But if you don't need a single system image, a cluster of disposable boxes makes good economic sense.
I remember a friend at school got his hands on an OS/2 Warp Performance Beta CD. This was a low cost Beta program where you could run a fully functional prerelease version of OS/2 Warp 3, so you could see how well it ran even on low spec hardware.
The best part of the CD was the label. It showed a jet plane in flight, and the slogan:
"Arrive in Chicago sooner than expected!"
(at the time, Windows 95 had just been delayed yet again)
There was a version of OS/2 Warp which didn't include Windows -- it took advantage of the Windows 3.1 installation you already had on your computer. I think it was 'OS/2 for Windows' or 'Warp for Windows'. It came in a red box, to distinguish it from the 'full' version that came in a blue box. It was also less expensive.
If I remember, not long after Warp For Windows came out, Microsoft came out with Windows 3.11 which fixed a few bugs in 3.1. Oddly enough, it didn't work with OS/2 for Windows. I'm surprised they missed that one. <G>
(This sounds very much like our situation where I work -- in fact, I'm almost wondering if I work with this Anonymous Coward)
Anyways, open sourcing the drivers will benefit your customers, but don't expect it to be a silver bullet.
Your customers are in a competitive market and facing tight deadlines. If your driver is poorly documented and poorly supported, your customers will switch vendors long before they decide to fix your code. Fixing minor scripting errors is one thing. Fixing fundamental design flaws is quite another.
Don't expect the community to do a free code overhaul for you. Open source is driven by developers scratching their itches--whether it be a simple missing feature, or an annoying bug.
In our case, what scared us off to another vendor was the RedHat centricity of the Dialogic software. Our experience with RedHat has been that once a version becomes obsolete, it's really hard to keep up with security patches--not fun when you have a rack of 72 identical RH 6.0 telephony machines, all waiting to be rooted.
I have no doubt it would be easy to port the Dialogic system release to other Linux distributions (e.g. Gentoo, Debian) or even make it distribution-agnostic. I'm sure it all boils down to a few critical dependencies that are packaged differently between distributions (e.g. LiS, glibc, kernel version, etc). The problem is that it's not obvious where I would start, and I don't have time to really investigate. However, if this information were more readily available, it wouldn't take long for somebody to figure it out.
Open source is all about developers scratching personal itches. For me, it's getting a system release working on Gentoo. For others, it might be in building a better configurator, system alarming, or test/administrative utilities. Your main challenge will be to foster all of this, and build a community. Be very ready to help them through the initial hurdles.
One strategy might be to sponsor a group of developers who are already familiar with your products (e.g. sample hardware and solid developer support). They already know what personal itches they'd like scratched--all they need to know is where to begin.
There's a really good description of the AARD code on Dr Dobb's Journal.
http://www.ddj.com/documents/s=1030/ddj9309d/
Basically, the code was encrypted, and took steps that effectively defeated debuggers. According to the DDJ article, the code actually ran a few tests to determine if it was MS DOS or DR DOS. These tests basically crawled a few internal MS DOS data structures to determine what version of DOS was running. It was a fairly artificial test--it didn't check anything that would actually make a difference WRT compatibility.
Because of the fact they disabled debugging, encrypted the code, and used a fairly convoluted, non-obvious way of testing compatibility, it's pretty clear what Microsoft was up to.
They didn't use a very sophisticated method to determine if MS-DOS or DR-DOS was running. The fix was simple. Just lie. Perhaps the WINE folk can do the same.
It really depends what 'lie' means. In the case of DR DOS, my understanding is that they exploited some difference in how DR DOS and MS DOS implement an arcane and seldom-used system call. If they're pulling something like this with Wine, that's going to be a very tough arms race to keep up with. It's unwinnable too, depending on how far Microsoft wants to push it.
Microsoft has actually been on the losing end of this sort of thing before. Remember the great AOL/MSN Messenger interoperability battle a few years ago? Microsoft wanted to connect to AOL IM, but AOL kept blocking Microsoft. For every block AOL set up, Microsoft would figure out how to circumvent it...until finally AOL implmenented the 'nuclear option'.
Basically, AOL implemented a server-side sniffer that exploited a buffer overflow in their own IM client. MSN messenger was not bug compatible, so it didn't have this buffer overlow. They were faced with an unwelcome choice--either duplicate the same buffer overflow in MSN messenger, or concede defeat. Interoperability...or security?
Actually, it makes sense. Castle keeps were set up so that an attacker would have to climb stairs with their right side against a wall. This would make it tough for an attacker to swing a sword, since the wall would be in their way. At the same time, the right-handed defender would have no problem, since the wall was only on one side of the stairs.
The same would apply for a spiral staircase that ascended in a clockwise direction--a right-handed attacker wouldn't be able to swing a sword easily with the central post to their right side.
They're probably going to respond saying that it's an outside contractor, bla bla bla
Actually, Microsoft makes heavy use of 'temporary workers'--rather than go through the pains of actually hiring an employee, they hire contractors for extended periods of time.
Being an outside contractor to Microsoft is the next-best thing to actually being an employee.
A corporation does not totally protect its owners / employees from legal liability. Corporations do provide protection from financial risk, but they don't totally protect you from civil or criminal liability.
Corporations are legal entities, but they are unable to act on their own. Their employees and management act as agents of the corporation--they have a duty to act in ways that are in the best interest of the corporation.
If an employee, acting on behalf of the corporation, exposes the corporation to a lawsuit, then he is being negligent in his duty to the corporation--if the corporation is sued, it could in turn sue its employee to recover the damages.
(note: IANAL)
You are correct. An apartment compex owner, a HOA, etc can't say you can't have a dish positioned somewhere due to how it might look. They also can not limit the number of dishes that you have installed as long as all are under the 1-meter limit.
Actually, they can request that you install your dish in a way that minimizes the aesthetic impact, but only to the extent that it does not interfere with reception.
I have a copy of 'Solid Code', also put out by Microsoft. It's actually a very sensible, no-nonsense book about writing dependable code. The book is well written full of good advice, regardless of the fact it's published by 'Microsoft Press'.
My only reservation about the book is the author's insistence on using Hungarian Notation.
In all fairness, I think there are plenty of people at Microsoft that know how to write good solid code. They probably have a few incompetent coders on staff, but I think generally their coders are very talented. They do have pretty high standards for their people.
Many of Microsoft's infamous software flaws can be traced back to their emphasis on features and ease of use, rather than quality. After all, if you ran into a bug, it was probably something you could fix by buying the next version.
Recently, they've started to focus more on quality--I hope this translates into actual results and not just lip service.
Ohm's law really only applies to linear circuits and linear elements (e.g. conductors, resistors). It doesn't apply to insulators (i.e. air) or semiconductors, which have non-linear V/I behaviour.
m l
For an insulator such as air, you must look at its dielectric strength as well as the distance. From this, you can calculate the breakdown voltage required to generate an arc. For air, I believe it's roughly 10,000 V / inch. Of course, this depends on factors such as humidity, temperature, pressure, gas composition, etc.
If you apply a voltage below the breakdown voltage, no current flows. If you exceed the required breakdown voltage, then you get an arc. Essentially, this is a path of ionized gas, which is a very good conductor. This path is maintained as long as the voltage difference exceeds a minimum threshold (lower than the initial breakdown voltage).
For more info about nonlinear conduction: http://www.allaboutcircuits.com/vol_1/chpt_2/5.ht
After the emerge it will tell you that some files config files need to be looked at, a simple:
/etc -iname '._cfg????_*'
find
Actually, you can also do:
'etc-update'
This will walk you through the config files that need to be updated, and let you decide whether you want to accept the changes wholesale, discard the changes, or manually merge them in (it will even show you the differences between old and new).
"You Red Hat guys must get sick of dependency hell..." .rpms together on the command line, and that problems hardly ever occur if one uses proper Red Hat packages instead of mixing SuSE, Mandrake and Joe's Linux packages together (which the system wasn't designed for)."
:) I might find them on rpmfind.net, but then I also will have to manually track down a zillion dependencies, and make sure that the RPMs are all built for RH 4.2.
"I'm too stupid to understand that circular dependencies can be resolved by specifying BOTH
Obviously, it's bad RPM Juju to mix and match RPMs from different distributions. As long as you stick with RPMs built for your specific release of RedHat, everything fits together fine. But sometimes you don't have that option.
The difference is that sooner or later, RedHat releases become obsolete, and much harder to find good RPMs for. I imagine it's pretty hard to find the latest KDE RPMs for an old Redhat 4.2 box
And it's not just old versions of RedHat. Newer versions can have the same problems. We recently installed RH ES on a 24/7 database cluster, but needed to use Postgres 7.3.x. The Redhat-supplied Postgresql was an older release, where the periodic VACUUM process would basically lock an entire table for up to an hour--in our application, that's unacceptable. We strayed from RedHat's official packages because we basically had to. We went with the PGDG RPMs compiled for our version of Enterprise Server, and they work great, but I'm dreading the day that we need the official RedHat Postgresql RPM to satisfy a dependency. RPM --nodeps --force usually works, but it's also bad RPM Juju.
With Gentoo (and Debian), you also have the best results if you stay with the packaging system. However, this much easier to do so, especially over time, because your base install never becomes obsolete. You never need to search for a package that's built for your specific release of Gentoo / Debian--if it's in the packaging system, you'll be able to install it on your machine, regardless of how long ago you did the base install.
My machine at home was originally running Gentoo 1.2, and it's been painless to keep it up to date as new packages become available.
If RedHat and the other RPM distributions were to standardize on their RPM package naming and layout, and provide an easy and reliable upgrade path between releases, that would go a long way towards getting rid of the RPM Dependency Hell problem.
Now, when you search for AXA, you get the following result at the top of the page, as related news:
....priceless
News results for axa - View all the latest headlines
AXA sues Google over AdWords - Slashdot - 1 hour ago
They wouldn't be traffic jams anymore.
/karma to burn
They'd be rolling Beowulf clusters.
There are several good solutions, none of which require library-wide filters. For example:
I don't want my kids looking at Ron Jeremy on a libraries PC.
I'm sorry.... *whose* kids? If you don't want your kids surfing porn, then that's *your* responsibility as a parent to instill the right moral character in them. Don't you trust your kid to make the right decisions, even when you're not around?
If surfing porn at the library is okay, then why aren't they fighting the right to stock Hustler?
I understand that some libraries actually *do* stock magazines like Hustler. You probably have to approach the circulation desk if you want to read it though.
But let's talk magazines--if libraries shouldn't carry Hustler, what about these?
- Men's Health
- Cosmopolitan
- Vogue
- Seventeen
- Maxim
- National Geographic
- American Rifleman
- Soldier of Fortune
Which of these should the library not be allowed to stock? Why not?Oh, how did you figure that braking and releasing would ever be better then constant braking. I mean if the wheel isnâ(TM)t moving wonâ(TM)t it have more friction then if the wheel is allowed to rotate, even a little?
Most of your braking friction comes from your brakes and pads, not your tires.
When you lock your wheels, the only thing generating friction is your tire skidding on pavement (or whatever surface you're driving on). This generates far less friction than what you can get between your brake pads and rotors, leading to a longer stopping distance. Additionally, once your wheels are sliding, you can't steer to avoid anything.
The ideal situation is to get your brakes on the *threshold* of locking up--i.e. using the maximum braking force that doesn't cause your brakes to lock. Professional drivers can do this without problem, but most average drivers have trouble, especially in an emergency situation. The usual reaction is to panic, lock the wheels, and lose control of the car.
The benefit of ABS is that it approximates threshold braking very closely, while requiring far less skill from the driver. Additionally, your wheels are still turning, so you are able to steer at the same time. In a panic stop, I doubt most drivers would even remember to use threshold braking, let alone do it effectively.
There *are* situations where a four wheel lockup will be your best option, but they're the exception. For example, on snow or gravel, a locked tire will build up a wedge of material in front of it, that will help stop you. Considering that the original question came from a Canadian driving guide, I imagine this is what they were thinking.
In most situations though, ABS will get you shorter stopping distances than manual braking will.
I agree with you, that the 'noatime' optimization could also play a role here. It may turn out to be a significant factor. I didn't mean to discount it by any means.
I found it interesting that as the number of CPUs increased, the performance gap seemed to decrease--Linux got more of a 'boost' than Windows by adding CPUs.
Finally, the performance vs. connected clients graphs are very interesting too. The Windows system has a higher performance overall, but this tends to fall off as clients are added. In contrast, the Linux server seems to have fairly flat performance curves--extra clients didn't have quite the same impact on Linux as they did on the Windows side. I'm not quite sure how to interpret that, but it's interesting...
They also set up the servers with one NIC for each CPU. The uniprocessor box had one ethernet card, while the 8-way box had eight ethernet cards. If I remember, this is similar to the Mindcraft tests, where they tested file and web serving performance on systems having four ethernet adapters. I wouldn't call this a normal real-world configuration.
Maybe there are some cases where a fileserver is connected to several separate ethernet networks, but in my mind, that's an unusual configuration. I wonder if it's a contrived test, designed to exploit a difference between the Linux and Windows kernel, especially in handling multi-cpu / multi-NIC machines.
Perhaps Windows gets a larger boost than Linux from CPU affinity, especially on the chosen hardware (e.g. the IRQs from each ethernet card are dedicated to a specific CPU). There may be some room for improvement. It might even be that Linux doesn't fully support the chipset or APIC on that particular server, and therefore can't make the same optimization.
I understand that we are closing in on the "theoretical optimal limit". SO the Evolution of algorithms is reaching its close... so we need an innovative change. a Revolutionary search algorithm. A new theory.
I don't understand. If we're already near the theoretical optimal limit, *how* are we going to find a revolutionary search algorithm?
Space aliens?