Dual stack will not buy us any time, because it does not affect the number of routeable (public) IPv4 addresses required. The only thing dual stack expedites is some future day when we (effectively) cut off all the IPv4 only hosts from the Internet (or make them use v4v6 NAT).
If the existing standard couldn't handle it, then that standard needed to be changed so it could have.
That's the problem, IPv4 had a defective, fixed address length design from the very beginning, and the only way to fix it would require a solution that was not interoperable with IPv4 - not without NAT and ALGs at any rate.
It would be nice if the IPv6 designers learned from this mistake and designed a variable length address based protocol that wouldn't have the same inevitable obsolescence that IPv4 has, but that is a secondary issue. The *big* mistake was the decision to use (short) fixed length addresses with IPv4 in the first place.
No someone come in and explain to me why this cant be done with network addresses?
It can be, it just significantly complicates hardware routing, and that is why a VLA scheme was rejected for IPv6. A most unfortunate decision, in my opinion.
Circuit switched networks do not have this problem because a call is routed (set up) once and that route is preserved until the call terminates. Where with packet switched networks, the route can potentially change for every packet at every hop. Route lookups for packet switched networks have to be several orders of magnitude more efficient as a consequence. Such lookups also allow packet switched networks to handle an arbitrary number of connections or "calls".
Nobody in 1995 or thereabouts wanted to do VLA routing in hardware, so the IETF mostly just made IPv6 a bigger and better version of IPv4, complete with zero interoperability.
That is no doubt the best way to engage in productive conversation - imagine what your interlocutor believes and call him names. No doubt I am preoccupied from morning to midnight with the lunatic operations of a deranged mind. When I am not plotting to steal children's lollipops and swindle their parents out of their life savings, of course.
It doesn't matter how many IPv6 addresses you have as long as there remain IPv4 only clients that cannot access them. The only way the transition is going to be gradual is with a whole host of v4v6 and v6v4 NAT and application layer gateway devices.
The main people that need to run such devices are the end user ISPs. Until they do, no IPv4 only client will ever be able to reach a IPv6 only server. SNI aside, every publicly addressable IPv6 server will require the same number of IPv4 addresses as it does now. Dual stacking will not save an iota of IPv4 address space until IPv4 clients are practically required to use some sort of v4v6 NAT or ALG to access the rest of the (IPv6) Internet. To say nothing of the v4v4 or v6v4 NAT required so that every last ISP client doesn't require a routable IPv4 address as well.
I have have seen the future, and it is NAT until the cows come home (unfortunately). All this dual stacking is a worthless exercise without the v4v6 and v6v4 NAT (or ALGs) necessary so that the number of IPv4 addresses required actually goes down. I sure hope somebody is reserving the address space so that v4v6 NAT is actually practical, because we are going to need it for a long time, and the IPv4->IPv6 transition won't happen without it.
The Federal Reserve System was instituted before the Great Depression.
Yes. However, its power was limited at best prior to the change from the gold standard to a fiat currency, a transition that started in the Great Depression with a nearly 2:1 devaluation of the dollar (preceded by making all private gold holdings temporarily illegal), and completed with the final abandonment of the gold standard nearly a half century later.
Since the latter date, the only thing that ultimately sustains the value of the dollar is the Fed's motivation not to print too many of them, a motivation which more often than not goes in the other direction. Hence the decade of 10-12% inflation that immediately followed the abandonment of the gold standard in August 1971. All we need to do to solve the unemployment problem is to print a sufficient amount of money, right?
The IPv6 spec reserves space for the entire IPv4 network, making translation between the two a snap
That reservation is more or less a joke. It is great (in principle) if you want to send a packet from an IPv6 host to an IPv4 host. But how does the IPv4 host send a reply back? The short answer is, it can't. It can't because there (obviously) is no static mapping of IPv6 addresses to IPv4 address. There is no way to cleanly fold 128 bits into 32.
That means that there are only three basic ways for IPv4 hosts and IPv6 hosts to interoperate: v4v6 network address transation (NAT), application layer gateways (ALGs), and dual stacks. Presumably, the main point of IPv6 is to avoid NAT, so v4v6 NAT is a relatively undesirable solution. Application layer gateways for every external communication protocol are even more problematic. That leaves dual stacking, which is a way of solving the IPv4 IPv6 interoperability problem by conceding the plain truth - that IPv4 and IPv6 are not interoperable and never will be.
The only way to avoid NAT or ALGs is for every last Internet connected device on the planet to be dual stacked. That is going to take at least a decade. There will probably be lots of strange NAT and ALG solutions in between.
The more interesting question is if there were a market for IPv4 addresses, such that organizations had a significant economic incentive to renumber and minimize the number of IPv4 addresses they used (and the size of the routing tables necessary to reach them) how long could we survive on the current system? I would guess a half century at least.
Given the likelihood of this sort of economically motivated renumbering effort once centrally allocated blocks of IPv4 addresses run out, at what point does the overhead of the necessary network address translation outweigh the cost of administering a parallel IPv6 network that reaches nearly every device on the planet, in addition to the IPv4 network that is already there and which must remain there indefinitely (down to the level of each individual PC) in the absence of all the alternative v4v6 NAT and ALG devices we are trying to avoid in the first place?
Essentially IPv4 has a defective design, and IPv6 has exactly the same defect, with a slightly larger address space. Slightly because hierarchical allocation will use up those initial 64 network addressing bits in a big hurry. IPv6 is no more than a stop gap for a some sort of variable length address (VLA) scheme, the only alternative that that isn't essentially an exercise in planned obsolescence.
Comparable features? Yes. Comparable performance, not without hardware support. What you need in general is a (managed) switch on a NIC. Intel has hardware switch support on their latest (82576,82599 based) server NICs right now, although I don't think there is much in the way of switch function manageability. Most of the focus is around hardware NIC virtualization, so that network traffic doesn't have to be handled by the hypervisor.
There is nothing new about software switches. Linux has had one for years. The nice part about the Cisco software switch is the addition of all the extra management and filtering features.
The problem with software switches (or bridges) is that they aren't all that fast - anything in the data path that can't be offloaded to some sort of hardware is going to be relatively slow compared to a hardware switch. In fact, some of the latest Intel server NICs have built in hardware switches for inter-VM communications. I have no idea whether the Cisco VMware switch is able to leverage that. If not, it is going to be a *lot* slower. One might well wonder why Cisco doesn't get into the virtual Ethernet switch on a card market itself.
Do you really want to have to reconfigure and possibly readdress everything just because you are moving a vm between host boxes to cope with demand?
No. What you do is use dynamic route updates so that if the the VM is located on the same host, IP traffic for the target VM is logically routed through the non-Ethernet virtual network. It doesn't even have to be numbered.
Without hardware support, one could tweak the TCP stack to check if the destination is associated with a local VM and then ask the supervisor to "DMA" the whole TCP send into the receive buffers of the target TCP socket, or even better into the target application buffer (assuming there is a pending read). If the VM is relocated while there is still data waiting to be sent, the internal route will go away, and the remaining data can be transmitted through the physical ethernet interface as usual.
The end game for this is clearly not running all inter-VM traffic out to an external switch and then making a hairpin turn and sending it all back to the host. That is a workaround at best - it is a waste of hardware, a waste of energy, and a waste of bandwidth.
One way or another this is going to be done on the host - either with appropriately enhanced switching support on the NIC or other advances in the CPU and the networking stack. Server CPUs should have inter-VM networking capability built into hardware, not an inter-VM Ethernet switch, but rather something more like an inter-VM RDMA engine. There is no point in using "Ethernet" to communicate between VMs on the same host other than portability.
Breaking inter-VM communications down into little itty bitty packets, running them one by one through a virtual bridge table without the benefit of content addressable memory, and then back up through a virtual ethernet interface is not a particularly efficient use of resources.
As other commenters have noted, there is no way this figure applies to Sandy City proper. Sandy does not have a UTOPIA deployment. The real problem, though, is that the Salt Lake valley has a large number of relatively small cities all served by the same local ISPs, and there is no reliable way that Akamai can tell which users are in which local cities to that level of accuracy. The IP addresses don't carry any more information than (roughly) somewhere in the Salt Lake valley. One would have to be in a different for that difference to start to be visible.
Salt Lake City proper isn't a UTOPIA city either, but there are several cities in the valley which are, notably West Valley City, Midvale, and Murray. So what appears is that Akamai estimated the coverage footprint of a local content distribution node (probably the one at Xmission) and estimated that the center of the footprint was in Sandy. Even though no one in Sandy City proper has that kind of bandwidth, people with UTOPIA connection (and there are many in the general vicinity) often do - 50 Mbit/s UTOPIA service is readily available, and inexpensively at that if you live in one of the original UTOPIA cities.
Xmission has standard residential UTOPIA bandwidths of 15 Mbit/s and 50 Mbit/s - up and down. The end user links are all 100 Mbit/s Ethernet (over fiber), and you can get a 100 Mbit/s "business" connection if you want.
Hardly. The public school system is not a free market, where for more money you can attract higher levels of talent (and sanity). Paying more means paying the same people higher salaries, depending not on demonstrated ability, but rather the number of years they have been in the system. That is what the union system is all about - not talent, but rather seniority. The whole idea is that teachers (or assembly line workers or whoever) are interchangeable cogs in a wheel, not real individuals with different talents and abilities deserving of individual treatment.
If we want the school system to improve, we should quit running it like the drivers license division (and vice versa).
Journaling, and every other filesystem, has exactly the same problem. If consistence is required, YOU MUST DISABLE THE CACHE
Not true - it depends on the filesystem. It is true with journaling filesystems that either a write barrier or a cache flush (that are actually honored by the disk subsystem) must be issued after every journal commit to maintain metadata consistency in the event of a power loss.
The only disadvantage of that is that it really slows down a strict implementation of fsync, unless you have a battery backed RAID controller or place the journal on some sort of fast persistent storage like an SSD. The real question is how long will it be before spinning hard drives have a little bit of flash inside them so that they can internally journal all disk writes and honor "cache flush" commands with the alacrity of (much smaller and more expensive) SSDs.
I never send hard drives in for warranty service or replacement. If they have confidential data on them, I beat them up with a hammer and throw them away. If the drives actually work, and aren't hopelessly old, I put them on a shelf instead.
As far as encrypting data at the block level is concerned, I doubt it will become prevalent until it is a standard feature of every common operating system. Even then there will be many systems that won't use it without hardware encryption support, because it will be too slow.
Not many companies (big or small) have figured it out. FOSS + Commercial success is tough.
Tough yes. Tougher than trying to gain market dominance of a good (read: highly profitable) size niche of the proprietary software business, not so much. Aversion to vendor lock-in and concerns about staying power are a big problem for small proprietary software companies.
The advantage of open source businesses is that startups can be successful while smaller, which means much less capital is required. A small group of open source software businesses that contribute to the same software product form sort of a virtual corporation that is much easier to get established and get the core product rolling than with a real one. Each of the feeder businesses just needs to specialize in a different niche.
The only trojan horse infection I have had in the past decade was due to visting a "security" web site that exploited a Java vulnerability. I use XP for work, and never run as an administrator anymore, unless I need to install software. In XP it is fundamentally unsafe.
I imagine running as limited user all the time seriously reduces the impact of Adobe Reader vulnerabilities like this, among others.
PostgreSQL starting storing NUMERIC columns in base 10000 six or seven years ago. A nice trick, but not exactly rocket science. If you have a high school level education in computer science, you should know how to do stuff like this. Maybe that is what the patent examiners need.
Win 95 had worse problems than Mac System 7, but for different reasons, mostly backward compatibility with DOS programs.
However, it was technically superior in other ways: preemptive multitasking, memory protection, and virtual memory. The big problem on non-Internet connected systems was primarily bad device drivers. The whole PC world (ISVs and most Microsoft employees included) had very little experience dealing with the complexity of a modern operating system, and in the area of device drivers it was rather apparent. I once spent three days just getting a 3COM Ethernet card to install correctly.
Of course the other problem was Microsoft's incredibly cavalier attitude to personal computer security. That was fine until the day the Internet exploded upon the scene, which happened at about the same time Windows 95 was released, in part because (IIRC correctly) it was the first common personal computer OS that included TCP/IP support, certainly the first common one where nearly everyone used it.
This is an idle pastime for me. No doubt you have better things to do.
I agree the "convention" changed among a large number of PC users who couldn't tell the difference between a glorified disk driver and an operating system, and the unfortunate name clash between "DOS" and "OS".
I will grant that the Mac system software was ten to twenty times as sophisticated as MS DOS ever was. Microsoft didn't come close to catching up (in their own products) until the release of Windows 95.
Yes, because the *convention* is already established and it's not that.
Only among the historically uninformed. No UNIX or VMS guy from the 1980s would consider MS-DOS an operating system. A system for operating disks, sure, but not a general purpose "operating system". As I said, that is why it was called a "Disk Operating System", not an "operating system". The serious system guys would laugh if you called it that.
MS-DOS is barely more sophisticated than Apple DOS, and believe me, *no one* called Apple DOS an "operating system". Apple itself didn't call the Mac system software an operating system up through and including System 7. Not "OS 7" but "System 7". Apple didn't start referring to their system software as an "OS" until 1996 or so, with the later versions of what was System 7, renamed "Mac OS 7.6" or thereabouts.
If Apple users needed a real (preemptive, multi-user, etc) operating system what they sold them was "A/UX", Apple's version of Unix. You simply couldn't make a general purpose server out of Mac anything until Mac OS X. Of course you wouldn't want to use an Amiga back then for a general purpose server either, even though it was capable of it.
I'm sorry, I think you care a lot more about this subject than I do. Is there any truth to the question of whether (fill in the blank) is an operating system? It is just a matter of convention. Hardly more than a matter of idle curiosity.
In my opinion, the world would be infinitesimally better off if we adopted the convention that operating systems actually operate more than one non-trivial program at once, and multitask between them on an equal basis. No doubt you disagree.
Wikipedia, for example, lists MS-DOS as an operating system
I would hesitate to consider Wikipedia an authority on anything. That aside, where do you draw the line? Is a BIOS an operating system? A device driver? A boot ROM? What about a CPU? Is a CPU an operating system? I can run programs on it, can't I?
Take the Apple II for example. When the Apple II first came out, floppy drives were expensive and rare. So you could load and save from audio tape instead, a function that took up a couple hundred bytes of the 2K monitor ROM.
Assuming I don't need BASIC, I turn the computer on, enter a monitor command to load a program from cassette tape, press play on the tape recorder, wait a few minutes, and then enter a command to start the program at the load address. The program, once loaded, makes absolutely no use of any of the code in ROM, until it terminates and back comes the monitor prompt.
So the question is: Was the Apple II monitor an operating system? It could save, load, and run files from tape, right?
(By the way, the only thing that makes notepad.exe on Windows an application and the Notepad desk accessory on the Mac a "desk accessory" is a distinction that the Mac itself makes. If desk accessories could do everything that applications could do, and in the same way they did it, no one would care. "Mac desk accessory" and "Mac application" would be a distinction without a difference, sort of like "BIOS" and "Boot ROM".)
It's fine to use fixed memory locations if they not application specific. The problem with the Mac is there were hundreds of variables at low, fixed, global addresses that carried critical state for the running application - or at least with application specific state and system level state so intermixed it was dangerous to make the distinction.
Apple could have avoided this problem by doing something as simple as using standard offsets from a base register. Instead, you got the equivalent of having a 4KB register set that had to be saved and restored to let another application run safely, once letting another application run was possible, of course.
There is one safe way to live without an MMU of course, and that is for the entire system to run something like a restricted JVM. Microsoft is trying to do that, with their Singularity research project (albeit with C#). Personally, I don't think it will ever work unless they drop the idea of a kernel that uses a tracing garbage collector. Stop the world just isn't going to fly in the long run. Reference counting maybe.
Slashdot Mirror
Dual stack will not buy us any time, because it does not affect the number of routeable (public) IPv4 addresses required. The only thing dual stack expedites is some future day when we (effectively) cut off all the IPv4 only hosts from the Internet (or make them use v4v6 NAT).
If the existing standard couldn't handle it, then that standard needed to be changed so it could have.
That's the problem, IPv4 had a defective, fixed address length design from the very beginning, and the only way to fix it would require a solution that was not interoperable with IPv4 - not without NAT and ALGs at any rate.
It would be nice if the IPv6 designers learned from this mistake and designed a variable length address based protocol that wouldn't have the same inevitable obsolescence that IPv4 has, but that is a secondary issue. The *big* mistake was the decision to use (short) fixed length addresses with IPv4 in the first place.
No someone come in and explain to me why this cant be done with network addresses?
It can be, it just significantly complicates hardware routing, and that is why a VLA scheme was rejected for IPv6. A most unfortunate decision, in my opinion.
Circuit switched networks do not have this problem because a call is routed (set up) once and that route is preserved until the call terminates. Where with packet switched networks, the route can potentially change for every packet at every hop. Route lookups for packet switched networks have to be several orders of magnitude more efficient as a consequence. Such lookups also allow packet switched networks to handle an arbitrary number of connections or "calls".
Nobody in 1995 or thereabouts wanted to do VLA routing in hardware, so the IETF mostly just made IPv6 a bigger and better version of IPv4, complete with zero interoperability.
That is no doubt the best way to engage in productive conversation - imagine what your interlocutor believes and call him names. No doubt I am preoccupied from morning to midnight with the lunatic operations of a deranged mind. When I am not plotting to steal children's lollipops and swindle their parents out of their life savings, of course.
It doesn't matter how many IPv6 addresses you have as long as there remain IPv4 only clients that cannot access them. The only way the transition is going to be gradual is with a whole host of v4v6 and v6v4 NAT and application layer gateway devices.
The main people that need to run such devices are the end user ISPs. Until they do, no IPv4 only client will ever be able to reach a IPv6 only server. SNI aside, every publicly addressable IPv6 server will require the same number of IPv4 addresses as it does now. Dual stacking will not save an iota of IPv4 address space until IPv4 clients are practically required to use some sort of v4v6 NAT or ALG to access the rest of the (IPv6) Internet. To say nothing of the v4v4 or v6v4 NAT required so that every last ISP client doesn't require a routable IPv4 address as well.
I have have seen the future, and it is NAT until the cows come home (unfortunately). All this dual stacking is a worthless exercise without the v4v6 and v6v4 NAT (or ALGs) necessary so that the number of IPv4 addresses required actually goes down. I sure hope somebody is reserving the address space so that v4v6 NAT is actually practical, because we are going to need it for a long time, and the IPv4->IPv6 transition won't happen without it.
The Federal Reserve System was instituted before the Great Depression.
Yes. However, its power was limited at best prior to the change from the gold standard to a fiat currency, a transition that started in the Great Depression with a nearly 2:1 devaluation of the dollar (preceded by making all private gold holdings temporarily illegal), and completed with the final abandonment of the gold standard nearly a half century later.
Since the latter date, the only thing that ultimately sustains the value of the dollar is the Fed's motivation not to print too many of them, a motivation which more often than not goes in the other direction. Hence the decade of 10-12% inflation that immediately followed the abandonment of the gold standard in August 1971. All we need to do to solve the unemployment problem is to print a sufficient amount of money, right?
The IPv6 spec reserves space for the entire IPv4 network, making translation between the two a snap
That reservation is more or less a joke. It is great (in principle) if you want to send a packet from an IPv6 host to an IPv4 host. But how does the IPv4 host send a reply back? The short answer is, it can't. It can't because there (obviously) is no static mapping of IPv6 addresses to IPv4 address. There is no way to cleanly fold 128 bits into 32.
That means that there are only three basic ways for IPv4 hosts and IPv6 hosts to interoperate: v4v6 network address transation (NAT), application layer gateways (ALGs), and dual stacks. Presumably, the main point of IPv6 is to avoid NAT, so v4v6 NAT is a relatively undesirable solution. Application layer gateways for every external communication protocol are even more problematic. That leaves dual stacking, which is a way of solving the IPv4 IPv6 interoperability problem by conceding the plain truth - that IPv4 and IPv6 are not interoperable and never will be.
The only way to avoid NAT or ALGs is for every last Internet connected device on the planet to be dual stacked. That is going to take at least a decade. There will probably be lots of strange NAT and ALG solutions in between.
The more interesting question is if there were a market for IPv4 addresses, such that organizations had a significant economic incentive to renumber and minimize the number of IPv4 addresses they used (and the size of the routing tables necessary to reach them) how long could we survive on the current system? I would guess a half century at least.
Given the likelihood of this sort of economically motivated renumbering effort once centrally allocated blocks of IPv4 addresses run out, at what point does the overhead of the necessary network address translation outweigh the cost of administering a parallel IPv6 network that reaches nearly every device on the planet, in addition to the IPv4 network that is already there and which must remain there indefinitely (down to the level of each individual PC) in the absence of all the alternative v4v6 NAT and ALG devices we are trying to avoid in the first place?
Essentially IPv4 has a defective design, and IPv6 has exactly the same defect, with a slightly larger address space. Slightly because hierarchical allocation will use up those initial 64 network addressing bits in a big hurry. IPv6 is no more than a stop gap for a some sort of variable length address (VLA) scheme, the only alternative that that isn't essentially an exercise in planned obsolescence.
Comparable features? Yes. Comparable performance, not without hardware support. What you need in general is a (managed) switch on a NIC. Intel has hardware switch support on their latest (82576,82599 based) server NICs right now, although I don't think there is much in the way of switch function manageability. Most of the focus is around hardware NIC virtualization, so that network traffic doesn't have to be handled by the hypervisor.
There is nothing new about software switches. Linux has had one for years. The nice part about the Cisco software switch is the addition of all the extra management and filtering features.
The problem with software switches (or bridges) is that they aren't all that fast - anything in the data path that can't be offloaded to some sort of hardware is going to be relatively slow compared to a hardware switch. In fact, some of the latest Intel server NICs have built in hardware switches for inter-VM communications. I have no idea whether the Cisco VMware switch is able to leverage that. If not, it is going to be a *lot* slower. One might well wonder why Cisco doesn't get into the virtual Ethernet switch on a card market itself.
Do you really want to have to reconfigure and possibly readdress everything just because you are moving a vm between host boxes to cope with demand?
No. What you do is use dynamic route updates so that if the the VM is located on the same host, IP traffic for the target VM is logically routed through the non-Ethernet virtual network. It doesn't even have to be numbered.
Without hardware support, one could tweak the TCP stack to check if the destination is associated with a local VM and then ask the supervisor to "DMA" the whole TCP send into the receive buffers of the target TCP socket, or even better into the target application buffer (assuming there is a pending read). If the VM is relocated while there is still data waiting to be sent, the internal route will go away, and the remaining data can be transmitted through the physical ethernet interface as usual.
The end game for this is clearly not running all inter-VM traffic out to an external switch and then making a hairpin turn and sending it all back to the host. That is a workaround at best - it is a waste of hardware, a waste of energy, and a waste of bandwidth.
One way or another this is going to be done on the host - either with appropriately enhanced switching support on the NIC or other advances in the CPU and the networking stack. Server CPUs should have inter-VM networking capability built into hardware, not an inter-VM Ethernet switch, but rather something more like an inter-VM RDMA engine. There is no point in using "Ethernet" to communicate between VMs on the same host other than portability.
Breaking inter-VM communications down into little itty bitty packets, running them one by one through a virtual bridge table without the benefit of content addressable memory, and then back up through a virtual ethernet interface is not a particularly efficient use of resources.
As other commenters have noted, there is no way this figure applies to Sandy City proper. Sandy does not have a UTOPIA deployment. The real problem, though, is that the Salt Lake valley has a large number of relatively small cities all served by the same local ISPs, and there is no reliable way that Akamai can tell which users are in which local cities to that level of accuracy. The IP addresses don't carry any more information than (roughly) somewhere in the Salt Lake valley. One would have to be in a different for that difference to start to be visible.
Salt Lake City proper isn't a UTOPIA city either, but there are several cities in the valley which are, notably West Valley City, Midvale, and Murray. So what appears is that Akamai estimated the coverage footprint of a local content distribution node (probably the one at Xmission) and estimated that the center of the footprint was in Sandy. Even though no one in Sandy City proper has that kind of bandwidth, people with UTOPIA connection (and there are many in the general vicinity) often do - 50 Mbit/s UTOPIA service is readily available, and inexpensively at that if you live in one of the original UTOPIA cities.
Xmission has standard residential UTOPIA bandwidths of 15 Mbit/s and 50 Mbit/s - up and down. The end user links are all 100 Mbit/s Ethernet (over fiber), and you can get a 100 Mbit/s "business" connection if you want.
Hardly. The public school system is not a free market, where for more money you can attract higher levels of talent (and sanity). Paying more means paying the same people higher salaries, depending not on demonstrated ability, but rather the number of years they have been in the system. That is what the union system is all about - not talent, but rather seniority. The whole idea is that teachers (or assembly line workers or whoever) are interchangeable cogs in a wheel, not real individuals with different talents and abilities deserving of individual treatment.
If we want the school system to improve, we should quit running it like the drivers license division (and vice versa).
Journaling, and every other filesystem, has exactly the same problem. If consistence is required, YOU MUST DISABLE THE CACHE
Not true - it depends on the filesystem. It is true with journaling filesystems that either a write barrier or a cache flush (that are actually honored by the disk subsystem) must be issued after every journal commit to maintain metadata consistency in the event of a power loss.
The only disadvantage of that is that it really slows down a strict implementation of fsync, unless you have a battery backed RAID controller or place the journal on some sort of fast persistent storage like an SSD. The real question is how long will it be before spinning hard drives have a little bit of flash inside them so that they can internally journal all disk writes and honor "cache flush" commands with the alacrity of (much smaller and more expensive) SSDs.
I never send hard drives in for warranty service or replacement. If they have confidential data on them, I beat them up with a hammer and throw them away. If the drives actually work, and aren't hopelessly old, I put them on a shelf instead.
As far as encrypting data at the block level is concerned, I doubt it will become prevalent until it is a standard feature of every common operating system. Even then there will be many systems that won't use it without hardware encryption support, because it will be too slow.
Not many companies (big or small) have figured it out. FOSS + Commercial success is tough.
Tough yes. Tougher than trying to gain market dominance of a good (read: highly profitable) size niche of the proprietary software business, not so much. Aversion to vendor lock-in and concerns about staying power are a big problem for small proprietary software companies.
The advantage of open source businesses is that startups can be successful while smaller, which means much less capital is required. A small group of open source software businesses that contribute to the same software product form sort of a virtual corporation that is much easier to get established and get the core product rolling than with a real one. Each of the feeder businesses just needs to specialize in a different niche.
The only trojan horse infection I have had in the past decade was due to visting a "security" web site that exploited a Java vulnerability. I use XP for work, and never run as an administrator anymore, unless I need to install software. In XP it is fundamentally unsafe.
I imagine running as limited user all the time seriously reduces the impact of Adobe Reader vulnerabilities like this, among others.
PostgreSQL starting storing NUMERIC columns in base 10000 six or seven years ago. A nice trick, but not exactly rocket science. If you have a high school level education in computer science, you should know how to do stuff like this. Maybe that is what the patent examiners need.
Win 95 had worse problems than Mac System 7, but for different reasons, mostly backward compatibility with DOS programs.
However, it was technically superior in other ways: preemptive multitasking, memory protection, and virtual memory. The big problem on non-Internet connected systems was primarily bad device drivers. The whole PC world (ISVs and most Microsoft employees included) had very little experience dealing with the complexity of a modern operating system, and in the area of device drivers it was rather apparent. I once spent three days just getting a 3COM Ethernet card to install correctly.
Of course the other problem was Microsoft's incredibly cavalier attitude to personal computer security. That was fine until the day the Internet exploded upon the scene, which happened at about the same time Windows 95 was released, in part because (IIRC correctly) it was the first common personal computer OS that included TCP/IP support, certainly the first common one where nearly everyone used it.
This is an idle pastime for me. No doubt you have better things to do.
I agree the "convention" changed among a large number of PC users who couldn't tell the difference between a glorified disk driver and an operating system, and the unfortunate name clash between "DOS" and "OS".
I will grant that the Mac system software was ten to twenty times as sophisticated as MS DOS ever was. Microsoft didn't come close to catching up (in their own products) until the release of Windows 95.
Yes, because the *convention* is already established and it's not that.
Only among the historically uninformed. No UNIX or VMS guy from the 1980s would consider MS-DOS an operating system. A system for operating disks, sure, but not a general purpose "operating system". As I said, that is why it was called a "Disk Operating System", not an "operating system". The serious system guys would laugh if you called it that.
MS-DOS is barely more sophisticated than Apple DOS, and believe me, *no one* called Apple DOS an "operating system". Apple itself didn't call the Mac system software an operating system up through and including System 7. Not "OS 7" but "System 7". Apple didn't start referring to their system software as an "OS" until 1996 or so, with the later versions of what was System 7, renamed "Mac OS 7.6" or thereabouts.
If Apple users needed a real (preemptive, multi-user, etc) operating system what they sold them was "A/UX", Apple's version of Unix. You simply couldn't make a general purpose server out of Mac anything until Mac OS X. Of course you wouldn't want to use an Amiga back then for a general purpose server either, even though it was capable of it.
I'm sorry, I think you care a lot more about this subject than I do. Is there any truth to the question of whether (fill in the blank) is an operating system? It is just a matter of convention. Hardly more than a matter of idle curiosity.
In my opinion, the world would be infinitesimally better off if we adopted the convention that operating systems actually operate more than one non-trivial program at once, and multitask between them on an equal basis. No doubt you disagree.
Wikipedia, for example, lists MS-DOS as an operating system
I would hesitate to consider Wikipedia an authority on anything. That aside, where do you draw the line? Is a BIOS an operating system? A device driver? A boot ROM? What about a CPU? Is a CPU an operating system? I can run programs on it, can't I?
Take the Apple II for example. When the Apple II first came out, floppy drives were expensive and rare. So you could load and save from audio tape instead, a function that took up a couple hundred bytes of the 2K monitor ROM.
Assuming I don't need BASIC, I turn the computer on, enter a monitor command to load a program from cassette tape, press play on the tape recorder, wait a few minutes, and then enter a command to start the program at the load address. The program, once loaded, makes absolutely no use of any of the code in ROM, until it terminates and back comes the monitor prompt.
So the question is: Was the Apple II monitor an operating system? It could save, load, and run files from tape, right?
(By the way, the only thing that makes notepad.exe on Windows an application and the Notepad desk accessory on the Mac a "desk accessory" is a distinction that the Mac itself makes. If desk accessories could do everything that applications could do, and in the same way they did it, no one would care. "Mac desk accessory" and "Mac application" would be a distinction without a difference, sort of like "BIOS" and "Boot ROM".)
It's fine to use fixed memory locations if they not application specific. The problem with the Mac is there were hundreds of variables at low, fixed, global addresses that carried critical state for the running application - or at least with application specific state and system level state so intermixed it was dangerous to make the distinction.
Apple could have avoided this problem by doing something as simple as using standard offsets from a base register. Instead, you got the equivalent of having a 4KB register set that had to be saved and restored to let another application run safely, once letting another application run was possible, of course.
Check this out.
There is one safe way to live without an MMU of course, and that is for the entire system to run something like a restricted JVM. Microsoft is trying to do that, with their Singularity research project (albeit with C#). Personally, I don't think it will ever work unless they drop the idea of a kernel that uses a tracing garbage collector. Stop the world just isn't going to fly in the long run. Reference counting maybe.