2) run Linux under Windows. Perhaps with a Knoppix CD that autoruns and starts a full-screen Linux session without rebooting, and you can hit Alt-Tab to go back to Windows. (Bochs + Plex86 + Knoppix: what should be the name for this? Knopplechs86?)
Nobody has difficulty finding stuff in the registry? It seems pretty awkward to me. Perhaps I am in a minority of one, but locating the particular key needed to change things like the background colour of the login screen takes ages. Perhaps I am in a minority of one. It doesn't help that the data for a single program is strewn across seemingly random parts of the registry (at least, this is the case for Windows itself).
If programs should not NEED TO BE IN A SPECIFIC DIRECTORY, why should they NEED TO BE IN A SPECIFIC TREE OF THE REGISTRY? They both come down to the same thing, agreeing on a location.
Having a registry just pushes the problem to another level: people have to agree on whereabouts in the registry the information is stored. If they don't currently agree on/tmp/foo.sock versus/var/tmp/foo/0.sock, what makes you think they will agree on \\HKEY_LOCAL_MACHINE\Vendors\Foo Corporation\Foo\1.45\Configuration\SocketLocation rather than \\HKEY_USERS\All Users\Software\Foo 1.45\Socket?
We already have a hierarchical database used for storing information and associating it with particular names. It's called the filesystem. No need to reinvent the wheel. FWIW,.NET does not use the Windows registry at all, (IIRC).
Yes, most of the author's problems were files being in different locations. The clash between/usr/lib/ and/usr/local/lib/ wouldn't happen under any packaging system (since/usr/local/ is not touched by the package manager), and the difference in the location of the socket is something the vendor ought to have fixed, by shipping packages that agree on the location.
It isn't clear from the article where he got the RPMs from. If they were from a mixture of different places, it's not that surprising that there were difficulties. Maybe the answer is for the package builders to talk to each other a bit more.
Suppose the cache holds 128k words and of those a dozen or so are bad. That means one in ten thousand accesses which would normally hit the cache have to go to main memory instead. If main memory is ten times slower than L2 cache, that's roughly a 0.1% slowdown. You could get unlucky and have a particular frequently-accessed address get assigned one of the cache bad spots, but in that case the address would be in L1 anyway.
Is it really 640Kbyte in total? That would happen only if every address in the L1 were not also in the L2. If it's possible for L1 and L2 caches to overlap, then it would be more accurate to say '512Kbyte of cache in total, of which 128Kbyte can run rather quickly'.
I mean, nobody says their system has '128.5 megabytes of memory in total' if they have a single 128 meg memory module and 512Kbyte of cache in the CPU.
So a large area of cache means more chance of defects: defects in the cache. But if some part of the cache is bad, it ought to be possible to just use half of it and sell the chip as having 256Kbyte of cache.
It seems to me (knowing nothing about chip design) that there should be some way to specify which parts of the cache are bad. Perhaps the cache could operate as normal, but if an address being fetched turns out to be in a bad part of the cache, it counts as a cache miss and is fetched from main memory as normal. A few dozen bad spots in a 512Kbyte cache shouldn't affect performance that much. The yield should be greatly increased.
There must be some good reason why this doesn't work, else the chip manufacturers would be doing it already. What is that?
Most people base their operating systems on silly things like memory management, process scheduling, and hardware drivers.
Yeah, RISC OS doesn't have any of those. OK, last time I looked it had some memory protection and I think there was even a new facility to let a process allocate more memory for itself once loaded (rather than taking a fixed 'slot'), but it's still essentially a single-tasking system that does co-operative multitasking with polling. Still, it works.
The first thought that went through my head when reading this story was 'oh good, they'll probably have to release RISC OS under the GPL, I could really use a legal copy to work with Arcem'. But I soon remembered that copyright in RISC OS is actually held by Pace (makers of DTV set-top boxes) and Castle just do some of the development.
Given that Acorn (and now I think their successors Pace) refused/still refuse to release even the original 1981 OS ROM for the BBC Micro for use in emulators, it seems a bit unreasonable for them to go copying other people's code in this way.
RISC OS was a nice system, especially the graphical interface and anti-aliased outline fonts (which still look better than anything on Linux or Windows, except maybe Acroread). If it were free I might even go back to using it occasionally. Ho hum...
It's a good question. And this is one of the main reasons the FSF asks for copyright assignment on contributed code - so they can go to court if someone infringes (ie, distributes GPLed code under a licence other than GPL) and say unequivocally, we are the copyright holders and the defendant is in breach of copyright.
Linus chose not to require such assignment, so the copyright on the code is held jointly by many people. IANAL, but it seems reasonable that just one of them could still sue if he or she had written a substantial chunk of the copied code. But it's not quite so clear-cut as before.
I hiccup when I eat spicy food. Clearly this is caused by brain circuitry inherited from primaeval tadpole-like creatures trying to crawl their way out of the chilli-infested waters of the Amazon into a cool, fresh pit of naturally occurring yogurt.
Holy guacamole, 'power consumption of less than 1W'? Can this really be true? Maybe the marketing department is taking account of the hours during the day when the notebook is in sleep mode or switched off...
Still, it would be nice to have an Intel chip with low power consumption. Is anyone making desktop systems or motherboards with the mobile chipset?
If all you want is web access, why bother with NAT at all? It is an ugly hack, really. You can just set up a proxy server (squid or wwwoffle) and configure browsers to use that. You'll probably get better performance, too, since the proxy server can do caching. Or you could use NAT for ssh connections and an explicit proxy server for http/https/ftp.
OK, I know there are some NATting products which do caching internally, but it's not as clean as just configuring the web browsers to talk directly to a proxy, and it's more likely to break stuff. (At least, some 'transparent' web caches are horribly broken.)
Actually I agree with Valenti on this. If your DVD breaks, you get to keep both parts. The right to view the movie comes with the physical possession of the medium - or at least it should IMHO - and so making a backup copy is just the same as any other form of copying.
It sometimes seems that people want to have it both ways. They want to say, it's my disc, I paid for it, I can do what I want with it - but then when it comes to backup copies, or making a copy of music to listen to in the car, they seem to prefer thinking about some 'right to use' the information, which is apparently what you really paid for, and therefore you are justified in transferring it onto a different medium as long as you still only listen to it yourself. The trouble is, once you start down the road of buying a licence rather than buying a physical artefact, you have questions about what your licence allows you to do - like region coding. Much better, IMHO, to stick with the conventional copyright system that gives a monopoly on *making copies* but doesn't get into the world of access controls and licensing a disc for a particular purpose.
OK, these two groups may be disjoint, I know that there is no such thing as 'the Slashdot opinion' which is so often criticized as being inconsistent. And I'm sure that the MPAA/RIAA/etc also switch between the two views of copyright when it suits them. But still, when you argue that the right to use the information (rather than ownership of the physical medium) is what matters, be sure that this is really what you want.
That's not what abusing a position of trust means. It means, when you are placed in a position of responsibility, not living up to the trust placed in you. For example a customs officer who helps in smuggling is abusing a position of trust (among other things). An ordinary person who smuggled goods would not be abusing a position of trust, because they were never in that position to start with. It doesn't just mean general dishonesty or confidence trickery.
So if Mr Mitnick had been appointed as a security consultant and used that to break into systems for personal gain, that would be an abuse of trust. As it is, he doesn't seem to have committed this kind of dishonesty, whatever else he did.
I think we will see 'raising the resolution' become an uncommon operation, since most displays will run at the maximum possible resolution all the time. (For LCDs, you run at the natural resolution of the screen, and it makes no sense to use anything else.) Instead there will be an option in the control panel to 'make things bigger' or 'make things smaller'.
When I installed Linux-Mandrake it defaulted to 800x600 resolution, even though the video card and monitor were capable of much more. But it was a sensible default, since current X11 desktops have (physically) bigger UI elements at low resolutions, and might look too small and fiddly at high resolutions (at least for the new user). If, OTOH, you could trust the desktop and applications to just display at the specified size regardless of pixel resolution, then Mandrake could pick the best quality display without any worries.
Another argument is *say what you mean*. If you want smaller fonts and UI elements to give more space on your desktop, then there should be a preference for 'make the UI smaller'. And if you want to change the number of pixels fitting onto your screen, there should be a preference for that. It doesn't make sense to muddle these two things into a single option, still less to have them in a single option and then various kludges like Windows's 'small fonts / large fonts' option on top.
I think that inexperienced users do not raise the resolution, they may not know what the resolution is. And power users will be just as happy with two options 'raise resolution' and 'make stuff smaller'. I don't think it would be user-unfriendly to replace the current broken system.
It's more likely that as free software becomes more widespread, the remaining Microsoft customers are those who will stick with Windows, no matter what. All those customers who are strongly influenced by pricing will already have moved to Linux. So Microsoft's best strategy is to increase its prices further, to get more money out of a smaller customer base (and do it as quickly as possible, before those customers too start to migrate).
It's extremely useful. I have a box where I have a shell account and some web space, but my firewall blocks ssh connections, and besides, not every PC will have an ssh client installed. Being able to go to a web page and run the occasional command would save a lot of time. OK, you couldn't run pine or emacs inside it, but it's still handy.
There is no security problem because access to the CGI script will be protected with the normal user and password mechanisms of the web server. With any half-decent Apache installation that means authenticating over an SSL connection giving your Unix username and password. If the only person who can run the script is you, then you don't really need to worry about exploits because an attacker could not execute the script unless he already had login access to your account.
What surprises me is that there aren't a dozen such CGI programs in existence already.
It's a step towards what we should have had long ago: a desktop where you don't need to know what resolution it's running at, things are just scaled to the correct size. It's crazy that changing to a higher resolution display (eg from 800x600 to 1024x768 on the same monitor) makes all the window decorations and icons smaller. Fonts are supposed to remain the same size, but often they don't.
Obviously for really low resolutions the scale might need to be increased to keep things readable, but a 3200x2400 desktop should look identical to 800x600 except for increased sharpness and detail. (You can still choose really tiny icons if you want them, of course.)
Looking at the way AMD moved to 64 bits - with pretty much the same instruction set, just widening some registers and adding a few registers - you wonder why the same hasn't happened more widely. Why is there no 64 bit ARM, for example?
Or why don't Centaur/VIA widen the registers on their C3 chip and release it as Opteron-compatible? The performance would suck relative to Opteron, of course, but for people who were buying Opteron servers and wanted compatible hardware it could be a competitor to the Athlon 64.
Of course Hammer/Opteron/Athlon 64 is not just 'take the existing Athlon and make some paths a bit wider'. It's a new chip which performs better than the current Athlon. But when designing a CPU, surely you can make the design parameterized by register width and produce 16/32/64 bit versions with only one lot of design and validation effort.
Slashdot Mirror
2) run Linux under Windows. Perhaps with a Knoppix CD that autoruns and starts a full-screen Linux session without rebooting, and you can hit Alt-Tab to go back to Windows. (Bochs + Plex86 + Knoppix: what should be the name for this? Knopplechs86?)
Obligatory Simpsons quotation:
'McBain to base: under attack by commie Nazis.'
Nobody has difficulty finding stuff in the registry? It seems pretty awkward to me. Perhaps I am in a minority of one, but locating the particular key needed to change things like the background colour of the login screen takes ages. Perhaps I am in a minority of one. It doesn't help that the data for a single program is strewn across seemingly random parts of the registry (at least, this is the case for Windows itself).
If programs should not NEED TO BE IN A SPECIFIC DIRECTORY, why should they NEED TO BE IN A SPECIFIC TREE OF THE REGISTRY? They both come down to the same thing, agreeing on a location.
Having a registry just pushes the problem to another level: people have to agree on whereabouts in the registry the information is stored. If they don't currently agree on /tmp/foo.sock versus /var/tmp/foo/0.sock, what makes you think they will agree on \\HKEY_LOCAL_MACHINE\Vendors\Foo Corporation\Foo\1.45\Configuration\SocketLocation rather than \\HKEY_USERS\All Users\Software\Foo 1.45\Socket?
.NET does not use the Windows registry at all, (IIRC).
We already have a hierarchical database used for storing information and associating it with particular names. It's called the filesystem. No need to reinvent the wheel. FWIW,
Yes, most of the author's problems were files being in different locations. The clash between /usr/lib/ and /usr/local/lib/ wouldn't happen under any packaging system (since /usr/local/ is not touched by the package manager), and the difference in the location of the socket is something the vendor ought to have fixed, by shipping packages that agree on the location.
It isn't clear from the article where he got the RPMs from. If they were from a mixture of different places, it's not that surprising that there were difficulties. Maybe the answer is for the package builders to talk to each other a bit more.
Suppose the cache holds 128k words and of those a dozen or so are bad. That means one in ten thousand accesses which would normally hit the cache have to go to main memory instead. If main memory is ten times slower than L2 cache, that's roughly a 0.1% slowdown. You could get unlucky and have a particular frequently-accessed address get assigned one of the cache bad spots, but in that case the address would be in L1 anyway.
Is it really 640Kbyte in total? That would happen only if every address in the L1 were not also in the L2. If it's possible for L1 and L2 caches to overlap, then it would be more accurate to say '512Kbyte of cache in total, of which 128Kbyte can run rather quickly'.
I mean, nobody says their system has '128.5 megabytes of memory in total' if they have a single 128 meg memory module and 512Kbyte of cache in the CPU.
So a large area of cache means more chance of defects: defects in the cache. But if some part of the cache is bad, it ought to be possible to just use half of it and sell the chip as having 256Kbyte of cache.
It seems to me (knowing nothing about chip design) that there should be some way to specify which parts of the cache are bad. Perhaps the cache could operate as normal, but if an address being fetched turns out to be in a bad part of the cache, it counts as a cache miss and is fetched from main memory as normal. A few dozen bad spots in a 512Kbyte cache shouldn't affect performance that much. The yield should be greatly increased.
There must be some good reason why this doesn't work, else the chip manufacturers would be doing it already. What is that?
The first thought that went through my head when reading this story was 'oh good, they'll probably have to release RISC OS under the GPL, I could really use a legal copy to work with Arcem'. But I soon remembered that copyright in RISC OS is actually held by Pace (makers of DTV set-top boxes) and Castle just do some of the development.
Given that Acorn (and now I think their successors Pace) refused/still refuse to release even the original 1981 OS ROM for the BBC Micro for use in emulators, it seems a bit unreasonable for them to go copying other people's code in this way.
RISC OS was a nice system, especially the graphical interface and anti-aliased outline fonts (which still look better than anything on Linux or Windows, except maybe Acroread). If it were free I might even go back to using it occasionally. Ho hum...
It's a good question. And this is one of the main reasons the FSF asks for copyright assignment on contributed code - so they can go to court if someone infringes (ie, distributes GPLed code under a licence other than GPL) and say unequivocally, we are the copyright holders and the defendant is in breach of copyright.
Linus chose not to require such assignment, so the copyright on the code is held jointly by many people. IANAL, but it seems reasonable that just one of them could still sue if he or she had written a substantial chunk of the copied code. But it's not quite so clear-cut as before.
I hiccup when I eat spicy food. Clearly this is caused by brain circuitry inherited from primaeval tadpole-like creatures trying to crawl their way out of the chilli-infested waters of the Amazon into a cool, fresh pit of naturally occurring yogurt.
Holy guacamole, 'power consumption of less than 1W'? Can this really be true? Maybe the marketing department is taking account of the hours during the day when the notebook is in sleep mode or switched off...
Still, it would be nice to have an Intel chip with low power consumption. Is anyone making desktop systems or motherboards with the mobile chipset?
If all you want is web access, why bother with NAT at all? It is an ugly hack, really. You can just set up a proxy server (squid or wwwoffle) and configure browsers to use that. You'll probably get better performance, too, since the proxy server can do caching. Or you could use NAT for ssh connections and an explicit proxy server for http/https/ftp.
OK, I know there are some NATting products which do caching internally, but it's not as clean as just configuring the web browsers to talk directly to a proxy, and it's more likely to break stuff. (At least, some 'transparent' web caches are horribly broken.)
NASTY hobbitses!
Mount Rainier? Is that the mountain that Rainier Wolfcastle wanted a volunteer to climb to promote Powersauce bars?
Actually I agree with Valenti on this. If your DVD breaks, you get to keep both parts. The right to view the movie comes with the physical possession of the medium - or at least it should IMHO - and so making a backup copy is just the same as any other form of copying.
It sometimes seems that people want to have it both ways. They want to say, it's my disc, I paid for it, I can do what I want with it - but then when it comes to backup copies, or making a copy of music to listen to in the car, they seem to prefer thinking about some 'right to use' the information, which is apparently what you really paid for, and therefore you are justified in transferring it onto a different medium as long as you still only listen to it yourself. The trouble is, once you start down the road of buying a licence rather than buying a physical artefact, you have questions about what your licence allows you to do - like region coding. Much better, IMHO, to stick with the conventional copyright system that gives a monopoly on *making copies* but doesn't get into the world of access controls and licensing a disc for a particular purpose.
OK, these two groups may be disjoint, I know that there is no such thing as 'the Slashdot opinion' which is so often criticized as being inconsistent. And I'm sure that the MPAA/RIAA/etc also switch between the two views of copyright when it suits them. But still, when you argue that the right to use the information (rather than ownership of the physical medium) is what matters, be sure that this is really what you want.
That's not what abusing a position of trust means. It means, when you are placed in a position of responsibility, not living up to the trust placed in you. For example a customs officer who helps in smuggling is abusing a position of trust (among other things). An ordinary person who smuggled goods would not be abusing a position of trust, because they were never in that position to start with. It doesn't just mean general dishonesty or confidence trickery.
So if Mr Mitnick had been appointed as a security consultant and used that to break into systems for personal gain, that would be an abuse of trust. As it is, he doesn't seem to have committed this kind of dishonesty, whatever else he did.
I think we will see 'raising the resolution' become an uncommon operation, since most displays will run at the maximum possible resolution all the time. (For LCDs, you run at the natural resolution of the screen, and it makes no sense to use anything else.) Instead there will be an option in the control panel to 'make things bigger' or 'make things smaller'.
When I installed Linux-Mandrake it defaulted to 800x600 resolution, even though the video card and monitor were capable of much more. But it was a sensible default, since current X11 desktops have (physically) bigger UI elements at low resolutions, and might look too small and fiddly at high resolutions (at least for the new user). If, OTOH, you could trust the desktop and applications to just display at the specified size regardless of pixel resolution, then Mandrake could pick the best quality display without any worries.
Another argument is *say what you mean*. If you want smaller fonts and UI elements to give more space on your desktop, then there should be a preference for 'make the UI smaller'. And if you want to change the number of pixels fitting onto your screen, there should be a preference for that. It doesn't make sense to muddle these two things into a single option, still less to have them in a single option and then various kludges like Windows's 'small fonts / large fonts' option on top.
I think that inexperienced users do not raise the resolution, they may not know what the resolution is. And power users will be just as happy with two options 'raise resolution' and 'make stuff smaller'. I don't think it would be user-unfriendly to replace the current broken system.
Ashley Judd? Who he? For a moment there I thought you said Harry Mudd... now that _would_ be cool...
It's more likely that as free software becomes more widespread, the remaining Microsoft customers are those who will stick with Windows, no matter what. All those customers who are strongly influenced by pricing will already have moved to Linux. So Microsoft's best strategy is to increase its prices further, to get more money out of a smaller customer base (and do it as quickly as possible, before those customers too start to migrate).
In fact, this process may already have started.
It's extremely useful. I have a box where I have a shell account and some web space, but my firewall blocks ssh connections, and besides, not every PC will have an ssh client installed. Being able to go to a web page and run the occasional command would save a lot of time. OK, you couldn't run pine or emacs inside it, but it's still handy.
There is no security problem because access to the CGI script will be protected with the normal user and password mechanisms of the web server. With any half-decent Apache installation that means authenticating over an SSL connection giving your Unix username and password. If the only person who can run the script is you, then you don't really need to worry about exploits because an attacker could not execute the script unless he already had login access to your account.
What surprises me is that there aren't a dozen such CGI programs in existence already.
It's a step towards what we should have had long ago: a desktop where you don't need to know what resolution it's running at, things are just scaled to the correct size. It's crazy that changing to a higher resolution display (eg from 800x600 to 1024x768 on the same monitor) makes all the window decorations and icons smaller. Fonts are supposed to remain the same size, but often they don't.
Obviously for really low resolutions the scale might need to be increased to keep things readable, but a 3200x2400 desktop should look identical to 800x600 except for increased sharpness and detail. (You can still choose really tiny icons if you want them, of course.)
Looking at the way AMD moved to 64 bits - with pretty much the same instruction set, just widening some registers and adding a few registers - you wonder why the same hasn't happened more widely. Why is there no 64 bit ARM, for example?
Or why don't Centaur/VIA widen the registers on their C3 chip and release it as Opteron-compatible? The performance would suck relative to Opteron, of course, but for people who were buying Opteron servers and wanted compatible hardware it could be a competitor to the Athlon 64.
Of course Hammer/Opteron/Athlon 64 is not just 'take the existing Athlon and make some paths a bit wider'. It's a new chip which performs better than the current Athlon. But when designing a CPU, surely you can make the design parameterized by register width and produce 16/32/64 bit versions with only one lot of design and validation effort.
Q. What do you call an error message which contains no useful information?
A. An advertisement.