Not everybody particularly cares about 3D graphics performance. If you ask the common joe, they probably care more about video performance than 3D performance, as people typically watch videos on their PCs more often than play 3D games.
With that being said, Intel Integrated Graphics tend to do quite well with video, especially HD Video, rendering.
Somebody that cares about 3D graphics performance, because they want to play the latest and greatest games, is going to buy discrete graphics regardless, doesn't matter if the integrated graphics is made by nVidia, ATI, etc.
That's because the school is legally responsible for your child. For example, if there is a natural disaster, they need to account for EVERY child. What would you do if the nurse told you she thought your kid was in class, and the teacher said she thought your kid was in the nurse's office, and neither knew where your kid really was? That is why your child is supposed to report back to the classroom, then say that she needs to go to the restroom, rather then just going there on her own.
That's how you are supposed to use certificates. It's only as secure as your weakest link. In this case, how you provision your root of trust. That's why every client implementation ships with a handful of preinstalled root of trust.
That way when you need to install another trusted chain, you have something to bootstrap it with... That way if you do business with say, "uTorrent", you don't have to physically swap anything with uTorrent directly, you both can choose to bootstrap trust with one of the preinstalled trusted roots, such as Verisign. Then once you install other certs in this fashion, you can start using these new certs to bootstrap other relationships etc...
This is how its supposed to work. You can think of it as an external channel, but the original poster was making a different argument. One of the original replies to the poster mentioned trusted roots, which is exactly this system, but the original poster claimed even that was vulnerable to man in the middle, and only talked about needing to physically exchange keys with the intended recipient. When it became obvious that person didn't seem to understand how certs actually work, I simply explained how the trusted root system works.
If you have a compromised client that's a different story.
However, just because you obtained the software from the internet doesn't necessarily make it vulnerable to man in the middle in and of itself. If you downloaded it from some random place that you never heard of, that's different.
But lets say you get it from uTorrent. If they made it such that you have to go into a secured page on their page, then they would present you with a uTorrent cert, that is signed by a trusted root, lets say Verisign... Your browser ships with this trusted root straight from CD/DVD, OEM, etc, that you bought straight from the store.
Man in the middle may be able to fake the uTorrent site, but they wouldn't be able to fake a cert for uTorrent that is signed by one of the pre-installed trusted roots in your browser.
Now lets say they did manage to fool cert validation... All it would take is for somebody to realize this, then that "bad" cert would get added to the certificate revocation list, and the bad cert will get black listed and get flushed out the next time it tries to validate the cert.
Now I"m not trying to argue this system is perfect, I'm just saying that you make it sound like it's worthless so there is no point in using it. If the user is being a tool and just ignores any and all cert warnings, or doesn't even bother to look at the cert, that is their own fault. No different than writing their password on a piece of paper and taping it to their monitor.
Used _correctly_, this mechanism is quite secure. But if the user is a tool, or the author of said app is a tool, than all bets are off...
Sounds like you have no idea how certs actually work. Even if you man in the middle the cert, YOU STILL DO NOT HAVE THE CORRECT PRIVATE KEYS TO SIGN THE CERT. When you pass that cert to the client, its cert chain will fail validation, because your certs chain of trust is not trusted by the client.
When you man in the middle a cert, usually you use a self-signed cert, and hope the client doesn't notice.
High level example... If the client trusts the Cert Authority A, and has a cert chain saying A, B, C. Then when it recieves a cert from you, it will expect your cert D, to be signed by C, wwhich will be signed by B, which will be signed by A. If you man in the middle your own cert F, how the hell are you going to manage to get your cert chain signed by A, B, and C?
A man in the middle attack will result in your cert F, usually being signed by F, or some other authority G. Neither of which will validate against A, B, and C, so the client will reject your cert.
What certificate are you going to present to the client? If you forged the public key, the cert won't validate, because the client will detect it when it tries to validate the cert chain, as the client won't trust your root cert.
I didn't say the study was about visio or PDF, I was just using them as examples.
As far as Linux accessing NTFS... It can read from NTFS but it can't write to it... Also, most users of laptops that need long battery life are enterprise users. Many enterprises use an encrypted file system. Linux cannot read those.
I completely understand demographics, but you seem to not understand economics and ROI. Have you ever approached a company like Dell or HP and try to persuade them to support something like this? Before they give you the time of day, they will want usability studies, (and they will even conduct them on their own), and they want a monetization story to show them what the market looks like, and how they will make money on it, and how much. You have to justify every penny of extra cost to the platform. If they see that it is not worth it, they will not build it... So let me ask you again... Have you approached these OEMs? I HAVE. I know what they said.
You are acting like YOU are like the majority of people out there... But guess what, you AREN'T. Most consumer notebook's don't even leave the home. Of those, most are always tethered to A/C power. Why do you think most "long life battery" notebooks are usually in an OEM's business line of notebooks? The margins on these computers are smaller than you think. I can hardly get OEMs to agree to 50 cent increases in bill of materials for additional hardware. You think you can convince them to add an entire new platform into the notebook without a strong monetization story?
That's why I said there's better approaches. For example, simply switching the type of memory used on the system can net you a 40% power savings. You'll have an easier time trying to convince the OEM to incorporate this technology (especially if the BOM cost differential is negligible), and show that it would be a seamless integration... Versus saying that they can add $10 in BOM cost to the platform, and show that the integration wouldn't be seamless because you are dual-booting, etc, questionable access to some enterprise scenarios, but it would benefit a niche consumer market (based on usability studies conducted by the OEM to validate feasibility)... Yeah, that will be easy to do....
Why is sending emails or web surfing on a phone painful? Because of the small display? That wasn't whay I meant when I was referring to that. When I said I wouldn't want to be in that environment, I wasn't referring to the phone's environment, I was referring to the ARM environment. You can connect a 10" display to the ARM, but which app are you going to be running? Opera Mobile? That browser sucks compared to a desktop browser, doesn't matter if the screen is 2" or 10".
Integration is VERY important... So let's say you want to send email from a low power mode... What if you need to attach a visio file? Where is the file stored? In the ARM partition or the Windows partition? How you going to access the Windows partition? Ok, so let's say you managed to carve out a shared FAT volume.. What if you need to make a quick edit to that file before you send it? Which ARM app you going to use to open the attachement? What if you need to make a quick edit to a PDF file, such as change the value of one of the fields... Which version of Adobe Acrobat are you going to use on that ARM?
How do you know people would have no problem dual booting for that scenario? Did you do a usability study? We actually DID work with a company on a usability study for something similar to that, and guess what? It FAILED.
Like I said, if the primary concern is power savings, there are much better solutions than taking an entire platform (ie ARM), and wedging it into an existing platform (ie x86), and jury-riging it (ie Dual Boot) into a single device.
You can work at reducing power at the CPU, at the chipset, at the memory, etc, etc. For example, you can save lots of power by switching to a type of memory that doesn't have to be constantly refreshed, etc, etc.
The Atom runs the same OS and the same Apps as a real x86. Who cares if an Arm gets better battery life... My phone has an arm, and it gets better battery life than my notebook. But that doesn't mean I'd rather spend my day in that type of environment.
You really think the average joe will be ok with running a platform running linux as an acceptable replacement for the windows environment they are used to? Running two parallel environments that are dissimilar is asking a lot of the user.
An Atom/Hybrid device is like a gas hybrid car... Looks and feels like any other car, and the user does just fine with it, using less gas...
Using an ARM/Hybrid would be like giving a diesel powered moped with the gas car to the user, and telling them if they ride the moped they'll get much better fuel economy than a comparable Atom/Hybrid.
Sure, that's true, but the utility is not the same. In the Atom case, if the user wants to access some visio foils, he loads up Visio just like on the desktop... Of to use the car analogy, he has a big suitcase, and just tosses it in the trunk..
In the ARM case, he needs to find a compatible app, or possible recompile the App if it doesn't exist... That's like telling the user that he can't take the suitcase, but that's no problem... He can just go to the store, and buy a new suitcase that looks just like his suitcase, but has special attachments to connect to the moped.
I didn't say it couldn't be done, I even illustrated how it can be done... My point was that when you start sharing memory like that, you aren't saving any power, becuase you'll have to keep the x86 powered up to run the memory controller.
I also mentioned that two isolated environments is not a good solution, because it is not seamless. Why would I want to dual boot my laptop on two different non-compatible OSes, just to save battery life? If I'm doing simple things like email and crap where I don't need the horespower of my laptop, I won't even bother with the laptop, I'll just do it on my phone. I don't like carrying my notebook when I don't have to.
You and I can both dual boot linux or whatever OS on ARM and Windoze on x86, and use it just fine... But take Joe sixpack... He'll get mad when he tries to run WinMobile or whatever on ARM, and wonder why he can't launch Office 2007 to view a simple word document. Or get frustrated when he sees the interface and functionality for Pocket Word is vastly different from Word 2007, etc.
There is a reason Atom runs x86 instructions... It's so it can run the same OS, and run the same apps as it's big brother. Joe Sixpack will appreciate that when he sees that the same apps that run on his desktop, will also run on his netbook. It provides for a consistent user experience.
I'm just saying that there are better ways to reduce power on the platform, than to take an orthogonal platform like ARM, and try to jury-rig it in as a solution.
Doesn't matter if the atom did it in 130 seconds, because 70 seconds still sucks.
Whose going to be doing that in real life? That's like comparing which is faster at encoding h264. Doesn't matter what the results are, becuase it'll suck for both, and nobody will be doing this on a netbook in the first place.
I don't know what the hell kind of webpage they were trying to display... I have an Acer Netbook with the Atom in it, running Windows 7. It renders slashdot, ars, and even facebook, within 3 seconds or so...
The 386 was designed to co-exist with a 387 math co-processor. ARM was not designed to co-exist with an x86.
Good luck running the Windows OS on ARM. The Windows OS relies on many features of the CPU that are not present on an ARM. Unless you are going to suggest that the feature set of Windows Mobile is good enough...
Those architectures have the memory controller off chip.
The architectures where you plugged in an x86... They started with soft emulation, which is pretty slow. The add-in card allowed you to get rid of the software emulation. However, those add in x86 cards were still based on architectures where the memory controller and such were off-chip, so that the 680x0 architecture could just virtualize the memory controller (among other things)to the x86 CPU.
You can't do that with a modern x86 CPU, because there is nothing to virtualize, becuase the CPU only talks to the on-die memory controller.
In order to correctly do this today, the ARM processor will have to talk QPI/Hypertransport to the x86 to access memory as well as to maintain cache coherency. If you are going to be doing that, you aren't going to be saving any power. Plus you would really bog down the x86 CPU, becuase what if the x86 CPU needed to access a resource that was locked by the ARM processor? How many wait states are you going to have to inject for x86 to wait for the much slower ARM to satisfy a bus request?
And lets say you do it the virtual way, you still have to deal with data sharing. Apps running in a virtualized sand box will not have access to all the data/resources in your main OS. This isn't the 1990's anymore where everything can just access the same physicall address space.
It would make more sense to move to an architecture where you have something like a traditional Intel or AMD CPU, where the cores would just shut down when not in use, etc...
Having two CPUs of different architecture is ridiculous. How are you going to make that seamless? For example, how are you going to access memory from the ARM? The memory controller is in the Intel/AMD CPU. If the AMD/Intel CPU is powered down, so is the memory controller. If the memory controller is powered down, the ram won't get refreshed.
So you'll basically need an off-chip memory controller. If you do that, then all of a sudden you have even more headaches, such as trying to synchronize the caches on each core of the Intel/AMD cpu, etc. (And this is overlooking the instruction disparity)
If you are talking about having a separate operating environment/desktop/etc completely separate from the main environment, that is going to be awkward for a lot of users, as many will expect seamless integration and data sharing, etc.
Also, don't fool yourself and think that just because your hybrid is running an ARM that you will magically get all-day battery life. The CPU is not the only power drain on the system. You also have the wireless radio, the LCD display, and the graphics processor, etc.
In other words, a tool that a) accesses elements of a copyrighted work b) evades protection mechanisms to do so violates the DMCA. Maybe the issue isn't with the judge, but with the law he's interpreting.
On the same token, then every Anti-Virus program also violates the DMCA, becuase they use thread-injection to launch a thread into other application's processes so they can check for viruses, circumventing any checks that the app may have had, because the AV software now has a "rogue" thread in your app able to access its resources that the app thought was supposed to be secure.
How is not running Aero the same as the car falling apart? Vista capable, means able to run Vista, which these computers can... In fact, the Intel Chipset CAN run aero, and it did in the beta, MS just decided to make WDDM a requirement for Aero.
But that aside... How are the hardware vendors responsible for this? You guys do realize that even if you have the highest end graphics card, Aero will TURN ITSELF OFF as soon as you run any application that does overlays, right? That means i the user buys Vista with top of the line everything, then they install their media player from their capture card, it's possible that Aero will stop working.
This is why I doubt you'll get the HW vendors to take any blame, because Aero in and of itself is half baked at the software level. (At least until Windows 7, which does support overlays)
You can only work through so many nights without sleep before you finally realize you're not compensated enough (in pay, recognition, or even lack of complaints -- which == recognition in our field often). Sorry to be a whiny IT wonk, but pay alone doesn't cut it. You watch the person you made that app for take all the credit for it and you might get a ** mention in the fine print. They get promoted over and over and you get... another project.
Perhaps I'm just lucky then... I have gotten many promotions, and have been rewarded multple times for going above and beyond the call of duty. I've even been rewarded with all-expense paid vacations when my extra-efforts land business deals with other companies, etc.
Not to mention people are attacking the guy when one of his examples is someone that strolls in at 9:30 and wasn't there at 3pm!
Thank you! I should note that when I said I "often" worked till 10pm, I should point out I stayed till 10 not becuase I was asked to or expected to, it was because I wanted to, because I actually enjoy what I do and have fun with what I do. That is a quality I'm seeing less and less of...
And to some of the others... I understand that what's work is work, and you want to have a life. But we don't live in a utopia, and the world does not revolve around you. Sometimes you need to make some sacrifices to help someone out...
And I never suggested that you should work 60+ hour weeks. Everyone here works on a flex schedule, but many abuse it, like the person in my example... Comes to work at 9:30, but is not in the office at 3pm, and does not have her laptop with her. All I needed her to do was to logon on to the network and upload some files that she was SUPPOSED to have put in the repository. The files I needed were relatively small, so should only take 5 minutes. Is it too much to ask to take 5 minutes of your personal time? (Nevermind that at 3pm, she's supposed to be on company time) Is it so terrible to ask her to come into work early (and leave work early) to do the same from the office?
I was just making generalizations about some trends that I've been seeing lately, I'm not trying to offend anyone, as I know there are indeed great employees in this group as well. It's just that even when I look at my own friends that are younger and part of that generation, I can see the same traits.
For example, I'm noticing many of these people are very focused on what their immediate job requirements are, and only focus on that, and claim anything above and beyond that is out of scope, and not in their job description.
To use the same person in my previous example... On another occasion, (many actually), she would tell me (out of the blue) that my code broke from some random project and I need to fix it...
I would ask her what the problem was. She would say, "I don't know, there's a bug in your module".
I would ask, "What's the bug?" She said, "I don't know, that's not my problem, it's your code"
I'd ask her to step through the code, to give me a little more to grasp at, and it would be like pulling teeth listening to her explain it's not her job to debug my code. It's like she was doing me a favor. She came back like an hour later and told me that after debugging, she said she found where it crashed, and said I was doing something wrong. She said it happens in multiple places in my module, but it always crashed on a "malloc"...
Oh geez, after she told me that, I told her that she must be corrupting the stack frame... She said the crash was in my module, so it was my problem. She seemed offended that I was suggesting that the problem was in her module.
I decided to give her a hand, and walked to her cube, and walked through the debugger with her. I asked her if she was doing any memory manipulations prior to calling into my module... She said no...
So I launched the debugger, and looked at the memory when it crashed... (and explained everything I was doing)
I found a text string in memory that shouldn't have been in "free memory", and asked her where that string was used... Jumped to that section in her code, and within seconds, found a hefty buffer-overflow where she was improperly writing to memory without checking the bounds.
I can understand these types of mistakes, but it would've been nice if she had said that she didn't understand what was going on, or asked for help, etc.. Instead, she just blamed me for her problems. I've seen her go home early, and she would say that her program is crashing, and the bug is in so and so's module, and they are out of office, so she can't make any progress, and as a result says she's going home early.
I'm curious what your definition of "often" is in this case. While I find people across age groups that are lazy, I'm finding it far more likely with younger people these days being the worst in that they want things handed to them and want to minimize what they actually put into the job.
I noticed the same thing... Young Gen-X people seem to be the ambitious type, but the young Gen-Z people tend to expect things handed to them... I noticed that a lot, and even heard of books being published to help employers deal with these new breed of workers...
When I graduated college 10 years ago, I was one of those ambitious people... I often stayed at work till 10pm to insure our products/projects met their milestones etc...
Recently we hired new hires that are of the new generation. So far, many of these people are out the door as soon as the clock hits 5, regardless the status of their projects and when the milestones were... Even when I'm travelling on business and am halfway across the world, they don't want to take any personal time to give me a hand (even if it's to upload a project they are past due on). They didn't even bother taking their work laptops home, because they don't want to "work" outside of work.
They told me they'll upload it when they get in the office. (I called 3pm their time, so they should have been IN THE OFFICE, but they left early). I asked for it at 7am their time, but they said no. Said they'll do it when they come in at 9:30am. Of course that was useless because of the timezone difference, because the meetings would have been over by that time. Had they been in the office at 3pm, or logged in, or whatever, I would've had a full day to get the project/kinks worked out at the client site... But because of their lack of team-spirit, we had to waste the opportunity of being in Europe to test the integration on-site. The next opportunity for on-site integration testing at a different client location was 4 months away. You can guess what that did to schedules...
Especially considering the project was supposedly already done, but this person never bothered to check in their code to the source code repository so I had no access to it. The only copy was on this person's notebook, which was not with her, and not powered on, so it wasn't on the network.
When I was their age, there were times when I would log in, or be in the office from 1am to 7am just to make sure I was aligned on the same time-zone so I could work with the team remotely (budget restraints on travel)
From what I'm seeing Windows 7 isn't that much of a difference from Vista.
Actually Windows 7 is quite different from Vista. It's based on the same kernel, but there are LOTS of things that changed. I'd be more specific, but I'm under NDA. (No, I don't work for MSFT)
Wow, you really have no idea what the hell you are talking about, as the MAP does not rely on a MAF to meter fuel, nor does it need to. The ECU uses the Speed-Density algorithm to determine how much fuel to meter.
The ECU uses the MAP sensor to measure the intake pressure so that in conjunction with the temperature reading from the IAT it can determine the mass/density of the air. Based on THIS, it consults its fuel maps to determine how much fuel to meter.
Because it is measuring the pressure/density/mass of the air in the intake manifold, is why the ECU cannot be fooled by BOF valves, because the MAP will detect the drop in pressure and compensate accordingly.
And yes, you can effect engine load by modulating the gas while in gear, because you are effecting the load on the engine. My point was to compare the engine load number when you are in gear vs when you push the clutch in or when you are in neutral. It will be much lower then just idling in gear.
As for the cat, you are completely missing my point. What I meant was that it wasn't the cat's primary job to burn unburnt fuel to compensate for the ECU's doings. To oxidize HC, requires oxygen that is released from the reduction of NOx. As I said earlier, the reduction of NOx is an inefficient process. Stuff like this is why a 3-way cat requires a closed loop feedback fueling system in which the ECU can maintain a stoichiometric air/fuel mixture. (Tho the ECU can and will vary the mixture at times to insure that the NOx reduction doesn't become oxygen loaded and insuring the CO/HC oxidation stages have sufficient oxygen saturation)
I don't know about the rest of the country, but over here on the west coast, during emissions inspection, they actually put your car on a roller, and test tailpipe emissions during acceleration, deceleration, and cruise. This is how I know you'll fail if the ECU makes the mixture too rich, because on one of my cars I had a vacuum leak that was causing a rich condition on deceleration, and this was noted as the failure reason on the paperwork, stating that during deceleration, the HC output was too high most likely caused by a rich condition.
But in the end, who the hell cares? My original point was that because of tightening emissions requirements, cars these days are needing to employ deceleration fuel cut. This is a fact, and is even stated as the primary reason in the service manuals of certain makes that I mentioned much earlier.
Slashdot Mirror
Not everybody particularly cares about 3D graphics performance. If you ask the common joe, they probably care more about video performance than 3D performance, as people typically watch videos on their PCs more often than play 3D games.
With that being said, Intel Integrated Graphics tend to do quite well with video, especially HD Video, rendering.
Somebody that cares about 3D graphics performance, because they want to play the latest and greatest games, is going to buy discrete graphics regardless, doesn't matter if the integrated graphics is made by nVidia, ATI, etc.
That's because the school is legally responsible for your child. For example, if there is a natural disaster, they need to account for EVERY child. What would you do if the nurse told you she thought your kid was in class, and the teacher said she thought your kid was in the nurse's office, and neither knew where your kid really was? That is why your child is supposed to report back to the classroom, then say that she needs to go to the restroom, rather then just going there on her own.
That's how you are supposed to use certificates. It's only as secure as your weakest link. In this case, how you provision your root of trust. That's why every client implementation ships with a handful of preinstalled root of trust.
That way when you need to install another trusted chain, you have something to bootstrap it with... That way if you do business with say, "uTorrent", you don't have to physically swap anything with uTorrent directly, you both can choose to bootstrap trust with one of the preinstalled trusted roots, such as Verisign. Then once you install other certs in this fashion, you can start using these new certs to bootstrap other relationships etc...
This is how its supposed to work. You can think of it as an external channel, but the original poster was making a different argument. One of the original replies to the poster mentioned trusted roots, which is exactly this system, but the original poster claimed even that was vulnerable to man in the middle, and only talked about needing to physically exchange keys with the intended recipient. When it became obvious that person didn't seem to understand how certs actually work, I simply explained how the trusted root system works.
If you have a compromised client that's a different story.
However, just because you obtained the software from the internet doesn't necessarily make it vulnerable to man in the middle in and of itself. If you downloaded it from some random place that you never heard of, that's different.
But lets say you get it from uTorrent. If they made it such that you have to go into a secured page on their page, then they would present you with a uTorrent cert, that is signed by a trusted root, lets say Verisign... Your browser ships with this trusted root straight from CD/DVD, OEM, etc, that you bought straight from the store.
Man in the middle may be able to fake the uTorrent site, but they wouldn't be able to fake a cert for uTorrent that is signed by one of the pre-installed trusted roots in your browser.
Now lets say they did manage to fool cert validation... All it would take is for somebody to realize this, then that "bad" cert would get added to the certificate revocation list, and the bad cert will get black listed and get flushed out the next time it tries to validate the cert.
Now I"m not trying to argue this system is perfect, I'm just saying that you make it sound like it's worthless so there is no point in using it. If the user is being a tool and just ignores any and all cert warnings, or doesn't even bother to look at the cert, that is their own fault. No different than writing their password on a piece of paper and taping it to their monitor.
Used _correctly_, this mechanism is quite secure. But if the user is a tool, or the author of said app is a tool, than all bets are off...
Now I can finally get started on building my holodeck.
Sounds like you have no idea how certs actually work. Even if you man in the middle the cert, YOU STILL DO NOT HAVE THE CORRECT PRIVATE KEYS TO SIGN THE CERT. When you pass that cert to the client, its cert chain will fail validation, because your certs chain of trust is not trusted by the client.
When you man in the middle a cert, usually you use a self-signed cert, and hope the client doesn't notice.
High level example... If the client trusts the Cert Authority A, and has a cert chain saying A, B, C. Then when it recieves a cert from you, it will expect your cert D, to be signed by C, wwhich will be signed by B, which will be signed by A. If you man in the middle your own cert F, how the hell are you going to manage to get your cert chain signed by A, B, and C?
A man in the middle attack will result in your cert F, usually being signed by F, or some other authority G. Neither of which will validate against A, B, and C, so the client will reject your cert.
Uh no, another cert can't be inserted. If another cert is inserted it won't validate.
What certificate are you going to present to the client? If you forged the public key, the cert won't validate, because the client will detect it when it tries to validate the cert chain, as the client won't trust your root cert.
I didn't say the study was about visio or PDF, I was just using them as examples.
As far as Linux accessing NTFS... It can read from NTFS but it can't write to it... Also, most users of laptops that need long battery life are enterprise users. Many enterprises use an encrypted file system. Linux cannot read those.
I completely understand demographics, but you seem to not understand economics and ROI. Have you ever approached a company like Dell or HP and try to persuade them to support something like this? Before they give you the time of day, they will want usability studies, (and they will even conduct them on their own), and they want a monetization story to show them what the market looks like, and how they will make money on it, and how much. You have to justify every penny of extra cost to the platform. If they see that it is not worth it, they will not build it... So let me ask you again... Have you approached these OEMs? I HAVE. I know what they said.
You are acting like YOU are like the majority of people out there... But guess what, you AREN'T. Most consumer notebook's don't even leave the home. Of those, most are always tethered to A/C power. Why do you think most "long life battery" notebooks are usually in an OEM's business line of notebooks? The margins on these computers are smaller than you think. I can hardly get OEMs to agree to 50 cent increases in bill of materials for additional hardware. You think you can convince them to add an entire new platform into the notebook without a strong monetization story?
That's why I said there's better approaches. For example, simply switching the type of memory used on the system can net you a 40% power savings. You'll have an easier time trying to convince the OEM to incorporate this technology (especially if the BOM cost differential is negligible), and show that it would be a seamless integration... Versus saying that they can add $10 in BOM cost to the platform, and show that the integration wouldn't be seamless because you are dual-booting, etc, questionable access to some enterprise scenarios, but it would benefit a niche consumer market (based on usability studies conducted by the OEM to validate feasibility)... Yeah, that will be easy to do....
Why is sending emails or web surfing on a phone painful? Because of the small display? That wasn't whay I meant when I was referring to that. When I said I wouldn't want to be in that environment, I wasn't referring to the phone's environment, I was referring to the ARM environment. You can connect a 10" display to the ARM, but which app are you going to be running? Opera Mobile? That browser sucks compared to a desktop browser, doesn't matter if the screen is 2" or 10".
Integration is VERY important... So let's say you want to send email from a low power mode... What if you need to attach a visio file? Where is the file stored? In the ARM partition or the Windows partition? How you going to access the Windows partition? Ok, so let's say you managed to carve out a shared FAT volume.. What if you need to make a quick edit to that file before you send it? Which ARM app you going to use to open the attachement? What if you need to make a quick edit to a PDF file, such as change the value of one of the fields... Which version of Adobe Acrobat are you going to use on that ARM?
How do you know people would have no problem dual booting for that scenario? Did you do a usability study? We actually DID work with a company on a usability study for something similar to that, and guess what? It FAILED.
Like I said, if the primary concern is power savings, there are much better solutions than taking an entire platform (ie ARM), and wedging it into an existing platform (ie x86), and jury-riging it (ie Dual Boot) into a single device.
You can work at reducing power at the CPU, at the chipset, at the memory, etc, etc. For example, you can save lots of power by switching to a type of memory that doesn't have to be constantly refreshed, etc, etc.
Yes, but that's an apples to oranges comparison.
The Atom runs the same OS and the same Apps as a real x86. Who cares if an Arm gets better battery life... My phone has an arm, and it gets better battery life than my notebook. But that doesn't mean I'd rather spend my day in that type of environment.
You really think the average joe will be ok with running a platform running linux as an acceptable replacement for the windows environment they are used to? Running two parallel environments that are dissimilar is asking a lot of the user.
An Atom/Hybrid device is like a gas hybrid car... Looks and feels like any other car, and the user does just fine with it, using less gas...
Using an ARM/Hybrid would be like giving a diesel powered moped with the gas car to the user, and telling them if they ride the moped they'll get much better fuel economy than a comparable Atom/Hybrid.
Sure, that's true, but the utility is not the same. In the Atom case, if the user wants to access some visio foils, he loads up Visio just like on the desktop... Of to use the car analogy, he has a big suitcase, and just tosses it in the trunk..
In the ARM case, he needs to find a compatible app, or possible recompile the App if it doesn't exist... That's like telling the user that he can't take the suitcase, but that's no problem... He can just go to the store, and buy a new suitcase that looks just like his suitcase, but has special attachments to connect to the moped.
I didn't say it couldn't be done, I even illustrated how it can be done... My point was that when you start sharing memory like that, you aren't saving any power, becuase you'll have to keep the x86 powered up to run the memory controller.
I also mentioned that two isolated environments is not a good solution, because it is not seamless. Why would I want to dual boot my laptop on two different non-compatible OSes, just to save battery life? If I'm doing simple things like email and crap where I don't need the horespower of my laptop, I won't even bother with the laptop, I'll just do it on my phone. I don't like carrying my notebook when I don't have to.
You and I can both dual boot linux or whatever OS on ARM and Windoze on x86, and use it just fine... But take Joe sixpack... He'll get mad when he tries to run WinMobile or whatever on ARM, and wonder why he can't launch Office 2007 to view a simple word document. Or get frustrated when he sees the interface and functionality for Pocket Word is vastly different from Word 2007, etc.
There is a reason Atom runs x86 instructions... It's so it can run the same OS, and run the same apps as it's big brother. Joe Sixpack will appreciate that when he sees that the same apps that run on his desktop, will also run on his netbook. It provides for a consistent user experience.
I'm just saying that there are better ways to reduce power on the platform, than to take an orthogonal platform like ARM, and try to jury-rig it in as a solution.
If that's the case, then what's the point?
Doesn't matter if the atom did it in 130 seconds, because 70 seconds still sucks.
Whose going to be doing that in real life? That's like comparing which is faster at encoding h264. Doesn't matter what the results are, becuase it'll suck for both, and nobody will be doing this on a netbook in the first place.
I don't know what the hell kind of webpage they were trying to display... I have an Acer Netbook with the Atom in it, running Windows 7. It renders slashdot, ars, and even facebook, within 3 seconds or so...
The 386 was designed to co-exist with a 387 math co-processor. ARM was not designed to co-exist with an x86.
Good luck running the Windows OS on ARM. The Windows OS relies on many features of the CPU that are not present on an ARM. Unless you are going to suggest that the feature set of Windows Mobile is good enough...
Those architectures have the memory controller off chip.
The architectures where you plugged in an x86... They started with soft emulation, which is pretty slow. The add-in card allowed you to get rid of the software emulation. However, those add in x86 cards were still based on architectures where the memory controller and such were off-chip, so that the 680x0 architecture could just virtualize the memory controller (among other things)to the x86 CPU.
You can't do that with a modern x86 CPU, because there is nothing to virtualize, becuase the CPU only talks to the on-die memory controller.
In order to correctly do this today, the ARM processor will have to talk QPI/Hypertransport to the x86 to access memory as well as to maintain cache coherency. If you are going to be doing that, you aren't going to be saving any power. Plus you would really bog down the x86 CPU, becuase what if the x86 CPU needed to access a resource that was locked by the ARM processor? How many wait states are you going to have to inject for x86 to wait for the much slower ARM to satisfy a bus request?
And lets say you do it the virtual way, you still have to deal with data sharing. Apps running in a virtualized sand box will not have access to all the data/resources in your main OS. This isn't the 1990's anymore where everything can just access the same physicall address space.
It would make more sense to move to an architecture where you have something like a traditional Intel or AMD CPU, where the cores would just shut down when not in use, etc...
Having two CPUs of different architecture is ridiculous. How are you going to make that seamless? For example, how are you going to access memory from the ARM? The memory controller is in the Intel/AMD CPU. If the AMD/Intel CPU is powered down, so is the memory controller. If the memory controller is powered down, the ram won't get refreshed.
So you'll basically need an off-chip memory controller. If you do that, then all of a sudden you have even more headaches, such as trying to synchronize the caches on each core of the Intel/AMD cpu, etc. (And this is overlooking the instruction disparity)
If you are talking about having a separate operating environment/desktop/etc completely separate from the main environment, that is going to be awkward for a lot of users, as many will expect seamless integration and data sharing, etc.
Also, don't fool yourself and think that just because your hybrid is running an ARM that you will magically get all-day battery life. The CPU is not the only power drain on the system. You also have the wireless radio, the LCD display, and the graphics processor, etc.
In other words, a tool that a) accesses elements of a copyrighted work b) evades protection mechanisms to do so violates the DMCA. Maybe the issue isn't with the judge, but with the law he's interpreting.
On the same token, then every Anti-Virus program also violates the DMCA, becuase they use thread-injection to launch a thread into other application's processes so they can check for viruses, circumventing any checks that the app may have had, because the AV software now has a "rogue" thread in your app able to access its resources that the app thought was supposed to be secure.
How is not running Aero the same as the car falling apart? Vista capable, means able to run Vista, which these computers can... In fact, the Intel Chipset CAN run aero, and it did in the beta, MS just decided to make WDDM a requirement for Aero.
But that aside... How are the hardware vendors responsible for this? You guys do realize that even if you have the highest end graphics card, Aero will TURN ITSELF OFF as soon as you run any application that does overlays, right? That means i the user buys Vista with top of the line everything, then they install their media player from their capture card, it's possible that Aero will stop working.
This is why I doubt you'll get the HW vendors to take any blame, because Aero in and of itself is half baked at the software level. (At least until Windows 7, which does support overlays)
You can only work through so many nights without sleep before you finally realize you're not compensated enough (in pay, recognition, or even lack of complaints -- which == recognition in our field often). Sorry to be a whiny IT wonk, but pay alone doesn't cut it. You watch the person you made that app for take all the credit for it and you might get a ** mention in the fine print. They get promoted over and over and you get... another project.
Perhaps I'm just lucky then... I have gotten many promotions, and have been rewarded multple times for going above and beyond the call of duty. I've even been rewarded with all-expense paid vacations when my extra-efforts land business deals with other companies, etc.
Not to mention people are attacking the guy when one of his examples is someone that strolls in at 9:30 and wasn't there at 3pm!
Thank you! I should note that when I said I "often" worked till 10pm, I should point out I stayed till 10 not becuase I was asked to or expected to, it was because I wanted to, because I actually enjoy what I do and have fun with what I do. That is a quality I'm seeing less and less of...
And to some of the others... I understand that what's work is work, and you want to have a life. But we don't live in a utopia, and the world does not revolve around you. Sometimes you need to make some sacrifices to help someone out...
And I never suggested that you should work 60+ hour weeks. Everyone here works on a flex schedule, but many abuse it, like the person in my example... Comes to work at 9:30, but is not in the office at 3pm, and does not have her laptop with her. All I needed her to do was to logon on to the network and upload some files that she was SUPPOSED to have put in the repository. The files I needed were relatively small, so should only take 5 minutes. Is it too much to ask to take 5 minutes of your personal time? (Nevermind that at 3pm, she's supposed to be on company time) Is it so terrible to ask her to come into work early (and leave work early) to do the same from the office?
I was just making generalizations about some trends that I've been seeing lately, I'm not trying to offend anyone, as I know there are indeed great employees in this group as well. It's just that even when I look at my own friends that are younger and part of that generation, I can see the same traits.
For example, I'm noticing many of these people are very focused on what their immediate job requirements are, and only focus on that, and claim anything above and beyond that is out of scope, and not in their job description.
To use the same person in my previous example... On another occasion, (many actually), she would tell me (out of the blue) that my code broke from some random project and I need to fix it...
I would ask her what the problem was. She would say, "I don't know, there's a bug in your module".
I would ask, "What's the bug?"
She said, "I don't know, that's not my problem, it's your code"
I'd ask her to step through the code, to give me a little more to grasp at, and it would be like pulling teeth listening to her explain it's not her job to debug my code. It's like she was doing me a favor. She came back like an hour later and told me that after debugging, she said she found where it crashed, and said I was doing something wrong. She said it happens in multiple places in my module, but it always crashed on a "malloc"...
Oh geez, after she told me that, I told her that she must be corrupting the stack frame... She said the crash was in my module, so it was my problem. She seemed offended that I was suggesting that the problem was in her module.
I decided to give her a hand, and walked to her cube, and walked through the debugger with her. I asked her if she was doing any memory manipulations prior to calling into my module... She said no...
So I launched the debugger, and looked at the memory when it crashed... (and explained everything I was doing)
I found a text string in memory that shouldn't have been in "free memory", and asked her where that string was used... Jumped to that section in her code, and within seconds, found a hefty buffer-overflow where she was improperly writing to memory without checking the bounds.
I can understand these types of mistakes, but it would've been nice if she had said that she didn't understand what was going on, or asked for help, etc.. Instead, she just blamed me for her problems. I've seen her go home early, and she would say that her program is crashing, and the bug is in so and so's module, and they are out of office, so she can't make any progress, and as a result says she's going home early.
I'm curious what your definition of "often" is in this case. While I find people across age groups that are lazy, I'm finding it far more likely with younger people these days being the worst in that they want things handed to them and want to minimize what they actually put into the job.
I noticed the same thing... Young Gen-X people seem to be the ambitious type, but the young Gen-Z people tend to expect things handed to them... I noticed that a lot, and even heard of books being published to help employers deal with these new breed of workers...
When I graduated college 10 years ago, I was one of those ambitious people... I often stayed at work till 10pm to insure our products/projects met their milestones etc...
Recently we hired new hires that are of the new generation. So far, many of these people are out the door as soon as the clock hits 5, regardless the status of their projects and when the milestones were... Even when I'm travelling on business and am halfway across the world, they don't want to take any personal time to give me a hand (even if it's to upload a project they are past due on). They didn't even bother taking their work laptops home, because they don't want to "work" outside of work.
They told me they'll upload it when they get in the office. (I called 3pm their time, so they should have been IN THE OFFICE, but they left early). I asked for it at 7am their time, but they said no. Said they'll do it when they come in at 9:30am. Of course that was useless because of the timezone difference, because the meetings would have been over by that time. Had they been in the office at 3pm, or logged in, or whatever, I would've had a full day to get the project/kinks worked out at the client site... But because of their lack of team-spirit, we had to waste the opportunity of being in Europe to test the integration on-site. The next opportunity for on-site integration testing at a different client location was 4 months away. You can guess what that did to schedules...
Especially considering the project was supposedly already done, but this person never bothered to check in their code to the source code repository so I had no access to it. The only copy was on this person's notebook, which was not with her, and not powered on, so it wasn't on the network.
When I was their age, there were times when I would log in, or be in the office from 1am to 7am just to make sure I was aligned on the same time-zone so I could work with the team remotely (budget restraints on travel)
Very frustrating...
I can't wait until an employee sick with the cold or flu shows up to work, and their PC gets sick, infecting the whole network.
Remember that Star Trek Voyager episode the Voyager's bioneural gel packs got sick, and the whole ship went haywire?
From what I'm seeing Windows 7 isn't that much of a difference from Vista.
Actually Windows 7 is quite different from Vista. It's based on the same kernel, but there are LOTS of things that changed. I'd be more specific, but I'm under NDA. (No, I don't work for MSFT)
Wow, you really have no idea what the hell you are talking about, as the MAP does not rely on a MAF to meter fuel, nor does it need to. The ECU uses the Speed-Density algorithm to determine how much fuel to meter.
The ECU uses the MAP sensor to measure the intake pressure so that in conjunction with the temperature reading from the IAT it can determine the mass/density of the air. Based on THIS, it consults its fuel maps to determine how much fuel to meter.
Because it is measuring the pressure/density/mass of the air in the intake manifold, is why the ECU cannot be fooled by BOF valves, because the MAP will detect the drop in pressure and compensate accordingly.
And yes, you can effect engine load by modulating the gas while in gear, because you are effecting the load on the engine. My point was to compare the engine load number when you are in gear vs when you push the clutch in or when you are in neutral. It will be much lower then just idling in gear.
As for the cat, you are completely missing my point. What I meant was that it wasn't the cat's primary job to burn unburnt fuel to compensate for the ECU's doings. To oxidize HC, requires oxygen that is released from the reduction of NOx. As I said earlier, the reduction of NOx is an inefficient process. Stuff like this is why a 3-way cat requires a closed loop feedback fueling system in which the ECU can maintain a stoichiometric air/fuel mixture. (Tho the ECU can and will vary the mixture at times to insure that the NOx reduction doesn't become oxygen loaded and insuring the CO/HC oxidation stages have sufficient oxygen saturation)
I don't know about the rest of the country, but over here on the west coast, during emissions inspection, they actually put your car on a roller, and test tailpipe emissions during acceleration, deceleration, and cruise. This is how I know you'll fail if the ECU makes the mixture too rich, because on one of my cars I had a vacuum leak that was causing a rich condition on deceleration, and this was noted as the failure reason on the paperwork, stating that during deceleration, the HC output was too high most likely caused by a rich condition.
But in the end, who the hell cares? My original point was that because of tightening emissions requirements, cars these days are needing to employ deceleration fuel cut. This is a fact, and is even stated as the primary reason in the service manuals of certain makes that I mentioned much earlier.