Sure, Windows sucks in lots of ways, but at least you won't find them generally working toward what customers want.
Was this a typo, or are you actually advocating products that don't do what you want? I mean, I've never found MS products to do what I want, but I thought either I was unusual in my desires or MS was making a mistake.
I certainly agree that a lot of application-makers seem to be in the business of competing with MS, rather than of providing good software. On the other hand, emacs and LaTeX (or HTML or just plain text) have worked a whole lot better than Word for my purposes. Which RMS is strange and emacs is odd, it's solid, and, for anything Word is capable of (or, at least, that I could figure out how to get Word to do), it's easier.
The main thing, I think, that would break MicroSoft's monopoly would be if it looked plausible that using MicroSoft products might soon become impossible. If people thought that, for example, Passport might get shut down in such a way that, suddenly, XP systems would just stop working, centralized services and buying from a monopoly would, by itself, become a significant deterent.
I think that the most effective settlement would be something like the existing one, with an extra clause that, if MicroSoft violates the terms at any point, all of their assets will be divided among their competitors.
Really, the terms of the settlement don't matter much. Nobody seriously expects MicroSoft to abide by them, and nothing seems likely to happen when they violate them. If there was a specified, negotiated, and fatal penalty for violating the agreement, the customers and investors would have to bet that MicroSoft would actually obey the law. Suddenly, going with MicroSoft would be a major risk, rather than a pretty safe bet, which would greatly change the business prospects.
Since there isn't currently a widely-supported and secure wireless protocol, they say that you should put your wireless network behind a firewall and treat it as an untrusted link. But they didn't actually do anything to see if the networks they were finding were firewalled off that way. So the article doesn't really say anything about deployed security. Of course, their correspondants probably actually know that the security sucks, but didn't want to demonstrate that.
It does make an interesting example of how you can confuse people, though: they actually wrote an article in which they say they went looking for networks, found them, looked for security, didn't find it, and learned that the only good security wouldn't have shown up, and they didn't come to the conclusion that they weren't looking for the right things.
Presumably these companies have insecure internet connections, but nobody would write an article about it without finding out if they have firewalls on them.
Since I've taken to watching TV almost exclusively recorded on my housemate's ReplayTV, the only way I ever know what channel a show is broadcast on is the little icons. So long as they stay in the corner and don't block anything important, I think they're fine, since I don't really have any other way of identifying the information, and it's occasionally nice to know what channel a show is actually on.
There's really no way to tell if the Windows VM is bad and is just being left as is, or is being changed, or is good, because you obviously can't run some other VM under the same load (even if you switch between Windows versions, it's a different load because you've got different system implementations and such).
The design of a VM system also depends a lot on the rest of the system: the best VM is one that always has a page swapped in when you need it, and always has it in an acceptable part of memory. But which page is going to be needed next depends on what sorts of programs you're running, and tons of other factors. The VM system is trying to guess these, and there are some known heuristics for guessing, but there's no right solution for VMs in general.
Apple has had a very different scheduling algorithm, which makes the problem totally different, and much easier: the applications not in front can be swapped out.
I believe that, for a commercial UNIX, if you need swap, then you didn't put in enough RAM. If you could buy the system in the first place, you can afford more RAM. If the OS doesn't support enough RAM, get a version that does.
Is it just me, or does everyone who likes CDE like it because it doesn't do that much? Maybe it's because I've only used it on HP/UX, but it seemed like CDE managed to botch every single thing it did. Admittedly, you can almost entirely avoid it, but "it's almost as good as nothing, and better than many other things" is not really a good sign.
I have to admit, it does include a window manager that lets you move, resize, and iconify windows and change the keyboard focus. But, other than that, just using an xterm would be nicer.
In the traditional VM formulation (pre-linux), every bit of VM would have a place in swap, and RAM would just keep a fast copy of the data. This greatly simplified the implementation, of course, because all of the data had a location on disk it could keep for its entire lifetime. Linux didn't do this: data would just be put on disk somewhere free, and could lose its place while in RAM. This meant that your total VM would be disk+RAM, not just disk.
As an optimization, and due to hard drive space being cheap, the first 2.4 VM used the traditional scheme, because, if a page hasn't been modified since it was last swapped out, it wouldn't have to be written at all if it was still there.
In any case, it's probably worthwhile to have at least 1.5 times the swap as RAM; if you have just a little bit of swap on a high-memory system, it's unlikely to save you from running out of memory, and will instead cause the machine to swap a lot before running out of memory anyway. You don't need to upgrade memory and swap at the same time, but you might as well upgrade swap first, or just turn it off. (That is, if you're getting more memory so you'll have more space, buy swap first. If you're getting more memory so it will be faster, replace swap with RAM)
These days, hard drives are cheap, and there are old hard drives lying around of reasonable sizes; just use a whole recently-replaced hard drive as swap. This avoids contention with filesystems and is easy to replace.
So Thawte now thinks their verification process is flawed. So they're not revising their verification process, or revoking their existing certificates (which they presumably issued based on their flawed process). And it's not like someone planning to do something with a developer certificate would wait until the last minute to actually get the certificate.
In any case, PKI is inherently broken in a number of ways, including that the signer doesn't specify what about the key is being certified. So there's no way for Thawte to certify that they checked a passport and you look like the photo. There's no way for them to say, "This person is who he says he is, unless he accidentally emailed his private key to a total stranger or duped the Portugese passport authority."
It should be fine, assuming that the environment includes everything the developer needs. Of course, if the standard environment includes everything the developers need, then you're going to be getting licenses for a lot of things for a lot of people who don't need them.
Of course, if the people are developers, they are presumably going to develop something that's not part of the environment. If they can install their project, they can probably install other stuff.
Microsoft has simply determined that, if you need to use a computer thesaurus to insult someone, you're better off not bothering, or just using the words you can come up with.
Exceptions are faster, assuming that they never happen. They should never happen, therefore, unless something goes wrong that occurs only rarely and involves some real problem that has to be dealt with differently. For instance, running out of disk space or getting invalid input from the user; in these cases, the user doesn't really care about efficiency as much as correctness (if I mess up, the time spent waiting for the computer to tell me what is wrong is much less than the time it would take to redo things that have gotten messed up).
Using exceptions means that the code doesn't have to check for unusual failures in the normal case. If things are okay, it doesn't have to stop at each level and see if something went wrong; if things aren't okay, you don't care that it's slow.
Unless, of course, you're writing Oracle stored procedures, in which case exceptions are fine in the normal case.
Actually, what makes their story rubbish is that (1) it doesn't accept the W3C HTTP Validator and (2) the splash page doesn't even *pass* the validator.
'"All of our development work for the new MSN.com is...W3C standard," said Bob Visse, the director of MSN marketing.'
So is it actually standard? According to http://validator.w3.org/check?uri=http%3A%2F%2Fwww.msn.com%2F&charset=%28detect+automatically%29 &doctype=Inline, nope: there are 4 errors. Unsurprisingly, the page it is validating is, of course, not the actual MSN home page. Evidentally, the W3C doesn't understand the latest W3C standards. Now, admittedly, I'm not sure anyone actually understands the most recent XHTML spec, but it's a bit unkind of MSN to say so.
But if it's local, it could use an IPC mechanism that didn't involve serializing everything and copying it. The shm extension shouldn't be necessary; shared memory should be something the server just does. In the case when it's being proxied over something, serialization will, of course, be needed, but much of the time, there are other concerns, anyway.
It's inconvenient for application-writing to use the client-server model, where it is up to the programmer to keep track of where the data is. It's also somewhat annoying that, much of the time, other programs end up putting a lot of data into the server process, so you can't tell how much memory use should be considered X's, and how much is really Netscape's.
The network inefficiency is because X is putting the network between the widget toolkit and the display, and doesn't have all the features the toolkit wants as primitives. So, in order to look the way it wants, the toolkit has to exchange a lot of data with the display over the network. It would be vastly more efficient if you could essentially run Qt/Gtk on the display side, and have the network in between the app and the widget toolkit. This, again, calls for not having X over a socket, because it makes more sense to put the network somewhere else, and put what's currently the other side of the socket in the same place as the server.
1) It's networked. People don't use this any more, mostly. If they do, it's via ssh, which doesn't use the network features of X anyway. X ought to just specify talking to a local server, which may be a proxy over ssh.
2) Its core protocol is missing a ton of features that program want. For example, nobody on the team knew how to do splines, so they left them out. Splines still aren't really supported, and won't be supported any time soon in the core protocol.
3) It's too extensive. It is generally implemented as a set of drivers, library, network server, resource manager, plus windowing system. Some of those features ought to be separate. In particular, splitting off the drivers (as well as implementations of operations the actual card doesn't support) from the windowing system would save a lot of hassles.
I think a layer for doing graphics under the level of the X server would be better. The main problem is that XFree86 has really good free drivers, which would be a shame to reimplement, but they are all for the X API.
There are some cases where you don't actually want the main features of X, so it would be good to provide a more fundamental graphics layer to programs that want it.
As far as I can tell, only the Xft parts are actually implemented at all. Also, using extensions is somewhat inconvenient, since it doesn't really integrate nicely with the core code; it would be much nicer if you could use all of the standard X functions with transparency features.
Admittedly, I'm likely one of the few people around these days who doesn't want to use a widget toolkit, so I care more about the library organization than just about anyone, but still.
I'd certainly like to have transparent windows, so that I can tell when things in windows other than the front ones change. Being able to get more information out of a particular screen arrangement is always a benefit.
For one, Apple has a patent on alpha blending, which is part of anti-aliasing algorithms and so forth. I suspect that Apple would actually rather not try to enforce this patent against users of standard like SVG, since it's a somewhat flismy patent, essentially being z=ax+(1-a)y, which is both simple math (from probability, e.g.) and also is essentially how colored plastic works.
Right, we have to give terrorists military aid, training, and funding, but no privacy rights. I'll remember that.
Hey, I hear there are a bunch of government-types who specialize in invading privacy, not tying the hands of law enforcement, and keeping people from getting away who are about to be out of work and would love to demonstrate their techniques in the US...
There are three issues in the case of the Linux kernel: (1) It depends on hardware. Nobody has one of everything, so nobody could do a comprehensive test. Sometime one driver will turn out to make one assumption, and another driver will make a conflicting assumption; either will work, but not together. (2) There are a lot of situations where the specified behavior is underdetermined, and, in particular, cases where you can do a set of things the original programmers didn't expect you to do together. There won't be tests for these sorts of things. (3) There are a lot of corner cases that are hard to make happen. It's very difficult to put the kernel into certain combinations of states, so, on most trials, the situation won't even get tested. This is particularly the case with race conditions between processors and things that depend on peripheral timing.
I agree that having a test suite would be good for catching a lot of simple bugs in places that are easy to test. Sometimes a new kernel will have something that doesn't work at all, and that should get caught. But there are relatively few of these, compared to things which aren't really quite safe, although you have to look at them carefully and think about them, understanding the code, for a while, and these are the more important bugs.
You want it to get for you information that depends on your location without disclosing your location? That's going to be somewhat difficult, because the service can't help but know what information they're providing to you. What logs they keep and what they do with them is a privacy policy question. There's no way they're going to send all of the data there is to your little phone, and have the phone figure out what you want from a GPS reading that it doesn't send out.
Fiber optics aren't really stronger than the stuff that construction equipment is supposed to go through. Obviously, if there were a really vast number of cables, the person would probably notice that he's digging in cables and not dirt at all, but for a reasonable number of cables, he'll go right through.
The sensible design, anyway, is to put a pipe around the cables, which will ideally protect them from moisture, animals, tree roots, etc, and somewhat from the construction equipment. But it doesn't matter how many cables you put in the pipe, because the cables are of negligable strength, compared to the pipe, and putting each cable in a separate pipe would take up a prohibitive amount of space.
People have this tendancy to put all of the cables in the same place anyway, because you can dig a huge ditch or dig up all the streets once, and put in a whole bunch of cables, or because there's only a few paths that you can afford to dig up. Having greater capacity on each cable just means that you won't need as many cables in the same hole. Whatever makes a cable break is likely to kill the whole group. The redundency comes largely from wanting to connect each pair of points for normal operation, which means that you'll have other routes if one goes down.
Slashdot Mirror
Sure, Windows sucks in lots of ways, but at least you won't find them generally working toward what customers want.
Was this a typo, or are you actually advocating products that don't do what you want? I mean, I've never found MS products to do what I want, but I thought either I was unusual in my desires or MS was making a mistake.
I certainly agree that a lot of application-makers seem to be in the business of competing with MS, rather than of providing good software. On the other hand, emacs and LaTeX (or HTML or just plain text) have worked a whole lot better than Word for my purposes. Which RMS is strange and emacs is odd, it's solid, and, for anything Word is capable of (or, at least, that I could figure out how to get Word to do), it's easier.
The main thing, I think, that would break MicroSoft's monopoly would be if it looked plausible that using MicroSoft products might soon become impossible. If people thought that, for example, Passport might get shut down in such a way that, suddenly, XP systems would just stop working, centralized services and buying from a monopoly would, by itself, become a significant deterent.
I think that the most effective settlement would be something like the existing one, with an extra clause that, if MicroSoft violates the terms at any point, all of their assets will be divided among their competitors.
Really, the terms of the settlement don't matter much. Nobody seriously expects MicroSoft to abide by them, and nothing seems likely to happen when they violate them. If there was a specified, negotiated, and fatal penalty for violating the agreement, the customers and investors would have to bet that MicroSoft would actually obey the law. Suddenly, going with MicroSoft would be a major risk, rather than a pretty safe bet, which would greatly change the business prospects.
Since there isn't currently a widely-supported and secure wireless protocol, they say that you should put your wireless network behind a firewall and treat it as an untrusted link. But they didn't actually do anything to see if the networks they were finding were firewalled off that way. So the article doesn't really say anything about deployed security. Of course, their correspondants probably actually know that the security sucks, but didn't want to demonstrate that.
It does make an interesting example of how you can confuse people, though: they actually wrote an article in which they say they went looking for networks, found them, looked for security, didn't find it, and learned that the only good security wouldn't have shown up, and they didn't come to the conclusion that they weren't looking for the right things.
Presumably these companies have insecure internet connections, but nobody would write an article about it without finding out if they have firewalls on them.
Since I've taken to watching TV almost exclusively recorded on my housemate's ReplayTV, the only way I ever know what channel a show is broadcast on is the little icons. So long as they stay in the corner and don't block anything important, I think they're fine, since I don't really have any other way of identifying the information, and it's occasionally nice to know what channel a show is actually on.
There's really no way to tell if the Windows VM is bad and is just being left as is, or is being changed, or is good, because you obviously can't run some other VM under the same load (even if you switch between Windows versions, it's a different load because you've got different system implementations and such).
The design of a VM system also depends a lot on the rest of the system: the best VM is one that always has a page swapped in when you need it, and always has it in an acceptable part of memory. But which page is going to be needed next depends on what sorts of programs you're running, and tons of other factors. The VM system is trying to guess these, and there are some known heuristics for guessing, but there's no right solution for VMs in general.
Apple has had a very different scheduling algorithm, which makes the problem totally different, and much easier: the applications not in front can be swapped out.
I believe that, for a commercial UNIX, if you need swap, then you didn't put in enough RAM. If you could buy the system in the first place, you can afford more RAM. If the OS doesn't support enough RAM, get a version that does.
Is it just me, or does everyone who likes CDE like it because it doesn't do that much? Maybe it's because I've only used it on HP/UX, but it seemed like CDE managed to botch every single thing it did. Admittedly, you can almost entirely avoid it, but "it's almost as good as nothing, and better than many other things" is not really a good sign.
I have to admit, it does include a window manager that lets you move, resize, and iconify windows and change the keyboard focus. But, other than that, just using an xterm would be nicer.
In the traditional VM formulation (pre-linux), every bit of VM would have a place in swap, and RAM would just keep a fast copy of the data. This greatly simplified the implementation, of course, because all of the data had a location on disk it could keep for its entire lifetime. Linux didn't do this: data would just be put on disk somewhere free, and could lose its place while in RAM. This meant that your total VM would be disk+RAM, not just disk.
As an optimization, and due to hard drive space being cheap, the first 2.4 VM used the traditional scheme, because, if a page hasn't been modified since it was last swapped out, it wouldn't have to be written at all if it was still there.
In any case, it's probably worthwhile to have at least 1.5 times the swap as RAM; if you have just a little bit of swap on a high-memory system, it's unlikely to save you from running out of memory, and will instead cause the machine to swap a lot before running out of memory anyway. You don't need to upgrade memory and swap at the same time, but you might as well upgrade swap first, or just turn it off. (That is, if you're getting more memory so you'll have more space, buy swap first. If you're getting more memory so it will be faster, replace swap with RAM)
These days, hard drives are cheap, and there are old hard drives lying around of reasonable sizes; just use a whole recently-replaced hard drive as swap. This avoids contention with filesystems and is easy to replace.
So Thawte now thinks their verification process is flawed. So they're not revising their verification process, or revoking their existing certificates (which they presumably issued based on their flawed process). And it's not like someone planning to do something with a developer certificate would wait until the last minute to actually get the certificate.
In any case, PKI is inherently broken in a number of ways, including that the signer doesn't specify what about the key is being certified. So there's no way for Thawte to certify that they checked a passport and you look like the photo. There's no way for them to say, "This person is who he says he is, unless he accidentally emailed his private key to a total stranger or duped the Portugese passport authority."
It should be fine, assuming that the environment includes everything the developer needs. Of course, if the standard environment includes everything the developers need, then you're going to be getting licenses for a lot of things for a lot of people who don't need them.
Of course, if the people are developers, they are presumably going to develop something that's not part of the environment. If they can install their project, they can probably install other stuff.
Microsoft has simply determined that, if you need to use a computer thesaurus to insult someone, you're better off not bothering, or just using the words you can come up with.
Exceptions are faster, assuming that they never happen. They should never happen, therefore, unless something goes wrong that occurs only rarely and involves some real problem that has to be dealt with differently. For instance, running out of disk space or getting invalid input from the user; in these cases, the user doesn't really care about efficiency as much as correctness (if I mess up, the time spent waiting for the computer to tell me what is wrong is much less than the time it would take to redo things that have gotten messed up).
Using exceptions means that the code doesn't have to check for unusual failures in the normal case. If things are okay, it doesn't have to stop at each level and see if something went wrong; if things aren't okay, you don't care that it's slow.
Unless, of course, you're writing Oracle stored procedures, in which case exceptions are fine in the normal case.
Actually, what makes their story rubbish is that (1) it doesn't accept the W3C HTTP Validator and (2) the splash page doesn't even *pass* the validator.
So is it actually standard? According to http://validator.w3.org/check?uri=http%3A%2F%2Fwww .msn.com%2F&charset=%28detect+automatically%29 &doctype=Inline, nope: there are 4 errors. Unsurprisingly, the page it is validating is, of course, not the actual MSN home page. Evidentally, the W3C doesn't understand the latest W3C standards. Now, admittedly, I'm not sure anyone actually understands the most recent XHTML spec, but it's a bit unkind of MSN to say so.
But if it's local, it could use an IPC mechanism that didn't involve serializing everything and copying it. The shm extension shouldn't be necessary; shared memory should be something the server just does. In the case when it's being proxied over something, serialization will, of course, be needed, but much of the time, there are other concerns, anyway.
It's inconvenient for application-writing to use the client-server model, where it is up to the programmer to keep track of where the data is. It's also somewhat annoying that, much of the time, other programs end up putting a lot of data into the server process, so you can't tell how much memory use should be considered X's, and how much is really Netscape's.
The network inefficiency is because X is putting the network between the widget toolkit and the display, and doesn't have all the features the toolkit wants as primitives. So, in order to look the way it wants, the toolkit has to exchange a lot of data with the display over the network. It would be vastly more efficient if you could essentially run Qt/Gtk on the display side, and have the network in between the app and the widget toolkit. This, again, calls for not having X over a socket, because it makes more sense to put the network somewhere else, and put what's currently the other side of the socket in the same place as the server.
1) It's networked. People don't use this any more, mostly. If they do, it's via ssh, which doesn't use the network features of X anyway. X ought to just specify talking to a local server, which may be a proxy over ssh.
2) Its core protocol is missing a ton of features that program want. For example, nobody on the team knew how to do splines, so they left them out. Splines still aren't really supported, and won't be supported any time soon in the core protocol.
3) It's too extensive. It is generally implemented as a set of drivers, library, network server, resource manager, plus windowing system. Some of those features ought to be separate. In particular, splitting off the drivers (as well as implementations of operations the actual card doesn't support) from the windowing system would save a lot of hassles.
I think a layer for doing graphics under the level of the X server would be better. The main problem is that XFree86 has really good free drivers, which would be a shame to reimplement, but they are all for the X API.
There are some cases where you don't actually want the main features of X, so it would be good to provide a more fundamental graphics layer to programs that want it.
As far as I can tell, only the Xft parts are actually implemented at all. Also, using extensions is somewhat inconvenient, since it doesn't really integrate nicely with the core code; it would be much nicer if you could use all of the standard X functions with transparency features.
Admittedly, I'm likely one of the few people around these days who doesn't want to use a widget toolkit, so I care more about the library organization than just about anyone, but still.
I'd certainly like to have transparent windows, so that I can tell when things in windows other than the front ones change. Being able to get more information out of a particular screen arrangement is always a benefit.
Nope, he's got the freedom to hang up the phone on you. But he can't stop you from calling...
For one, Apple has a patent on alpha blending, which is part of anti-aliasing algorithms and so forth. I suspect that Apple would actually rather not try to enforce this patent against users of standard like SVG, since it's a somewhat flismy patent, essentially being z=ax+(1-a)y, which is both simple math (from probability, e.g.) and also is essentially how colored plastic works.
Right, we have to give terrorists military aid, training, and funding, but no privacy rights. I'll remember that.
Hey, I hear there are a bunch of government-types who specialize in invading privacy, not tying the hands of law enforcement, and keeping people from getting away who are about to be out of work and would love to demonstrate their techniques in the US...
Even after all these warning, people keep openning suspicious mail with attachments.
Plus, people often have virus scanners, but nobody has a bacterium scanner...
There are three issues in the case of the Linux kernel: (1) It depends on hardware. Nobody has one of everything, so nobody could do a comprehensive test. Sometime one driver will turn out to make one assumption, and another driver will make a conflicting assumption; either will work, but not together. (2) There are a lot of situations where the specified behavior is underdetermined, and, in particular, cases where you can do a set of things the original programmers didn't expect you to do together. There won't be tests for these sorts of things. (3) There are a lot of corner cases that are hard to make happen. It's very difficult to put the kernel into certain combinations of states, so, on most trials, the situation won't even get tested. This is particularly the case with race conditions between processors and things that depend on peripheral timing.
I agree that having a test suite would be good for catching a lot of simple bugs in places that are easy to test. Sometimes a new kernel will have something that doesn't work at all, and that should get caught. But there are relatively few of these, compared to things which aren't really quite safe, although you have to look at them carefully and think about them, understanding the code, for a while, and these are the more important bugs.
You want it to get for you information that depends on your location without disclosing your location? That's going to be somewhat difficult, because the service can't help but know what information they're providing to you. What logs they keep and what they do with them is a privacy policy question. There's no way they're going to send all of the data there is to your little phone, and have the phone figure out what you want from a GPS reading that it doesn't send out.
Fiber optics aren't really stronger than the stuff that construction equipment is supposed to go through. Obviously, if there were a really vast number of cables, the person would probably notice that he's digging in cables and not dirt at all, but for a reasonable number of cables, he'll go right through.
The sensible design, anyway, is to put a pipe around the cables, which will ideally protect them from moisture, animals, tree roots, etc, and somewhat from the construction equipment. But it doesn't matter how many cables you put in the pipe, because the cables are of negligable strength, compared to the pipe, and putting each cable in a separate pipe would take up a prohibitive amount of space.
People have this tendancy to put all of the cables in the same place anyway, because you can dig a huge ditch or dig up all the streets once, and put in a whole bunch of cables, or because there's only a few paths that you can afford to dig up. Having greater capacity on each cable just means that you won't need as many cables in the same hole. Whatever makes a cable break is likely to kill the whole group. The redundency comes largely from wanting to connect each pair of points for normal operation, which means that you'll have other routes if one goes down.