It will be very easy (a windows installer shortcut probably) to install IE and without a browser it will be difficult to install any other browser (so no real change then). But we will only know Microsoft's view on downloading the IE version when you have the No-IE version when we see the licensing. If your No-IE key works on an IE version of the OS then, yes, I think Microsoft do want users to have the pirate version if the alternative is "not Microsoft". This has always been their, unofficial, view of pirate editions after all.
But, I too will, have to install the Microsoft Website Explorer. I still need to get bugfixes from the Microsoft website after all.
You really don't want to go there, my main linux system has been the same OS since '92 (or '93) where it started as SLS1.02. It was in-place upgraded to debian several years later and hasn't been reinstalled to this day.
At first the machine was upgraded around it, until the floppy disk drive was the only original component. Later, the disk has been moved from machine to machine, or the filesystem copied from disk to disk as time passes. It's just recently been moved to a machine with eight cores and 6TB of disk and flash. It started on a 486, I think it was the machine with the Hippo DCA motherboard.
I have done clean installs on other machines and added packages to the main machine because of it, but there's never been a need to reinstall.
BTW: My home directory predates Linux with (a few) honest mtimes over 7000 days ago! (Everything over 9000 is in early 1970)
IBM's IFL is a way of adding processors to a System-z machine that can only be used to run Linux VMs, not the other OS VM's that a System-z can run. This has the advantage of significantly lower costs as this "Integrated Facility for Linux" is often not considered an extra processor for license pricing, after all it's can't run real software...
Ok, so every time you start a new GUI program, you have to immediatly tell your local display client...
Of course not, none of the examples I gave above works like that
... telnet or ssh or VNC or MS Remote desktop or Citrix seamless windows...
they all send data down the same connection. Either through an already open file descriptor or a kernel mediated virtual device.
VNC is probably the closest simulation, you connect to the VNC server (on the server machine) and it gives data to show on your client display. The X clients connect to it through a unix domain socket (which is secured). Unfortunately, plain VNC has no encryption, nor does it use unix domain sockets to listen for X.:-(
If the guy with the cancer cure isn't making backups his "cure" is gonna be just a careless.
How many time do we have to tell you, it isn't a backup until it's disconnected from the machine, it isn't a safe backup until it's with the neighbour ACROSS the street. (or at least in the car boot (trunk) on the street).
Yes I get it, the TCP/IP connection connects to the machine with the screen, so the machine with the screen is the server in X.
BUT, X is the wrong way round. NOTHING else connects a display with a process that way and even with X the first connection is FROM the display TO the CPU server and tell the CPU where to find the X server. So every remote X connection actually consists of two connects one from the DISPLAY TO the CPU (usually cached and often an XDM connection but it can be a telnet) the second is FROM the CPU TO the DISPLAY.
AND this leads to the ridiculous situation of the server machine having to logon to the client machine (with an MIT magic cookie) to send back the response to a command received through an already open connection!
This is really noticeable with "ssh -X" where the initial connection is the SSH connect but SSH has to provide an (insecure) open port for the connection BACK to the X server to send X over secure connection.
But, X is the wrong way around, you should have a client running on the local machine that connects to the remote machine and provides it with a remote display. Like telnet or ssh or VNC or MS Remote desktop or Citrix seamless windows or "ssh -X"!
In fact X is that ONLY one that puts the server next to the display with the security implications inherent in that.
The Firefox on Linux issue is well known, it's caused by the ext2/3 drivers converting an fsync() call into a sync() call in the sqlite library.
The workaround is to move the entire Firefox profile onto a ramdisk, copied to disk and from disk at appropriate times of course. It works well for me with loads of tabs on an old 1.3GHz minilaptop, with only flash (as usual) causing problems.
As Linux almost never crashes this works fine. There are even distributions (puppy) that work like this for everything.
That's not been forgotten, that's part of the problem, people do remember how much of a pain in the arse the upgrade was and they've had years to sit on the "everything is working just fine" side of the fence. They don't want to go back to the bad old days and nothing Microsoft is providing with these releases^H^H^H^H^H^H^H^H^H escapes is convincing people that the return of the pain is worth it. Businesses especially have had a few years off the upgrade treadmill and they're loving it.
Who knows, maybe Vista even precipitated recent economic changes; lots of businesses suddenly reallocating large chunks of cash to Windows upgrade projects on an ongoing basis with requisite drops in profitability predictions. It sure looks possible.
That is ALL versions of Windows 2k. W2k Professional can use exactly 4Gb of RAM independent of how much is allocated to the video card. As could XP before service pack 2.
The simple fact is the x86 processors allow any OS to use the entire of memory in both 64bit and 32bit modes.
I have 12Gb of RAM and a 32bit OS, it's all usable.
Windows 2000, 32bit only, could use 64Gb of memory. We have some 32bit Windows 2003 machines with 8Gb of memory. But there's one application that needs 64bit; MS-SQL works a lot better with a 64bit userspace.
That's really the point. There are very few applications that need a 64bit userspace, they're usually pretty easy to recognise, they're the ones with multi-gigabyte data files. And that's the difference between this transition and the 16bit->32bit one. In the previous transition there was so much pain in staying with 16bit for the majority of applications; eg a book can easily contain 60000 words so a 16bit wordprocessor has to be able to swap chapters (or use "far pointers" in a bastard crossbreed mix of 16 and 32bits). What's more is that a 64kb program is only a few thousand lines of code, easy to exceed. To exceed a 32bit program you need over 100 million lines of code, that's a huge 'application'.
This switch over is being entirely driven by Microsoft, they have reduced their artificial limit to 4Gb of address space, they are saying you MUST have 64bit. If you look at Linux, it has no problems with 64bit but very few people use it, they don't need it. I believe the reason Microsoft are pushing 64bit so hard is that they still only want to support one real version of their OS, it can't be 32bit because there are a couple of Microsoft applications that benefit (erm; I can only think of one.. MS-SQL) from the larger address space so everybody must switch to 64bit for Microsoft.
No, you currently avoid it in your applications by defragmenting, in effect paying the price of slow seeks when you're not waiting for the machine. In the worst case you will end up doing defragmentation all the time...
For applications that pressure the drives, ie databases, seek times are very, very important. A modern database system will tend to have multiple drives (doubling the number of drives halves the effective seek time... IF you're lucky) and only uses the start of larger drives (reduces the seek time to little more than the rotational latency, the rotational latency of a 15k drive is 4ms). But even with this the seek times dominate the performance.
Actual numbers: On a single 15k drive, if you manage to get 64k reads and writes it's just under 16Mbytes/s but an 8k block size gets you only TWO megabytes per second! Just imagine how much difference a flash drive that manages 200Mb/s random can make, even 40Mb/s is a massive improvement.
This seek time problem is why the first database optimisation for ms-sql is to move the log file onto a distinct spindle from the database file.
You're pretty close, except it isn't the magnetic coating that gets flung off nowadays. It's the glass or metal disks themselves that start to ooze toward the edge of the drive.
Then there's the momentum, if you're holding a running 15k drive and it's bearing seizes it has a very good chance of jumping out of your hand. (I've had that happen with a 7k2 drive, it didn't have much chance of escaping but it was very noticeable) Much more and it'll start damaging equipment around it.
Both of these are good reasons for there not being any 5.25" hard drives anymore.
Anyway huge storage isn't useless with slow access, it's just that it's "nearline" storage rather than "online" storage.
Have you seen the math? That 'few million' cycles with perfect wear leveling is something like 70-100 years of continuous use. Intel's guarantees on their drives are on a par with hard drives right now and as far as we can see they are leaving a very large amount of headroom.
How long until they fail isn't really a serious concern at this point, the answer is 'long enough' IFF you are planning to replace them on "runs out day"+1. The real question is how they will fail when that replacement is postponed too long. There are theories, and experience with old flash drives but these are very new designs and even the physics is being pushed into new regions. So people expect the failures to be nicer than hard drives but most are not really ready to bet the farm on the drives just yet.
The additional linear speed is more or less worthless if you're talking about databases. The only thing that wants it is backup, and that's limited by the tape drive. For random access you're often lucky if you get a couple of megabytes per second.
For random access on disks a raid10 array is what you want, raid5 is crap because random writes will almost certainly have the "small write penalty" of 50% or more.
The "enterprise" versions of the flash drives are very much being looked at right now. Their problem is that real world reliability and failure mode data is still in very short supply. That make people worried about putting them into live systems, but development, test and secondary systems are getting these drives with serious performance hikes.
Slashdot Mirror
Your "BAs" asked the wrong question, it should have been "What do you need the solution to do". Nobody needs unicorn farts.
You then lock down that fixed specification for the fixed price.
When the specification changes so does the price.
Or you can work time & materials, but that needs trust.
It will be very easy (a windows installer shortcut probably) to install IE and without a browser it will be difficult to install any other browser (so no real change then). But we will only know Microsoft's view on downloading the IE version when you have the No-IE version when we see the licensing. If your No-IE key works on an IE version of the OS then, yes, I think Microsoft do want users to have the pirate version if the alternative is "not Microsoft". This has always been their, unofficial, view of pirate editions after all.
But, I too will, have to install the Microsoft Website Explorer. I still need to get bugfixes from the Microsoft website after all.
It's called Off by One.
You really don't want to go there, my main linux system has been the same OS since '92 (or '93) where it started as SLS1.02. It was in-place upgraded to debian several years later and hasn't been reinstalled to this day.
At first the machine was upgraded around it, until the floppy disk drive was the only original component. Later, the disk has been moved from machine to machine, or the filesystem copied from disk to disk as time passes. It's just recently been moved to a machine with eight cores and 6TB of disk and flash. It started on a 486, I think it was the machine with the Hippo DCA motherboard.
I have done clean installs on other machines and added packages to the main machine because of it, but there's never been a need to reinstall.
BTW: My home directory predates Linux with (a few) honest mtimes over 7000 days ago! (Everything over 9000 is in early 1970)
IBM's IFL is a way of adding processors to a System-z machine that can only be used to run Linux VMs, not the other OS VM's that a System-z can run. This has the advantage of significantly lower costs as this "Integrated Facility for Linux" is often not considered an extra processor for license pricing, after all it's can't run real software...
Tell me where you get caught ...
You have just been hacked, your user id and password are now property of the blackhats.
Yes it is.
Telnet server, listens for telnet connections.
XDM server, listening for the "X11 Display Manager Control Protocol".
Ok, so every time you start a new GUI program, you have to immediatly tell your local display client ...
Of course not, none of the examples I gave above works like that
... telnet or ssh or VNC or MS Remote desktop or Citrix seamless windows ...
they all send data down the same connection. Either through an already open file descriptor or a kernel mediated virtual device.
VNC is probably the closest simulation, you connect to the VNC server (on the server machine) and it gives data to show on your client display. The X clients connect to it through a unix domain socket (which is secured). Unfortunately, plain VNC has no encryption, nor does it use unix domain sockets to listen for X. :-(
If the guy with the cancer cure isn't making backups his "cure" is gonna be just a careless.
How many time do we have to tell you, it isn't a backup until it's disconnected from the machine, it isn't a safe backup until it's with the neighbour ACROSS the street. (or at least in the car boot (trunk) on the street).
Yes I get it, the TCP/IP connection connects to the machine with the screen, so the machine with the screen is the server in X.
BUT, X is the wrong way round. NOTHING else connects a display with a process that way and even with X the first connection is FROM the display TO the CPU server and tell the CPU where to find the X server. So every remote X connection actually consists of two connects one from the DISPLAY TO the CPU (usually cached and often an XDM connection but it can be a telnet) the second is FROM the CPU TO the DISPLAY.
AND this leads to the ridiculous situation of the server machine having to logon to the client machine (with an MIT magic cookie) to send back the response to a command received through an already open connection!
This is really noticeable with "ssh -X" where the initial connection is the SSH connect but SSH has to provide an (insecure) open port for the connection BACK to the X server to send X over secure connection.
HA HA HA HA HA HA HA HA HA.
You poor deluded Microserf.
It was COMPUTER GAMES that got computers to the home.
Only then did, spreadsheets, word processing and the internet sneak in. In every one of those cases Microsoft was late to the party.
For the way that X works it's correct.
But, X is the wrong way around, you should have a client running on the local machine that connects to the remote machine and provides it with a remote display. Like telnet or ssh or VNC or MS Remote desktop or Citrix seamless windows or "ssh -X"!
In fact X is that ONLY one that puts the server next to the display with the security implications inherent in that.
Somebody's been looking at XKCD ... http://xkcd.com/303/
The Firefox on Linux issue is well known, it's caused by the ext2/3 drivers converting an fsync() call into a sync() call in the sqlite library.
The workaround is to move the entire Firefox profile onto a ramdisk, copied to disk and from disk at appropriate times of course. It works well for me with loads of tabs on an old 1.3GHz minilaptop, with only flash (as usual) causing problems.
As Linux almost never crashes this works fine. There are even distributions (puppy) that work like this for everything.
That's not been forgotten, that's part of the problem, people do remember how much of a pain in the arse the upgrade was and they've had years to sit on the "everything is working just fine" side of the fence. They don't want to go back to the bad old days and nothing Microsoft is providing with these releases^H^H^H^H^H^H^H^H^H escapes is convincing people that the return of the pain is worth it. Businesses especially have had a few years off the upgrade treadmill and they're loving it.
Who knows, maybe Vista even precipitated recent economic changes; lots of businesses suddenly reallocating large chunks of cash to Windows upgrade projects on an ongoing basis with requisite drops in profitability predictions. It sure looks possible.
Easy actually, just install Debian, about v3.0 IIRC.
Support wouldn't be much of a problem either, but you would have to pay for it.
And probably get some serious earache about upgrading, "it's free after all".
That is ALL versions of Windows 2k. W2k Professional can use exactly 4Gb of RAM independent of how much is allocated to the video card. As could XP before service pack 2.
The simple fact is the x86 processors allow any OS to use the entire of memory in both 64bit and 32bit modes.
I have 12Gb of RAM and a 32bit OS, it's all usable.
Windows 2000, 32bit only, could use 64Gb of memory. We have some 32bit Windows 2003 machines with 8Gb of memory. But there's one application that needs 64bit; MS-SQL works a lot better with a 64bit userspace.
That's really the point. There are very few applications that need a 64bit userspace, they're usually pretty easy to recognise, they're the ones with multi-gigabyte data files. And that's the difference between this transition and the 16bit->32bit one. In the previous transition there was so much pain in staying with 16bit for the majority of applications; eg a book can easily contain 60000 words so a 16bit wordprocessor has to be able to swap chapters (or use "far pointers" in a bastard crossbreed mix of 16 and 32bits). What's more is that a 64kb program is only a few thousand lines of code, easy to exceed. To exceed a 32bit program you need over 100 million lines of code, that's a huge 'application'.
This switch over is being entirely driven by Microsoft, they have reduced their artificial limit to 4Gb of address space, they are saying you MUST have 64bit. If you look at Linux, it has no problems with 64bit but very few people use it, they don't need it. I believe the reason Microsoft are pushing 64bit so hard is that they still only want to support one real version of their OS, it can't be 32bit because there are a couple of Microsoft applications that benefit (erm; I can only think of one .. MS-SQL) from the larger address space so everybody must switch to 64bit for Microsoft.
If you were using XP-32bit sp1 you would lose nothing; XP-32bit sp1 can use 1Gb video + 4Gb RAM + 1Gb PCI without any problems.
Only with XP-32bit sp2 did Microsoft disable use of RAM over 4Gb
Of course Office 2007 won't install on XP-32bit sp1.
No, you currently avoid it in your applications by defragmenting, in effect paying the price of slow seeks when you're not waiting for the machine. In the worst case you will end up doing defragmentation all the time ...
For applications that pressure the drives, ie databases, seek times are very, very important. A modern database system will tend to have multiple drives (doubling the number of drives halves the effective seek time ... IF you're lucky) and only uses the start of larger drives (reduces the seek time to little more than the rotational latency, the rotational latency of a 15k drive is 4ms). But even with this the seek times dominate the performance.
Actual numbers: On a single 15k drive, if you manage to get 64k reads and writes it's just under 16Mbytes/s but an 8k block size gets you only TWO megabytes per second! Just imagine how much difference a flash drive that manages 200Mb/s random can make, even 40Mb/s is a massive improvement.
This seek time problem is why the first database optimisation for ms-sql is to move the log file onto a distinct spindle from the database file.
You're pretty close, except it isn't the magnetic coating that gets flung off nowadays. It's the glass or metal disks themselves that start to ooze toward the edge of the drive.
Then there's the momentum, if you're holding a running 15k drive and it's bearing seizes it has a very good chance of jumping out of your hand. (I've had that happen with a 7k2 drive, it didn't have much chance of escaping but it was very noticeable) Much more and it'll start damaging equipment around it.
Both of these are good reasons for there not being any 5.25" hard drives anymore.
Anyway huge storage isn't useless with slow access, it's just that it's "nearline" storage rather than "online" storage.
Free will return memory to the operating system if it can find large chunks.
In your visual, rooms can be removed and the land released as long as there isn't a pipe left in the ground connecting to still existing rooms.
Firefox has become a lot better at doing this.
Have you seen the math? That 'few million' cycles with perfect wear leveling is something like 70-100 years of continuous use. Intel's guarantees on their drives are on a par with hard drives right now and as far as we can see they are leaving a very large amount of headroom.
How long until they fail isn't really a serious concern at this point, the answer is 'long enough' IFF you are planning to replace them on "runs out day"+1. The real question is how they will fail when that replacement is postponed too long. There are theories, and experience with old flash drives but these are very new designs and even the physics is being pushed into new regions. So people expect the failures to be nicer than hard drives but most are not really ready to bet the farm on the drives just yet.
The additional linear speed is more or less worthless if you're talking about databases. The only thing that wants it is backup, and that's limited by the tape drive. For random access you're often lucky if you get a couple of megabytes per second.
For random access on disks a raid10 array is what you want, raid5 is crap because random writes will almost certainly have the "small write penalty" of 50% or more.
The "enterprise" versions of the flash drives are very much being looked at right now. Their problem is that real world reliability and failure mode data is still in very short supply. That make people worried about putting them into live systems, but development, test and secondary systems are getting these drives with serious performance hikes.