Oh great, go around drawing on bits of other people's walls so it becomes a bit easier to leech off some third person's network connection.
If these people are so technically clued-up, why not use computers to do the work? Store the geographical information in a file and download it to your machine once a week or so. Then either use GPS or just type in the street name.
IBM's PS/2 Model 95 (one of the last PS/2 MCA-bus machines, mainly for use as a server) came with a built-in LCD display... there's now a Linux driver for it.
Out of interest how do you bind keys for buffer cycling? I tried to set it up once but I couldn't find the command to _cycle_ through buffers rather than switching back and forth like C-x b.
If you were outbid by 'one damn dollar', and you would still have been happy to buy the item for $1 more, then why didn't you put in a slightly higher bid to start with?
A maximum bid is just that, a maximum. You are saying, if the price is more than this maximum then I'm not interested. Even if it is just one dollar more. That's a difficult decision I know, but you have to draw the line.
Is there any way we can find out what kind of suggestions Google receives from the public? It would be quite interesting to look at them all, and maybe some of them could now be implemented using the Google API.
It seems that the UI of most Unix software (the shell, Emacs, even X) has changed much less over the last 20 years than DOS/Windows, and is still changing more slowly now. Is this an explanation for why Unix users typically learn more of the intricate features of their software? Or does the causation run the other way round - because all the obscure Emacs keybindings are so well known by its users (and developers), they can't be changed?
Re:There is nothing wrong with RPMs. Only packager
on
Is RPM Doomed?
·
· Score: 2
Absolutely. The points raised in the article have _nothing_ to do with the choice of RPM as package format.
Point one: dependency hell. When you install a binary package it requires several updated libraries, each of which may require other upgrades... well yes, of course, if it's built against a particular library version then it may require those versions. At least with RPM and other packaging tools you get a warning about what is required. Don't shoot the messenger.
The comparison with Debian: it's just because Debian put lots of effort into upgradability, and most RPM-based distros don't worry about it to quite the same extent. Talk to someone who started with Corel Linux and wanted to update some packages, and you'll see that the choice of RPM vs dpkg vs whatever doesn't matter here. Just the quality of the packages themselves.
RPMs being awkward because files are in different locations: any binary package will have these exact same problems, as long as distributions use differing conventions. This is just the familiar complaint about there not being a single Linux standard which all distros follow.
Then the author goes on to talk about using apt-rpm or Debian, totally missing the point. The reason these tools work so well is a good *collection of packages* put together by the maintainers of those distributions. It's not related much to package formats, beyond some really basic dependencies. The 'switch to Slackware' arguement is similar: Slackware's more upgradable because the packages themselves use the same conventions from one release to the next, not because.tgz is magically superior to.rpm. In a parallel universe where Slackware used RPMs and RedHat used tarballs, the argument 'switch to Slackware' would be just the same.
As far as I can tell, the Distrowatch article is just complaining that it's not always possible to pull random binary packages off the net, install them on your system, and expect them to interoperate with other random binary packages built by other people. Well, duh.
So this compiler lets you access Microsoft's proprietary.Net class libraries. A native code O'Caml compiler can access the hundreds of libraries written in C, on a range of platforms. What's the big deal?
From reading the article it sounds like 90% of the cheats could be addressed if the developers remembered a simple principle: *you cannot trust the client*.
Having some spyware which runs on the individual's PC and looks for known cheat programs is a complete dead-end. It just leads to an endless arms race like that between virus scanners and virus writers. Just like with viruses, the only sensible answer is to eliminate the problem by not trusting code you can't directly control.
Imagine you were building an ecommerce site and you found that some customers were modifying their web browser to send back the wrong price for an item. Would you try to write some tool which runs on the client's PC and detects the browser modification? Of course not, you would just correct the boneheaded decision to let the client send the item price to start with. Such things should always be handled by the server, and any data validation must always be done on the server. The client could do it too, for quicker turnaround and user-friendliness, but if you want any kind of security the server must check for cheating itself.
So the rules of the game should always be enforced at the company's servers. If it's possible for somebody to write a client which lies about how much money the character has - well, you deserve what you get for such a misdesigned game.
In some cases it's not possible or practical to check at the server, for example seeing round walls in first-person shooters. If every screen refresh needed to contact the server to get information on what was visible at that moment, then the game would be horribly slow. So the server has no choice but to send complete information, even including objects which might be invisible, and trust the client to hide some information from the user. But this should be avoided whenever possible.
Another difficulty is bots, which play the game for themselves or assist the human player. It's not so easy to detect those.
- Maybe instead of a constant $10/month, the gaming companies could keep an 'ethical index' for each player and charge more to players that behave rudely, kill others without provocation and so on. But this might distort the structure of the game.
Well SCO UnixWare (aka Caldera OpenUnix), for example, has a Linux personality to let it run many common applications. That does not qualify it as Linux. So if Darwin were simply a collection of APIs layered onto Mach, it would not count as BSD. BSD-compatible, yes, but that same claim can be made by many Unixes.
OTOH, if Darwin actually uses BSD code (in the same way as MkLinux uses Linux code), then it's reasonable to count it as 'BSD' while not giving that title to Linux or Solaris or Cygwin.
The web page you refer to doesn't make it clear whether Darwin is actually based on BSD, or just an implementation of the BSD process model, filesystem, and other APIs. The GNU system is designed to follow BSD Unix - does that mean that Debian should start appearing in the BSD section of Slashdot?
Well there is the mention of 'a customized version of 4.4 BSD-Lite2 kernel'. It's not immediately obvious how to transplant a monolithic kernel to run on top of Mach, but I guess we should take Apple's word for it that you really are running a BSD system: just one that happens to be hosted on Mach in some way. Maybe the objective test is: would a developer who is familiar with 4.4BSD, or FreeBSD or NetBSD, feel at home hacking the Darwin kernel?
Could anyone who knows more about this stuff clarify what is happening? I am assuming that JordanH is not _the_ Jordan H.:-P.
How is Darwin 'based on BSD'? It is a Mach kernel with a BSD personality layered on top. By that argument Linux has a better claim to be 'BSD' than Mac OS X does.
If the Darwin kernel is actually based off the 4.4BSD code then fair enough. But I haven't seen that it is. As far as I can tell, Apple took a microkernel, put a Unix compatibility layer on it and called it 'BSD' for marketing reasons.
It's not because of limited memory but limited address space. The switching between ROMs and RAM needs to happen because there is more than 64Kbyte of total (ROM+RAM) memory in the system, but the 6502 processor has only 16-bit addressing. If memory had been a bit more limited, there wouldn't have been any need for these tricks:-P.
On the BBC Micro you could add 16Kbyte banks of 'sideways RAM'. I remember that some upgrades had a 'read protect' switch, which sounded very odd. I think it was for compatibility; read protect made the upgrade effectively invisible.
SuSE was originally a fork from Slackware, you can still see that in the 'disk sets' a1, a2, ap1 and so on on the CD. (Maybe 8.x has got rid of this, I don't know.)
SuSE moved to RPM a long time ago but they don't always use it to best advantage: they have their own weird conventions for specifying dependencies in spec files instead of using rpm's Requires: and BuildRequires:, so the dependencies can't be checked. Perhaps this is a hangover from Slackware's build scripts.
My understanding was they were developing a single standardized Linux distro. That would most definitely mean dropping the individual installer programs, as well as differences in what is packaged, administration tools and everything else.
If all they did was some token effort at 'consistency' or meaningless certification to slap onto each individual distribution, then it would be no better than what we have now. (Which is not bad; Linux distros are mostly cross-compatible where it matters.)
Still, we'll have to wait for the official announcement to find out what is actually happening.
It's curious that this announcement comes from the three most closed and proprietary (relatively speaking) Linux vendors. Caldera has always been a semi-proprietary distribution, with per-seat licensing and other unpleasantness, and both SuSE and TurboLinux keep some of their own software (such as SuSE's YaST installer) non-free. Say what you like about Red Hat, at least they release all of their code as free software (AFAIK). Yes of course the companies need to make money blah blah blah, I just think it is odd that it should be these three all coming together.
Conectiva appears to be the odd one out; they're a fully free distribution as far as I know.
It's possible that this deal will mean the end of SuSE's and Caldera's and TurboLinux's proprietary installers, since none of the four companies will want the others to get control over the distribution.
It's often said that all science fiction is about the present; maybe that's a bit strong but still you should expect a sci-fi movie to reflect the times in which it was produced. After all, you want present-day audiences to pay to see it.
Couldn't they live in a giant spinning thing in space during the voyage? That's the standard sci-fi answer to low gravity isn't it? At least, you could spend a few hours each day inside some kind of violently spinning chamber so that the centrifugual force would give your heart something to pump against.
In Britain the Computer Misuse Act makes it a criminal offence to access a computer without authorization, or to modify data stored on it. (Other countries must have equivalent laws, of course.) If the Tivo boxes belong to their owners then it sounds like the owners might be able to take Tivo to court (assuming they can persuade the Crown to start a criminal prosecution, which sounds unlikely). Still, at least there is trespass to chattels to consider for a possible civil action. IANAL etc etc.
In a town where the mayor is handing out free guns, you'd better make sure you get some of the best guns for yourself. But the citizens would probably be better off if the mayor behaved more sensibly.
(BTW - I don't mean to start a gun control thread, just for the sake of argument, okay? Please feel free to post a better metaphor if you can think of one.)
Slashdot Mirror
Oh great, go around drawing on bits of other people's walls so it becomes a bit easier to leech off some third person's network connection.
If these people are so technically clued-up, why not use computers to do the work? Store the geographical information in a file and download it to your machine once a week or so. Then either use GPS or just type in the street name.
IBM's PS/2 Model 95 (one of the last PS/2 MCA-bus machines, mainly for use as a server) came with a built-in LCD display... there's now a Linux driver for it.
Out of interest how do you bind keys for buffer cycling? I tried to set it up once but I couldn't find the command to _cycle_ through buffers rather than switching back and forth like C-x b.
If you were outbid by 'one damn dollar', and you would still have been happy to buy the item for $1 more, then why didn't you put in a slightly higher bid to start with?
A maximum bid is just that, a maximum. You are saying, if the price is more than this maximum then I'm not interested. Even if it is just one dollar more. That's a difficult decision I know, but you have to draw the line.
Is there any way we can find out what kind of suggestions Google receives from the public? It would be quite interesting to look at them all, and maybe some of them could now be implemented using the Google API.
It seems that the UI of most Unix software (the shell, Emacs, even X) has changed much less over the last 20 years than DOS/Windows, and is still changing more slowly now. Is this an explanation for why Unix users typically learn more of the intricate features of their software? Or does the causation run the other way round - because all the obscure Emacs keybindings are so well known by its users (and developers), they can't be changed?
Absolutely. The points raised in the article have _nothing_ to do with the choice of RPM as package format.
.tgz is magically superior to .rpm. In a parallel universe where Slackware used RPMs and RedHat used tarballs, the argument 'switch to Slackware' would be just the same.
Point one: dependency hell. When you install a binary package it requires several updated libraries, each of which may require other upgrades... well yes, of course, if it's built against a particular library version then it may require those versions. At least with RPM and other packaging tools you get a warning about what is required. Don't shoot the messenger.
The comparison with Debian: it's just because Debian put lots of effort into upgradability, and most RPM-based distros don't worry about it to quite the same extent. Talk to someone who started with Corel Linux and wanted to update some packages, and you'll see that the choice of RPM vs dpkg vs whatever doesn't matter here. Just the quality of the packages themselves.
RPMs being awkward because files are in different locations: any binary package will have these exact same problems, as long as distributions use differing conventions. This is just the familiar complaint about there not being a single Linux standard which all distros follow.
Then the author goes on to talk about using apt-rpm or Debian, totally missing the point. The reason these tools work so well is a good *collection of packages* put together by the maintainers of those distributions. It's not related much to package formats, beyond some really basic dependencies. The 'switch to Slackware' arguement is similar: Slackware's more upgradable because the packages themselves use the same conventions from one release to the next, not because
As far as I can tell, the Distrowatch article is just complaining that it's not always possible to pull random binary packages off the net, install them on your system, and expect them to interoperate with other random binary packages built by other people. Well, duh.
I've always thought the ship's computer ('Rommie') from Andromeda would make a fairly good assistant.
So this compiler lets you access Microsoft's proprietary .Net class libraries. A native code O'Caml compiler can access the hundreds of libraries written in C, on a range of platforms. What's the big deal?
From reading the article it sounds like 90% of the cheats could be addressed if the developers remembered a simple principle: *you cannot trust the client*.
Having some spyware which runs on the individual's PC and looks for known cheat programs is a complete dead-end. It just leads to an endless arms race like that between virus scanners and virus writers. Just like with viruses, the only sensible answer is to eliminate the problem by not trusting code you can't directly control.
Imagine you were building an ecommerce site and you found that some customers were modifying their web browser to send back the wrong price for an item. Would you try to write some tool which runs on the client's PC and detects the browser modification? Of course not, you would just correct the boneheaded decision to let the client send the item price to start with. Such things should always be handled by the server, and any data validation must always be done on the server. The client could do it too, for quicker turnaround and user-friendliness, but if you want any kind of security the server must check for cheating itself.
So the rules of the game should always be enforced at the company's servers. If it's possible for somebody to write a client which lies about how much money the character has - well, you deserve what you get for such a misdesigned game.
In some cases it's not possible or practical to check at the server, for example seeing round walls in first-person shooters. If every screen refresh needed to contact the server to get information on what was visible at that moment, then the game would be horribly slow. So the server has no choice but to send complete information, even including objects which might be invisible, and trust the client to hide some information from the user. But this should be avoided whenever possible.
Another difficulty is bots, which play the game for themselves or assist the human player. It's not so easy to detect those.
- Maybe instead of a constant $10/month, the gaming companies could keep an 'ethical index' for each player and charge more to players that behave rudely, kill others without provocation and so on. But this might distort the structure of the game.
Well SCO UnixWare (aka Caldera OpenUnix), for example, has a Linux personality to let it run many common applications. That does not qualify it as Linux. So if Darwin were simply a collection of APIs layered onto Mach, it would not count as BSD. BSD-compatible, yes, but that same claim can be made by many Unixes.
OTOH, if Darwin actually uses BSD code (in the same way as MkLinux uses Linux code), then it's reasonable to count it as 'BSD' while not giving that title to Linux or Solaris or Cygwin.
The web page you refer to doesn't make it clear whether Darwin is actually based on BSD, or just an implementation of the BSD process model, filesystem, and other APIs. The GNU system is designed to follow BSD Unix - does that mean that Debian should start appearing in the BSD section of Slashdot?
:-P.
Well there is the mention of 'a customized version of 4.4 BSD-Lite2 kernel'. It's not immediately obvious how to transplant a monolithic kernel to run on top of Mach, but I guess we should take Apple's word for it that you really are running a BSD system: just one that happens to be hosted on Mach in some way. Maybe the objective test is: would a developer who is familiar with 4.4BSD, or FreeBSD or NetBSD, feel at home hacking the Darwin kernel?
Could anyone who knows more about this stuff clarify what is happening? I am assuming that JordanH is not _the_ Jordan H.
How is Darwin 'based on BSD'? It is a Mach kernel with a BSD personality layered on top. By that argument Linux has a better claim to be 'BSD' than Mac OS X does.
If the Darwin kernel is actually based off the 4.4BSD code then fair enough. But I haven't seen that it is. As far as I can tell, Apple took a microkernel, put a Unix compatibility layer on it and called it 'BSD' for marketing reasons.
It's not because of limited memory but limited address space. The switching between ROMs and RAM needs to happen because there is more than 64Kbyte of total (ROM+RAM) memory in the system, but the 6502 processor has only 16-bit addressing. If memory had been a bit more limited, there wouldn't have been any need for these tricks :-P.
On the BBC Micro you could add 16Kbyte banks of 'sideways RAM'. I remember that some upgrades had a 'read protect' switch, which sounded very odd. I think it was for compatibility; read protect made the upgrade effectively invisible.
SuSE was originally a fork from Slackware, you can still see that in the 'disk sets' a1, a2, ap1 and so on on the CD. (Maybe 8.x has got rid of this, I don't know.)
SuSE moved to RPM a long time ago but they don't always use it to best advantage: they have their own weird conventions for specifying dependencies in spec files instead of using rpm's Requires: and BuildRequires:, so the dependencies can't be checked. Perhaps this is a hangover from Slackware's build scripts.
My understanding was they were developing a single standardized Linux distro. That would most definitely mean dropping the individual installer programs, as well as differences in what is packaged, administration tools and everything else.
If all they did was some token effort at 'consistency' or meaningless certification to slap onto each individual distribution, then it would be no better than what we have now. (Which is not bad; Linux distros are mostly cross-compatible where it matters.)
Still, we'll have to wait for the official announcement to find out what is actually happening.
It's curious that this announcement comes from the three most closed and proprietary (relatively speaking) Linux vendors. Caldera has always been a semi-proprietary distribution, with per-seat licensing and other unpleasantness, and both SuSE and TurboLinux keep some of their own software (such as SuSE's YaST installer) non-free. Say what you like about Red Hat, at least they release all of their code as free software (AFAIK). Yes of course the companies need to make money blah blah blah, I just think it is odd that it should be these three all coming together.
Conectiva appears to be the odd one out; they're a fully free distribution as far as I know.
It's possible that this deal will mean the end of SuSE's and Caldera's and TurboLinux's proprietary installers, since none of the four companies will want the others to get control over the distribution.
I wonder if the 'director's cut' includes said cheesy flag scene.
It's often said that all science fiction is about the present; maybe that's a bit strong but still you should expect a sci-fi movie to reflect the times in which it was produced. After all, you want present-day audiences to pay to see it.
Couldn't they live in a giant spinning thing in space during the voyage? That's the standard sci-fi answer to low gravity isn't it? At least, you could spend a few hours each day inside some kind of violently spinning chamber so that the centrifugual force would give your heart something to pump against.
I believe the Assassins actually used opium: just outsiders wrongly thought it was hashish.
In Britain the Computer Misuse Act makes it a criminal offence to access a computer without authorization, or to modify data stored on it. (Other countries must have equivalent laws, of course.) If the Tivo boxes belong to their owners then it sounds like the owners might be able to take Tivo to court (assuming they can persuade the Crown to start a criminal prosecution, which sounds unlikely). Still, at least there is trespass to chattels to consider for a possible civil action. IANAL etc etc.
OK, how about large clubs with nails sticking out. In that case size does matter :-).
In a town where the mayor is handing out free guns, you'd better make sure you get some of the best guns for yourself. But the citizens would probably be better off if the mayor behaved more sensibly.
(BTW - I don't mean to start a gun control thread, just for the sake of argument, okay? Please feel free to post a better metaphor if you can think of one.)