I'm having to trust the physical security of whatever device I'm interacting with, bringing my own keyboard and display gives me insurance on their mechanisms.
And so the chip cards have processing elements on card that have data input and output, and never make available their contents to any device they interact with? Or is there assumption that the ATM/POS equipment is all trustworthy and secure and will discard the data and never be possibly compromised by a malicious retailer?
How do I know someone hasn't disassembled the device, and put in some bug. Best case on the part of the device, extra pads under the buttons to register the presses, or a camera positioned just right.
That's why I say my device must have a private keypad/display, so I don't have to trust the POS equipment at all. Besides, doesn't cover credit card numbers, which remains the significant share of online purchases.
Seriously though, identity theft is one of the big scary monsters that is used to scare the public on a daily basis. If an offering that experts agreed was highly resistant to identity theft, some consumers may jump at it after all the fear mongering.
You forgot the step where your computer has a key logger installed and someone overseas now has all your data. Someone steals my device or gains unauthorized access and *then* returns it to me unnoticed is *far* more likely to be noticed than taking my card, scribbling the number on the front and back, and putting it back. Or for random POS equipment to be instrumented that I interact with. Or for some old-fashioned place with the carbon copies or some stands to be set up. At least the security risk lies in the implementation of the device, *not* fundamental to the system. Sure, *the* most secure proposition is currency, but other than direct physical interaction, currency is *not* feasible for the same reasons its good for face to face. Mail currency and anyone can intercept and use it, as it's not traceable and not targeted.
That's not even getting into your other major flaw, and your incorrect assumption. It would be much easier to discuss those points if you at least mentioned what they were.
I've been wanting something much more sophisticated than a 'shared secret' that you have to give to anyone to give money. If I let random restaurant a charge me 2 bucks for a drink, I have to give them potentially full access to my accounts.
Where's my private/public cryptography? I want to carry around my own damned device with keypad and display. The display would show me *exactly* what my financial institution will think I'm authorizing, and the keypad would be used to enter the passphrase to decrypt my private key, which is never ever ever transferred outside of the devices local filesystem. It's generated by the device and the public portion uploaded in a secure manner to my financial institution. The secure manner is a complicated issue, but there are degrees of inconvenience that can be induced to do it right, and allow me to opt to allow nothing more convenient than that.
I go to a damn store or online retailer.. When ready to purchase, it somehow gets the data to my device (maybe encrypt with my public key, maybe direct connect to my device, maybe through the financial institution, whatever, the security risk in this transaction being the nature of what I'm buying, not in any way risking the actual money being transfered). I enter my passphrase (which could be as simplistic as a 4-digit pin, but at my discretion, not theirs) to signify accepting the terms my display gives me (i.e. authorized wal-mart to take 5 dollars from my account this one time, or authorize phone company to withdraw no more than 25 dollars on a monthly basis, the transaction may have tolerances and periodic, but always show me the tolerances and period and *who* I'm really authorizing to get the mony). With my private key decrypted, use it to sign the payload, then my financial institution *must* receive that cryptographically signed authorization to transfer payment. The retailer *never* has anything more than data to confirm that one transaction (or reuse for repeat data if I declare that trust, within definable thresholds). To commit 'identity theft' (horrible phrase), they would either need to compromise the financial institutions database with *write* access to replace my public key with their own (by the way, invalidating my real key so I should notice it) or steal my device physically, which I should know. The device should overwrite memory contents where the key was with random bytes every time it completes an authorization, and therefore physical theft or tampering should lead to a dead end without my passphrase.
Why the hell would you want to do that? The kernel is not interesting, and doesn't give you the vast majority of compatibility features, you need the various libraries, GUI, everything else. If you think magically excel will work without MS libraries and will run under X, you are deluded.
Even if very strictly only talking about reboots that go to firmware, depending on your system and what kernel you are changing from/to, the new kernel may do something odd like hang or some hardware/driver interaction might get confused by the situation (if the driver was unable to unload, and so the case of two driver loads coming without a driver unload or intermediate firmware initiation confuses some set of devices gravely, a few instances to the point of panic). As far as I can tell, most common cases kexec works well, but it isn't universally safe even if every driver is unloaded and precautions are taken before the change.
But I wouldn't dictate avoiding firmware as being *that* significant, *particularly* on desktop platforms with relatively fast BIOS. From a user convenience factor, kexec still means the entire process space/memory/everything goes away. You start init over again with a new kernel and initrd, just like you would from grub. It's not exactly a consolation that a kernel update will not get you into firmware if it still resets everything your doing like a full system reboot would. I can see with some card firmwares being annoyed with startup time, but it's generally not that bad. If really disconcerting, a number of cards/BIOSes let you disable the firmware for the card and the linux driver will still work, you just need/boot on some trivially accessed media (i.e. a USB key) and / could be on any number of inconvenient devices for the firmware to get at. I just think the frustration system firmware is blown way out of proportion, and instead of insisting of doing away with it, demand features that facilitate things like fast boot and exotic boot loader configurations. A BIOS that would skip straight to a USB port (making all the relevant assumptions along the way) and go would go a long way paired with a USB flash storage device.
As fun as it is to poke fun at MS for updates incurring reboots, most modern distros end up issuing a kernel update every couple of weeks, so linux is not immune. Also, I have some misbehaving drivers on my laptop that currently preclude suspending, and thus shut down when I have to travel with it, so it's often the case my linux laptop incurs resets that flush cache. Finally, the simple reality is if you want to build a platform for the masses, you have to deal with some users that even with everything lined up to avoid cache-dropping reboots, will want to shut-down or reboot because they feel like it (or know suspend on their particular hardware still draws a few watts, and want to save that). OO.o whether you like it or not is a significant piece of that equation as it has the largest mindshare among the free suites, afaict. As much as I find it critical to use pipes in the shell to make use of various programs, it's not something I relish trying to explain to a complete novice.
Meanwhile, if you close the app every time without rebooting, you won't be so bad off in the case that preload aims to help. Firefox starting once induces it's disk needs to be cached, starting it again should have a high disk cache hit rate. Leaving the app open just to avoid an eventual startup penalty can be a waste of memory and work against performance if you starve memory available for disk caching.
dramatically speeding up loading Not so much in my experience, it just pushes all the loading and *then some* to the boot process. You may only ever hit, say, 40% of the disk content on a livecd if not tuned to your usage, and therefore incur 40% of the content having to be read painfully slow on demand. By virtue of being on demand, every operation that reads new files will be obviously slow the first go around.
Meanwhile, toram and such cause 100% of the disk content to be hit up during boot process, and can make it excruciatingly slow. However, once that one singular step is done, it will be amazingly responsive.
updatedb is a little different. Yes, I suppose on some amounts of memory, it will dislodge cached pages here and there, but updatedb doesn't do *much* with the files. My desktop has 12GB of ram, and has been up through a number of updatedb cycles and heavy heavy usage. It currently has 8.6 GB of ram it cannot possibly figure out a use for, that is left free, and 1.9GB of disk blocks held in cache. The actual memory used is 1.4GB, and there are 217MB of bufferspace allocated. With 4GB of ram, I would be in equally good shape with my usage pattern after a week of uptime.
updatedb when running has historically been sluggish due to poor IO scheduling. That has had a lot of attention as of late, but I haven't run a recent kernel on anything not ludicrously overpowered, so I can't comment how that has been working out.
Now the full content indexers (like beagle or whatever it is nowadays), those would hypothetically induce the behavior you describe, but another post hints at how the kernel provides the facility to address that.
In relatively recent history, IO scheduling has been painful on the desktop, but the kernel developers have been aware and working to make sure the right facilities are in place for programs to make use of the system without provoking the kernel into making wrong guesses about caching and such.
total used free shared buffers cached Mem: 2026 1512 513 0 770 379
buffers/cache: 363 1663 Swap: 2870 0 2870
slashdot won't seem to let me format the way I want, but run free -m on your own. The cached column is the 379 figure. Note the 379M number. That is the amount of data read from disk and kept in ram. When an application needs to malloc and no completely free memory, yes it will free up those pages (it ideally picks the cache least likely to be needed again). But absolutely, disk contents are kept in disk cache, but only after load. And no, memory leaks aren't hopelessly pervasive.
What preload does normally happens implicitly during boot. It's hard to demonstrate on init scripts effectively, but log into gnome right after boot, and the disk will thrash like crazy. Log out, kill every last process of that user, log in again. It will be quite dramatic. preload aims for that subsequent experience without the pain of the first.
So what preload brings is simple, and all that has to happen is simple, know which files are relevant to typical usage ahead of time, and be aggressive about 'cat file >/dev/null' if the system during boot has IO idle time. Presumably, the key is identifying which files those are for a particular system.
Linux implicitly aids this, but the user interface side still subjectively 'feels' bogged down because it won't proactively load things it doesn't know you'll need, despite the ability to derive this historical data in user space. If preload takes idle time (let's say, for example, while services with arbitrary sleeps and while waiting for username and password) and proactively gets cache populated, it is more IO work in the aggregate (disk will be hit up for things that will never be needed), but it will feel smoother out of the gate.
The whole point of the QPI is to not have a loaded FSB that makes scaling difficult. IDE-to-SATA went to point-point, PCI went to point-to-point in PCI-e, and now northbridge communications that have been bus oriented logically go the same way (past tense for AMD offerings). With respect to concerns about accessing non-local resources, that's what NUMA is all about and it has worked well for AMD. Essentially, the penalty isn't that bad and intelligent NUMA-aware OS process scheduling avoids the worst case for the most part.
also there needs to be quick path / HTX slots not sockets for add on 3rd party chips on the cpu bus and they need to let you any chipset like how there is a number of them for amd systems on the desktop and the sever side. Really, no thanks. PCI-e 2.0 has plenty of bandwidth and decent latencies even for co-processor applications. At least not worth the penalty of having a processor-specific adapter card which QPI and HTX dictate. If Intel had adopted HTX instead, maybe there would be an emerging market, but aside from specific scenarios, I think it a bad idea to produce something that will only understand how to behave in either an AMD or an Intel box, but not both. The obvious means to acheive independence would be offering the same part under HTX and QPI bridge chips, but at that point, that becomes sort of the very definition of a PCI-E chipset, which talks HTX out one end and PCI-e the other in AMD boxes.
Skulltrail by definition is an Intel design. There are a host of multi-socket chipsets that could do it theoretically, but Skulltrail is little more than a concerted marketing strategy around such capable parts. One interesting aspect of HT and QPI is that the planar chipsets become socket-count agnostic, just the processor you buy must support the right number of links for a multi-socket config. That said other than the '1337' factor, Skulltrail is a ludicrous waste of money. They explicitly declare it not suitable for server-class operation, and yet the only thing that currently meaningfully pushes beyond 4 cores is not to be found in the desktop space (programmers just aren't threading the intensive stuff that fine grained yet).
Intel did have a hell of a time confusing people before the concrete samples were available as to whether it was the same thing as AMD's 64-bit. They avoided using any term AMD associated with it for a time, instead tossing around ia32e and em64t and bs like that. I know some projects even baked into plans how to cope with yet another processor architecture for lack of a commitment from Intel that their 64-bit x86 compatible stuff would be the same.
Intel's hand was effectively forced because they learned their lesson from Itanium, don't screw with an incumbent variation of your flagship instruction set. With AMD's lead they would've risked yet another Itanium fiasco, so they picked the safe path and tried to PR dance around the existence of AMD's 64-bit stuff.
Itanium was an odd path in the history of Intel proving they truly thought they alone dictated the course of x86 technology. It stands in stark contrast to the history of supporting legacy all the way back to the 8086 days.
In this case, it's not the end-user or software developers being impacted, just hardware implementors who already have to do whatever the processor architecture dictates. Despite that freedom, Intel's unable to offer something that isn't obviously similar to the competing offering since it just is such a damn good idea. AMD has led some revolutionary changes in x86 architecture, while Intel has been able to follow up with evolutionary advances, fabrication, and marketing to continue eating the more significant profit margin space.
"These so-called pension funds are likely part of that approach and just softening up Yahoo, while setting the media against the board in prep for its ousting." Anyone reading the statement can readily tell it's an expression of speculation, random slashdot posts, particularly throwing in words like likely, do not constitute talking down the stock.
I know FrontPage had no integration with IE or MS software (other than the obvious lack of non-Windows versions, which I would count as at least a loose link with MS, just a common one), the product was a logical complement. You make a browser, having a complementary content creation offering simply makes sense. I don't recall a remotely credible/significant MS product that competed with FrontPage, so I don't see why MS would simply want to bury it. Also, FrontPage did not *fundamentally* champion OS or browser independence. It certainly could contribute to such causes, but it was possible to target IE primarily without compromising the basic nature of it. Meanwhile, BSD contributions just absolutely run against Windows without benefit to MS platforms, php can run on Windows, but MS has enough solutions they deem better, so php developers I would wager are not high on their list of resources to use as-is. Zimbra is a product that theoretically MS could subvert to being Windows platform only groupware, were it not for the Exchange offering. I know Exchange offers some sort of web interface that isn't as slick as Zimbra's. While they theoretically could add snazziness from Zimbra to their web interface, the fact is the Exchange web interface is 'good enough' and nothing really stopped MS from snazzing it up themselves before now. My guess would be they have motivation to keep the MS-only client experience 'richer' to strengthen the link between their product lines, with the web interface being considered a concession for road-warriors and mobile devices for interim access to content when Outlook is not conveniently at hand.
The issue with a number of the heavy hitters in the web space is that they are a lot more diversified technology wise than the company behind FrontPage. Any company with huge public-facing open-source usage is bound to contribute significantly to the projects they use. So instead of being consumers of MS competitor products, they are also contributing to MS competitor products in spaces where MS has been convicted as a monopolist. The direct motivation of yahoo as a weapon against google isn't much to worry about, at least less to worry about than Google's share, but the incidentals are something to worry over. It's hard for MS to conduct an acquisition these days without anti-competitive implications, whether they want to or not.
No, Insurance PROFITS are all about modeling the risks. Insurance is actually about distributing unknown risk among a large number of people You're right, taking my view of it to the ultimate extreme (knowing perfectly the future) reduces things to no insurance in the end. Of course, by definition, genetic screening is reducing the amount of distributed unknown risk, so it still would play into your more accurate description If all risks are known, insurance would devolve to meaningless either way. The opposite end, where everyone gets a flat fee won't work in today's market. Any company that offers a flat fee based on the total average of customer induced medical expenses would be too expensive for anyone where other companies exist that scale down the cost.
Let's say hypothetically that these genetic tests are done by people, and insurance companies offered a la carte rates (i.e. could insure for blood cancer specifically, welcome all comers willing to pay for that coverage). In this case, the customers naturally discriminate themselves, as people who have reduced risk of blood cancer would more often waive the coverage, and in aggregate the percentage of people who buy that insurance plan are quite likely to be afflicted. Either way, whether driven by the insurance companies or by the customers, rate hikes would occur. So a la carte premiums for certain prominent genetic conditions might be a way to drive the rates without technically discriminating or even knowing as companies. I wonder if the bill also prevents a la carte plans...
There are naturally given risks (genetic predispositions) which are unfair and in an certain idealistic vision, the ones covered equally at equal cost across the population (i.e. assumes equal risk of prostate cancer and everyone pays without caring about likelihood, screening used merely for early treatment), and there are voluntary lifestyle risks, like smoking, drugs, and physical activity, which could be abusive of a completely flat non-discriminatory system.
It's a whole set of rough questions, and health/life insurance companies from the very nature of dealing with life and death situations from a business perspective inevitably come off as either sinister by effectively choosing death or a poor business by doing the 'right' thing, it seems. Even if forbidden from denying coverage, they can always price the rates such that they aren't significantly cheaper than the treatments, so I see a rough path ahead regardless as tools for accurately knowing the likelihood of genetic conditions emerge.
Would they lower rates due to a clean genetic test compared to the normal now?
How long before insurance companies proactively raise rates, but then offer a discount back to normal if you provide genetic test results?
Is the bill worded such that neither penalties nor bonuses can be given out due to a genetic screen?
How much different really is it from family history, just a more accurate measure?
Insurance is all about modeling the risks for an individual based on available medical data. In *theory*, if genetic screening can increase the accuracy, then people with clean genetic situations should get decreased rates from what they pay now, while those with the dispositions carry the burden of the risk. If all goes according to the hypothetical, neither way is particularly feels 'fair'. On one hand, your rates go up because you got stuck with some genetic predisposition for heart disease that you couldn't control, that may never manifest. On the other hand, someone with a genetic disposition that will never suffer a particular ailment, will have to pay for the risk of that ailment anyway.
Of course, the chances insurance companies would *lower* any rates is slim, just jack up rates with the excuse of apparently increased risk individuals without ever acknowledging the class of reduced risk individuals.
Uh huh. And just how many CEO's and CTO's have been fired for using ATI or Nvidia's binary blob? I suspect the number's between zero and your imagination. He was suggesting AMD's or Intel's CEO, not 'client' companies. I doubt it would get to C*O level, but I could see leadership being shuffled out of responsibility if they didn't, for example, make a correct strategy to get the GPUs sold into the HPC market for GPU computing while the competitor did. I.e. if someone takes the open source specs and designs a set of really kick-ass math libraries that cream anything done with nVidia's CUDA, that could lead to a lot of AMD GPUs being moved while nVidia rushes to leverage that. I doubt anyone would be fired though.
The total number of hardware and still growing that's released with a binary blob is still greater than the total number that have open source drivers. Huh? I can count two families with binary blobs as the only option for full-function, nVidia and AMD. This story hypothetically paves the way for the AMD half to go away, leaving only nVidia for now (rumor has it nVidia will follow suit). There exist some fakeraid cards that have binary only drivers to use the same format as the firmware support, but overwhelmingly this is skipped for pure software RAID. There exist a few wireless drivers without Linux drivers at all, but ndiswrapper has brought over the Windows drivers, so I guess you could say those are binary blobs. Even counting all that, you still have countless network adapters, graphics chips (current hardware is mostly Intel on that front), wireless adapters, storage controllers, audio devices, USB devices which in no way require a binary blob. The binary blob portion of linux support is a vast minority.
I'm saying in order to get the same number of flops and using price-performance instead of straightforward performance, you must increase node count. If the processor performance/watt *was* better (I believe with the 45 nm process on Intel's side for the moment, a Xeon 2.33 quad core comes in a 50W TDP variant, for example, Barcelona comes in at 95W TDP, goes along way toward offsetting the FB-DIMM power), you still have to worry about more AC power supply inefficiencies, general power usage of extra motherboards, fans, hard drives, etc. I hear Opteron may be able to more effectively reduce power consumption when bits are idle, but if you aren't overbuilding your cluster and will always have jobs in the queue, the goal is to avoid being idle. If utilization of the cluster is consistantly under 90%, you probably overplanned and paid too much.
The FB-Dimms do suck however. Expensive, power-sucking, and so far only yields none of the promised memory throughput benefit while incurring a significant latency penalty. The only theoretical benefit achieved is that a simpler trace situation is possible (i.e. can scale out memory without a ludicrous trace design requiring many layers), but I haven't seen that leveraged in practice beyond what AMD offerings have scaled to. The other thought put forth is that PCBs could be done with fewer layers with respect to the DIMMs, but I think for other reasons the boards have to have so many layers anyway, so that could be a moot point.
One of the significant aspects of the stealth is trying to keep the exhaust temperature somewhat down. It loses a lot of power trying to keep a low infrared profile. Similar problems on intake, direct wide open intakes would also run counter to the stealthiness.
Comparing my R500 part with fglrx with an R300 part with the open source driver: -With fglrx kernel module loaded, my laptop has not been able to suspend ever (using Ubuntu Gutsy) -I have to do a goofy Virtual 1408x1050 resolution with fglrx to make 3D applications not look horribly corrupted. This is weird, but as long as I don't xrandr over to it, it's not a big deal, however.. -After doing above trick, fglrx shows corruption in lower right hand corner and hardware cursor if trying to do 3D apps at 1400x150 (native resolution). Have to run at 1280x960 to prevent that corruption. -All acceleration (3D and 2D) has a horrible diagonal tearing effect.
The *ONLY* net improvement in the interval you deem 'massive' improvement is in the frames per second area. Though important, the top priority should be reliability.
Meanwhile, though much slower, the open source driver on the R300 part behaves quite in line with what I expect. I look *very* much forward to what the open source initiative ultimately yields. If AMD can cram the fglrx performance into binary blobs that leverage the open source layers for everything they get right, I would be ecstatic.
Both Opteron and Phenom were at the same B2 stepping, complete with the same L3 errata, despite the different packaging. That's why you haven't seen a Tier one vendor touch the Opterons with a 10 foot poll for a generally available product. You can bet your ass this is the reason AMD released the kernel patch so 'some customer' could proceed with a Linux Opteron deployment with B2 parts without the performance penalty nor risk of the L3 errata.
This deployment is probably where AMD focused a firesale of B2 parts, since it's nice and well controlled.
Slashdot Mirror
I'm having to trust the physical security of whatever device I'm interacting with, bringing my own keyboard and display gives me insurance on their mechanisms.
And so the chip cards have processing elements on card that have data input and output, and never make available their contents to any device they interact with? Or is there assumption that the ATM/POS equipment is all trustworthy and secure and will discard the data and never be possibly compromised by a malicious retailer?
How do I know someone hasn't disassembled the device, and put in some bug. Best case on the part of the device, extra pads under the buttons to register the presses, or a camera positioned just right.
That's why I say my device must have a private keypad/display, so I don't have to trust the POS equipment at all. Besides, doesn't cover credit card numbers, which remains the significant share of online purchases.
Seriously though, identity theft is one of the big scary monsters that is used to scare the public on a daily basis. If an offering that experts agreed was highly resistant to identity theft, some consumers may jump at it after all the fear mongering.
I've been wanting something much more sophisticated than a 'shared secret' that you have to give to anyone to give money. If I let random restaurant a charge me 2 bucks for a drink, I have to give them potentially full access to my accounts.
Where's my private/public cryptography? I want to carry around my own damned device with keypad and display. The display would show me *exactly* what my financial institution will think I'm authorizing, and the keypad would be used to enter the passphrase to decrypt my private key, which is never ever ever transferred outside of the devices local filesystem. It's generated by the device and the public portion uploaded in a secure manner to my financial institution. The secure manner is a complicated issue, but there are degrees of inconvenience that can be induced to do it right, and allow me to opt to allow nothing more convenient than that.
I go to a damn store or online retailer.. When ready to purchase, it somehow gets the data to my device (maybe encrypt with my public key, maybe direct connect to my device, maybe through the financial institution, whatever, the security risk in this transaction being the nature of what I'm buying, not in any way risking the actual money being transfered). I enter my passphrase (which could be as simplistic as a 4-digit pin, but at my discretion, not theirs) to signify accepting the terms my display gives me (i.e. authorized wal-mart to take 5 dollars from my account this one time, or authorize phone company to withdraw no more than 25 dollars on a monthly basis, the transaction may have tolerances and periodic, but always show me the tolerances and period and *who* I'm really authorizing to get the mony). With my private key decrypted, use it to sign the payload, then my financial institution *must* receive that cryptographically signed authorization to transfer payment. The retailer *never* has anything more than data to confirm that one transaction (or reuse for repeat data if I declare that trust, within definable thresholds). To commit 'identity theft' (horrible phrase), they would either need to compromise the financial institutions database with *write* access to replace my public key with their own (by the way, invalidating my real key so I should notice it) or steal my device physically, which I should know. The device should overwrite memory contents where the key was with random bytes every time it completes an authorization, and therefore physical theft or tampering should lead to a dead end without my passphrase.
Why the hell would you want to do that? The kernel is not interesting, and doesn't give you the vast majority of compatibility features, you need the various libraries, GUI, everything else. If you think magically excel will work without MS libraries and will run under X, you are deluded.
Even if very strictly only talking about reboots that go to firmware, depending on your system and what kernel you are changing from/to, the new kernel may do something odd like hang or some hardware/driver interaction might get confused by the situation (if the driver was unable to unload, and so the case of two driver loads coming without a driver unload or intermediate firmware initiation confuses some set of devices gravely, a few instances to the point of panic). As far as I can tell, most common cases kexec works well, but it isn't universally safe even if every driver is unloaded and precautions are taken before the change.
/boot on some trivially accessed media (i.e. a USB key) and / could be on any number of inconvenient devices for the firmware to get at. I just think the frustration system firmware is blown way out of proportion, and instead of insisting of doing away with it, demand features that facilitate things like fast boot and exotic boot loader configurations. A BIOS that would skip straight to a USB port (making all the relevant assumptions along the way) and go would go a long way paired with a USB flash storage device.
But I wouldn't dictate avoiding firmware as being *that* significant, *particularly* on desktop platforms with relatively fast BIOS. From a user convenience factor, kexec still means the entire process space/memory/everything goes away. You start init over again with a new kernel and initrd, just like you would from grub. It's not exactly a consolation that a kernel update will not get you into firmware if it still resets everything your doing like a full system reboot would. I can see with some card firmwares being annoyed with startup time, but it's generally not that bad. If really disconcerting, a number of cards/BIOSes let you disable the firmware for the card and the linux driver will still work, you just need
As fun as it is to poke fun at MS for updates incurring reboots, most modern distros end up issuing a kernel update every couple of weeks, so linux is not immune. Also, I have some misbehaving drivers on my laptop that currently preclude suspending, and thus shut down when I have to travel with it, so it's often the case my linux laptop incurs resets that flush cache. Finally, the simple reality is if you want to build a platform for the masses, you have to deal with some users that even with everything lined up to avoid cache-dropping reboots, will want to shut-down or reboot because they feel like it (or know suspend on their particular hardware still draws a few watts, and want to save that). OO.o whether you like it or not is a significant piece of that equation as it has the largest mindshare among the free suites, afaict. As much as I find it critical to use pipes in the shell to make use of various programs, it's not something I relish trying to explain to a complete novice.
Meanwhile, if you close the app every time without rebooting, you won't be so bad off in the case that preload aims to help. Firefox starting once induces it's disk needs to be cached, starting it again should have a high disk cache hit rate. Leaving the app open just to avoid an eventual startup penalty can be a waste of memory and work against performance if you starve memory available for disk caching.
Meanwhile, toram and such cause 100% of the disk content to be hit up during boot process, and can make it excruciatingly slow. However, once that one singular step is done, it will be amazingly responsive.
updatedb is a little different. Yes, I suppose on some amounts of memory, it will dislodge cached pages here and there, but updatedb doesn't do *much* with the files. My desktop has 12GB of ram, and has been up through a number of updatedb cycles and heavy heavy usage. It currently has 8.6 GB of ram it cannot possibly figure out a use for, that is left free, and 1.9GB of disk blocks held in cache. The actual memory used is 1.4GB, and there are 217MB of bufferspace allocated. With 4GB of ram, I would be in equally good shape with my usage pattern after a week of uptime.
updatedb when running has historically been sluggish due to poor IO scheduling. That has had a lot of attention as of late, but I haven't run a recent kernel on anything not ludicrously overpowered, so I can't comment how that has been working out.
Now the full content indexers (like beagle or whatever it is nowadays), those would hypothetically induce the behavior you describe, but another post hints at how the kernel provides the facility to address that.
In relatively recent history, IO scheduling has been painful on the desktop, but the kernel developers have been aware and working to make sure the right facilities are in place for programs to make use of the system without provoking the kernel into making wrong guesses about caching and such.
Note the 379M number. That is the amount of data read from disk and kept in ram. When an application needs to malloc and no completely free memory, yes it will free up those pages (it ideally picks the cache least likely to be needed again). But absolutely, disk contents are kept in disk cache, but only after load. And no, memory leaks aren't hopelessly pervasive.
What preload does normally happens implicitly during boot. It's hard to demonstrate on init scripts effectively, but log into gnome right after boot, and the disk will thrash like crazy. Log out, kill every last process of that user, log in again. It will be quite dramatic. preload aims for that subsequent experience without the pain of the first.
So what preload brings is simple, and all that has to happen is simple, know which files are relevant to typical usage ahead of time, and be aggressive about 'cat file >
Linux implicitly aids this, but the user interface side still subjectively 'feels' bogged down because it won't proactively load things it doesn't know you'll need, despite the ability to derive this historical data in user space. If preload takes idle time (let's say, for example, while services with arbitrary sleeps and while waiting for username and password) and proactively gets cache populated, it is more IO work in the aggregate (disk will be hit up for things that will never be needed), but it will feel smoother out of the gate.
I feel OpenVMS needs to die. Considering the only actively maintained processor architecture for it is now Itanium, it's a great day for it to die.
Skulltrail by definition is an Intel design. There are a host of multi-socket chipsets that could do it theoretically, but Skulltrail is little more than a concerted marketing strategy around such capable parts. One interesting aspect of HT and QPI is that the planar chipsets become socket-count agnostic, just the processor you buy must support the right number of links for a multi-socket config. That said other than the '1337' factor, Skulltrail is a ludicrous waste of money. They explicitly declare it not suitable for server-class operation, and yet the only thing that currently meaningfully pushes beyond 4 cores is not to be found in the desktop space (programmers just aren't threading the intensive stuff that fine grained yet).
Intel did have a hell of a time confusing people before the concrete samples were available as to whether it was the same thing as AMD's 64-bit. They avoided using any term AMD associated with it for a time, instead tossing around ia32e and em64t and bs like that. I know some projects even baked into plans how to cope with yet another processor architecture for lack of a commitment from Intel that their 64-bit x86 compatible stuff would be the same.
Intel's hand was effectively forced because they learned their lesson from Itanium, don't screw with an incumbent variation of your flagship instruction set. With AMD's lead they would've risked yet another Itanium fiasco, so they picked the safe path and tried to PR dance around the existence of AMD's 64-bit stuff.
Itanium was an odd path in the history of Intel proving they truly thought they alone dictated the course of x86 technology. It stands in stark contrast to the history of supporting legacy all the way back to the 8086 days.
In this case, it's not the end-user or software developers being impacted, just hardware implementors who already have to do whatever the processor architecture dictates. Despite that freedom, Intel's unable to offer something that isn't obviously similar to the competing offering since it just is such a damn good idea. AMD has led some revolutionary changes in x86 architecture, while Intel has been able to follow up with evolutionary advances, fabrication, and marketing to continue eating the more significant profit margin space.
They *insist* on using non-standard stuff, just to piss off the world, while *every* other prominent OS has at its core a bourne compliant shell.
I know FrontPage had no integration with IE or MS software (other than the obvious lack of non-Windows versions, which I would count as at least a loose link with MS, just a common one), the product was a logical complement. You make a browser, having a complementary content creation offering simply makes sense. I don't recall a remotely credible/significant MS product that competed with FrontPage, so I don't see why MS would simply want to bury it. Also, FrontPage did not *fundamentally* champion OS or browser independence. It certainly could contribute to such causes, but it was possible to target IE primarily without compromising the basic nature of it. Meanwhile, BSD contributions just absolutely run against Windows without benefit to MS platforms, php can run on Windows, but MS has enough solutions they deem better, so php developers I would wager are not high on their list of resources to use as-is. Zimbra is a product that theoretically MS could subvert to being Windows platform only groupware, were it not for the Exchange offering. I know Exchange offers some sort of web interface that isn't as slick as Zimbra's. While they theoretically could add snazziness from Zimbra to their web interface, the fact is the Exchange web interface is 'good enough' and nothing really stopped MS from snazzing it up themselves before now. My guess would be they have motivation to keep the MS-only client experience 'richer' to strengthen the link between their product lines, with the web interface being considered a concession for road-warriors and mobile devices for interim access to content when Outlook is not conveniently at hand.
The issue with a number of the heavy hitters in the web space is that they are a lot more diversified technology wise than the company behind FrontPage. Any company with huge public-facing open-source usage is bound to contribute significantly to the projects they use. So instead of being consumers of MS competitor products, they are also contributing to MS competitor products in spaces where MS has been convicted as a monopolist. The direct motivation of yahoo as a weapon against google isn't much to worry about, at least less to worry about than Google's share, but the incidentals are something to worry over. It's hard for MS to conduct an acquisition these days without anti-competitive implications, whether they want to or not.
Let's say hypothetically that these genetic tests are done by people, and insurance companies offered a la carte rates (i.e. could insure for blood cancer specifically, welcome all comers willing to pay for that coverage). In this case, the customers naturally discriminate themselves, as people who have reduced risk of blood cancer would more often waive the coverage, and in aggregate the percentage of people who buy that insurance plan are quite likely to be afflicted. Either way, whether driven by the insurance companies or by the customers, rate hikes would occur. So a la carte premiums for certain prominent genetic conditions might be a way to drive the rates without technically discriminating or even knowing as companies. I wonder if the bill also prevents a la carte plans...
There are naturally given risks (genetic predispositions) which are unfair and in an certain idealistic vision, the ones covered equally at equal cost across the population (i.e. assumes equal risk of prostate cancer and everyone pays without caring about likelihood, screening used merely for early treatment), and there are voluntary lifestyle risks, like smoking, drugs, and physical activity, which could be abusive of a completely flat non-discriminatory system.
It's a whole set of rough questions, and health/life insurance companies from the very nature of dealing with life and death situations from a business perspective inevitably come off as either sinister by effectively choosing death or a poor business by doing the 'right' thing, it seems. Even if forbidden from denying coverage, they can always price the rates such that they aren't significantly cheaper than the treatments, so I see a rough path ahead regardless as tools for accurately knowing the likelihood of genetic conditions emerge.
Would they lower rates due to a clean genetic test compared to the normal now?
How long before insurance companies proactively raise rates, but then offer a discount back to normal if you provide genetic test results?
Is the bill worded such that neither penalties nor bonuses can be given out due to a genetic screen?
How much different really is it from family history, just a more accurate measure?
Insurance is all about modeling the risks for an individual based on available medical data. In *theory*, if genetic screening can increase the accuracy, then people with clean genetic situations should get decreased rates from what they pay now, while those with the dispositions carry the burden of the risk. If all goes according to the hypothetical, neither way is particularly feels 'fair'. On one hand, your rates go up because you got stuck with some genetic predisposition for heart disease that you couldn't control, that may never manifest. On the other hand, someone with a genetic disposition that will never suffer a particular ailment, will have to pay for the risk of that ailment anyway.
Of course, the chances insurance companies would *lower* any rates is slim, just jack up rates with the excuse of apparently increased risk individuals without ever acknowledging the class of reduced risk individuals.
The open source drivers have had the reliability advantage, so I'm guessing you agree with the perspective of the parent post?
I'm saying in order to get the same number of flops and using price-performance instead of straightforward performance, you must increase node count. If the processor performance/watt *was* better (I believe with the 45 nm process on Intel's side for the moment, a Xeon 2.33 quad core comes in a 50W TDP variant, for example, Barcelona comes in at 95W TDP, goes along way toward offsetting the FB-DIMM power), you still have to worry about more AC power supply inefficiencies, general power usage of extra motherboards, fans, hard drives, etc. I hear Opteron may be able to more effectively reduce power consumption when bits are idle, but if you aren't overbuilding your cluster and will always have jobs in the queue, the goal is to avoid being idle. If utilization of the cluster is consistantly under 90%, you probably overplanned and paid too much.
The FB-Dimms do suck however. Expensive, power-sucking, and so far only yields none of the promised memory throughput benefit while incurring a significant latency penalty. The only theoretical benefit achieved is that a simpler trace situation is possible (i.e. can scale out memory without a ludicrous trace design requiring many layers), but I haven't seen that leveraged in practice beyond what AMD offerings have scaled to. The other thought put forth is that PCBs could be done with fewer layers with respect to the DIMMs, but I think for other reasons the boards have to have so many layers anyway, so that could be a moot point.
And if he came from the United States, they would be whining a bit more...
One of the significant aspects of the stealth is trying to keep the exhaust temperature somewhat down. It loses a lot of power trying to keep a low infrared profile. Similar problems on intake, direct wide open intakes would also run counter to the stealthiness.
Comparing my R500 part with fglrx with an R300 part with the open source driver:
-With fglrx kernel module loaded, my laptop has not been able to suspend ever (using Ubuntu Gutsy)
-I have to do a goofy Virtual 1408x1050 resolution with fglrx to make 3D applications not look horribly corrupted. This is weird, but as long as I don't xrandr over to it, it's not a big deal, however..
-After doing above trick, fglrx shows corruption in lower right hand corner and hardware cursor if trying to do 3D apps at 1400x150 (native resolution). Have to run at 1280x960 to prevent that corruption.
-All acceleration (3D and 2D) has a horrible diagonal tearing effect.
The *ONLY* net improvement in the interval you deem 'massive' improvement is in the frames per second area. Though important, the top priority should be reliability.
Meanwhile, though much slower, the open source driver on the R300 part behaves quite in line with what I expect. I look *very* much forward to what the open source initiative ultimately yields. If AMD can cram the fglrx performance into binary blobs that leverage the open source layers for everything they get right, I would be ecstatic.
Both Opteron and Phenom were at the same B2 stepping, complete with the same L3 errata, despite the different packaging. That's why you haven't seen a Tier one vendor touch the Opterons with a 10 foot poll for a generally available product. You can bet your ass this is the reason AMD released the kernel patch so 'some customer' could proceed with a Linux Opteron deployment with B2 parts without the performance penalty nor risk of the L3 errata.
This deployment is probably where AMD focused a firesale of B2 parts, since it's nice and well controlled.