I think that in a permadeath game, the entire play mechanics would have to be shifted. For one, there would be no level 60 - well, maybe there would be, but it wouldn't be anything anyone sane would care to go after. Also, the characters would have to start out with more skills in the first place - I think we can all agree that nobody wants to play a game where you're tooling around with a level 1 weenie that can't do jack half the time.
You could make the penalty for dying something short of losing everything by giving you more skill points, hit points, etc. when you're creating your next character. So if you just lost a level 12 character, your next one would get to start at, say, level 8, and if you just lost a level 6 character, you'd be able to start at level 4.
You could also make it harder to die. I once played a tabletop RPG called Beasts, Men, and Gods where you were knocked unconscious at 0 hit points, and from there you would slowly lose hit points until you either got some medical attention or reached some negative number of hit points which represented death. I personally like this option because it makes those often-overlooked healers people you suddenly want to have in your party.
Personally, I think the above would be really neat ideas. I tend to look at permadeath as a great excuse for a friendly kick in the pants for MMORPG gameplay mechanics, which in my opinion aren't too different from the mechanics used in computer RPGs since the beginning of time.
Sadly, the thing that you would need most to make a permadeath game truly enjoyable is to include a way of making the game fun besides the usual level-grind. While I'd personally like a game of this nature, since I don't enjoy level grinding one bit, I realize that anyone who tries to create a game of this nature is up against 10 years of precedent and tradition as well as the incredible cost it takes to pay for people to make the game world come alive for new players and stay fresh for veterans.
I'm sure it has to be. The only way I can imagine that Excel would be that slow in those calculations is if, for every cell access in the source spreadsheet, it opens the file, find the data for the cell, reads it, and closes the file. If I do the same thing, but with the source data in another sheet in the same spreadsheet rather than in another file, things go much faster.
Meh, I regularly make spreadsheets that are full of calculated cells that depend on another spreadhseet. . . the idea being that since I generally only need to perform XXX analysis on a spreadsheet once, I can set up a system where I give the original some pre-defined name, open the analysis spreadhseet, wait for it to do the calculations, then copy and paste the analysis to save it.
Only problem is, to do, say, seven calculations per row (simple ones, like "=B2-C2" and "=LEFT(D4, 10)" ) on an external spreadsheet that has maybe 500 rows can literally take a full minute.
I shudder to think what the formula-evaluating routines in Excel must look like in order to make such a small number of calculations take so long on a computer that can theoretically perform ~three billion operations per second with the pipelines full.
If you need to protect a port/daemon/service/wakilix from attack, just don't run it.
On a certain unnamed desktop operating system which happens to be getting a lot of press lately and which isn't Windows, it isn't always so easy to "just don't run" services you don't want, either. And I think you forgot the "threat from inside" angle. I think one of the big reasons for personal firewall software that you overlooked is to keep things from getting out. Maybe I don't want any spyware that manages to get a foothold on my computer to be able to phone home. Plus, most 3rd-party personal firewall software that I've seen gives you the ability to grant permission to use a port to some programs but not others, or to grant temporary permission to use a port to a program - nice for giving the user some modicum of protection without interrupting some wanted service. And no, there aren't any major problems with spyware and viruses on said desktop operating system yet, but you can bet your ass that they are coming. Some of us like to put our raincoats on before we step outside.
While I agree that Zork gets a nod for being one of the first, and necessary playing for anyone who likes adventure games, I don't think Zork really defined the genre - though it has some story, and some great scenes and puzzles, I think the gameplay is still too close to its ADVENTURE roots.
If I were to pick one that I think defines the genre, it would have to be either Trinity (if you want to stick to well-known text adventures), or Anchorhead if you're willing to accept games from the amateur IF scene.
MythTV is really only an alternative if you have an old computer that is up to the task just laying around. But I certainly don't, and a quick look at the price involved suggests to me that it would be a heck of a lot cheaper for me to just buy a framegrabber for my Mac and copy shows from the TiVo using its "record to VCR" feature.
You really start to notice the difference with sustained file transfers, such as large files or backups.
If you're not one of the poor saps whose laptop has a 4-pin 1394 port, you also really notice not having to carry a power cord and wall wart for your external hard drive everywhere with you.
You know, I'm fine with my municipality not providing a service that competes with the local phone and cable (and therefore broadband) monopolies.
What I'm not fine with is that the government is opposed to any measure that will introduce competition into this marketplace.
To me, the thing that makes communism such a bad idea in a business sense is that it takes away competition, innovation, and any drive on the part of the service providers to provide a better service. (Unless, of course, they can find a way to use it as an excuse to make their prices even more exhorbitant.) So from my perspective, Charter, SBC, etc. look just as communist as government-provided utilities.
The bug is a way to cause the kernel to create a process whose bsd_info pointer is null, and then cause the kernel to dereference that pointer. There shouldn't be any way to change bsd_info, so there's really no way to use this to cause anything but a kernel panic. (And even if there were, it would be a completely separate issue that happens to involve the same data structure.)
How can this not be serious enough to warrant the time to fix it?
This is the software equivalent of the F00F bug - an incredibly simple and perfectly reliable way to make a system crash - hard - that doesn't require any special privileges or anything, just the ability to execute software, which every user has.
Heh, given the way Microsoft has been all along and the way some bits of J-Random-Free-OSnix (like the desktop environments) are going, I'd say that the truly innovative is is steady refinement over obsessive feature-chasing.
Given that the bug wouldn't be too hard to fix, and is a serious bug, I doubt that that is the case. On the contrary, while it is a bit annoying that this sort of oversight in the kernel design does exist, I think it speaks well for NeXT and Apple that they have not discovered it in all this time.
NEXTSTEP/OS X has an incredibly layered architecture, and those layers are quite well-stratified. That stratification is a great design asset - it makes it a lot easier to keep the whole mess organized, and reduces the number of boundary conditions where bugs (such as this kernel bug:-) can pop up. Now, the fact that OS X has a sort of Mach/BSD - Jekyll/Hyde sort of thing going on in the kernel means that you should expect it to be very tempting for many developers to haphazardly make system calls as they see fit. But if that had been the way development worked at NeXT, you can bet your pants that this bug would have been discovered at least a decade ago. (Mr. Singh doesn't say exactly how far this thing goes back, but I'm going to guess it has been in NEXTSTEP the entire time - about two decades.)
-BUT-, the bug is still there. While I normally hate old bugs as much as anyone, especially ones that cause kernel panics, in this case I am sincerely and profundly impressed at the amount of discipline that must have been present in the development culture at NeXT. (We'll see about Apple - on the inside, Classic MacOS became quite possibly the most tangled kludge of an operating system ever produced in its last few incarnations, and I do get the impression that Apple is starting to take OS X down that path, too.)
Why not just disable USB flash drives and hard disks by removing the drivers?
But if your office is anything like mine, that is going to kill your workflow. I am always using my USB flash drive when I have to collaborate with my co-workers. Maybe your employees are the problem, not your computers? I take company IP home with me fairly frequently, because if I am enjoying what I am working on at the moment, I tend to take it to a coffee shop or park or whatever and work on it in my spare time for the fun of it.
But if it is your employees that are the problem, you have to take some blame with that - either you are hiring bad people, or you are hiring good people and then systematically crushing their motivation and integrity. I would _NEVER_ do work on the side for a company that locks down so tight. . . I'd be so annoyed with my employer that it would be impossible for me to be able to enjoy anything even remotely related to my job. I'd probably also lose touch with that subtle bond of mutual respect that makes me want to help rather than hurt my employer.
So maybe the solution is to be friends with your employees rather than enemies?
Also, sudo only gives you root permissions for a short time. . . if an app needs root privileges, you have to specifically run that app as root, rather than having everything run this way.
This is immensely important if you want to protect your computer from trojan horses, macro viruses, etc. - a great number of Windows viruses and such can't infect the computers of people who don't run as Administrator all the time.
To the third point - ObjC objects aren't toll-free bridged to the Carbon libraries, they are toll-free bridged to Core Foundation, a procedural C set of libraries that is secretly most of what Cocoa is. But the end result is still that, if you need to, you can treat your Objective-C objects as C structs with no extra work.
(Stupid me. I tend to (wrongly) think "C == Carbon" when I think about the OS X libraries.)
Every linux distro I have used since Yggdrasil has done this. Red Hat 5, Slackware ninetywhatever, Mandrake, Gentoo, Debian, Caldera OpenLinux, SuSE. ..
I've settled down in my Distro-hopping, so the examples I used in most cases were over four years old (Yggdrasil most certainly was.:-), but in my experience it's standard practise to start the user off with a root account and make the normal user account optional, possibly with a little admonishment saying that you really shouldn't use root if you can avoid it.
None of them have ever spent much time explaining how sudo works and why you should use it.
If you're looking at writing native software, I would strongly recommend taking the long road and getting used to Objective-C, for a multitude of reasons.
The vast majority of frameworks available for OS X are written in Objective-C, and aren't necessarily well-documented. Even though there is an Objective-C - Java bridge, you'll still have to learn ObjC to use these frameworks just to learn how they work.
In my experience, ObjC apps run faster and consume less memory than Java Cocoa apps. I have also found that this tends to be a bigger issue in the Mac world than it is in the PC world, because Mac users tend to hold onto their computers for much longer. That, and the Java Runtime Environment for Macs doesn't seem to be nearly as well-optimized as the JRE for PCs. (well, Windows, at least.)
Massive portions of the OS X APIs have not been ported to Cocoa yet. If you use ObjC Cocoa, a lot of the ObjC objects you use will be toll-free bridged with the equivalent data structures in the Carbon libraries. It should also be a lot easier to deal with the even older C libraries that haven't even been included in Carbon yet.
But most of all, my impression is that if you're using the Cocoa libraries and the Java language, you have more or less given up all the benefits of the Java platform (such as the ability to write platform-independent apps), as well as the benefits of the Objective-C language (such as categories.) Unless you just really don't want to trade automatic garbage collection for reference counting or just really don't want to learn a new language, you're giving up a lot to gain a little by using Java for Cocoa development.
I'd love to see some numbers on that. To me, it just defies logic that a mugger would prefer to act that way.
Every ATM account jackpotting I know of involves cloning card and catching PIN numbers. Having someone actually take you to the ATM is maximizing the chance that somebody will notice that something is amiss - especially when you're having that person take you to a spot that is frequently visited (like an ATM).
And asking the person for their PIN is silly - everyone is capable of saying four numbers at random.
But most card-oriented crimes I know of skip the ATM thing entirely. involve just taking the person's card and making use of the fact that you can use it as a credit card, and then fence the goods.
You don't need to cut off a person's finger to get their fingerprint, nor do you need to cut out their eyes to have a model for what their retinas look like. In fact, both those plans would be inadvisable since a good biometrics system (which is what you'd be encountering anywhere you're willing to horribly mutilate or kill someone to get into) will involve sensors designed to tell if what's being scanned is alive.
The technology to mimic body identifiers will come. A cheap technique for mimicing a person's fingerprint well enough to fool a biometric scanner is already well-established, and will fool heat-sensing scanners, too, since all you need to do is coat your fingertip with some gelatin and then etch it.
And I would suggest that the "something you have, something you know" system is severely compromised if the "something you have" part is something that can't be voided and replaced. It means that you have to either re-do the entire security system from the ground up to use a different "something you have" whenever someone steals an important "something you have", or you are forced to fire the person who owned that "something you have", or you have to accept that for at least that one person, you no longer have a "something you have, something you know" system.
If you really need it to be attatched to your body, why not put it in the form of some sort of implant, like the ID chips people put in their pets?
I liked the Hitchhiker's series enough that I won't go see it if it doesn't do it justice. I get annoyed at folks who keep giving money to Hollywood just becaue it releases a movie with some characters they like. This whole Ep1&2&3 and remakes thing is a great example - I'd be much happier to see all the Star Wars fans out there vote with their feet to give George Lucas a strong message that he shouldn't take his fans for granted. Instead, they respond to his attempt to rape the series for cash by giving him oodles of cash.
Going to see Hitchhiker's if it's a stinker is even worse - you're rewarding a bunch of worthless freeloaders who don't have any right to lay claim to the Hitchhiker's universe with oodles of cash.
Slashdot Mirror
PDF files are well and good.
But the Acrobat Reader browser-plugin? The only word I can think of to describe it is 'ACK!'
I think that in a permadeath game, the entire play mechanics would have to be shifted. For one, there would be no level 60 - well, maybe there would be, but it wouldn't be anything anyone sane would care to go after. Also, the characters would have to start out with more skills in the first place - I think we can all agree that nobody wants to play a game where you're tooling around with a level 1 weenie that can't do jack half the time.
You could make the penalty for dying something short of losing everything by giving you more skill points, hit points, etc. when you're creating your next character. So if you just lost a level 12 character, your next one would get to start at, say, level 8, and if you just lost a level 6 character, you'd be able to start at level 4.
You could also make it harder to die. I once played a tabletop RPG called Beasts, Men, and Gods where you were knocked unconscious at 0 hit points, and from there you would slowly lose hit points until you either got some medical attention or reached some negative number of hit points which represented death. I personally like this option because it makes those often-overlooked healers people you suddenly want to have in your party.
Personally, I think the above would be really neat ideas. I tend to look at permadeath as a great excuse for a friendly kick in the pants for MMORPG gameplay mechanics, which in my opinion aren't too different from the mechanics used in computer RPGs since the beginning of time.
Sadly, the thing that you would need most to make a permadeath game truly enjoyable is to include a way of making the game fun besides the usual level-grind. While I'd personally like a game of this nature, since I don't enjoy level grinding one bit, I realize that anyone who tries to create a game of this nature is up against 10 years of precedent and tradition as well as the incredible cost it takes to pay for people to make the game world come alive for new players and stay fresh for veterans.
It is hypocritical for this guy to keep bringing this idea up again every time it gets killed.
Not if he starts the debate from the very beginning each time.
I'm sure it has to be. The only way I can imagine that Excel would be that slow in those calculations is if, for every cell access in the source spreadsheet, it opens the file, find the data for the cell, reads it, and closes the file. If I do the same thing, but with the source data in another sheet in the same spreadsheet rather than in another file, things go much faster.
Meh, I regularly make spreadsheets that are full of calculated cells that depend on another spreadhseet. . . the idea being that since I generally only need to perform XXX analysis on a spreadsheet once, I can set up a system where I give the original some pre-defined name, open the analysis spreadhseet, wait for it to do the calculations, then copy and paste the analysis to save it.
Only problem is, to do, say, seven calculations per row (simple ones, like "=B2-C2" and "=LEFT(D4, 10)" ) on an external spreadsheet that has maybe 500 rows can literally take a full minute.
I shudder to think what the formula-evaluating routines in Excel must look like in order to make such a small number of calculations take so long on a computer that can theoretically perform ~three billion operations per second with the pipelines full.
If you need to protect a port/daemon/service/wakilix from attack, just don't run it.
On a certain unnamed desktop operating system which happens to be getting a lot of press lately and which isn't Windows, it isn't always so easy to "just don't run" services you don't want, either. And I think you forgot the "threat from inside" angle. I think one of the big reasons for personal firewall software that you overlooked is to keep things from getting out. Maybe I don't want any spyware that manages to get a foothold on my computer to be able to phone home. Plus, most 3rd-party personal firewall software that I've seen gives you the ability to grant permission to use a port to some programs but not others, or to grant temporary permission to use a port to a program - nice for giving the user some modicum of protection without interrupting some wanted service. And no, there aren't any major problems with spyware and viruses on said desktop operating system yet, but you can bet your ass that they are coming. Some of us like to put our raincoats on before we step outside.
Yeee. . the MSRP on that Canopus ADVC-300 is $600! Buying a PC just for MythTV may be expensive, but it's not that expensive!
While I agree that Zork gets a nod for being one of the first, and necessary playing for anyone who likes adventure games, I don't think Zork really defined the genre - though it has some story, and some great scenes and puzzles, I think the gameplay is still too close to its ADVENTURE roots.
If I were to pick one that I think defines the genre, it would have to be either Trinity (if you want to stick to well-known text adventures), or Anchorhead if you're willing to accept games from the amateur IF scene.
MythTV is really only an alternative if you have an old computer that is up to the task just laying around. But I certainly don't, and a quick look at the price involved suggests to me that it would be a heck of a lot cheaper for me to just buy a framegrabber for my Mac and copy shows from the TiVo using its "record to VCR" feature.
You really start to notice the difference with sustained file transfers, such as large files or backups.
If you're not one of the poor saps whose laptop has a 4-pin 1394 port, you also really notice not having to carry a power cord and wall wart for your external hard drive everywhere with you.
You know, I'm fine with my municipality not providing a service that competes with the local phone and cable (and therefore broadband) monopolies.
What I'm not fine with is that the government is opposed to any measure that will introduce competition into this marketplace.
To me, the thing that makes communism such a bad idea in a business sense is that it takes away competition, innovation, and any drive on the part of the service providers to provide a better service. (Unless, of course, they can find a way to use it as an excuse to make their prices even more exhorbitant.) So from my perspective, Charter, SBC, etc. look just as communist as government-provided utilities.
The bug is a way to cause the kernel to create a process whose bsd_info pointer is null, and then cause the kernel to dereference that pointer. There shouldn't be any way to change bsd_info, so there's really no way to use this to cause anything but a kernel panic. (And even if there were, it would be a completely separate issue that happens to involve the same data structure.)
How can this not be serious enough to warrant the time to fix it?
This is the software equivalent of the F00F bug - an incredibly simple and perfectly reliable way to make a system crash - hard - that doesn't require any special privileges or anything, just the ability to execute software, which every user has.
Heh, given the way Microsoft has been all along and the way some bits of J-Random-Free-OSnix (like the desktop environments) are going, I'd say that the truly innovative is is steady refinement over obsessive feature-chasing.
Given that the bug wouldn't be too hard to fix, and is a serious bug, I doubt that that is the case. On the contrary, while it is a bit annoying that this sort of oversight in the kernel design does exist, I think it speaks well for NeXT and Apple that they have not discovered it in all this time.
:-) can pop up. Now, the fact that OS X has a sort of Mach/BSD - Jekyll/Hyde sort of thing going on in the kernel means that you should expect it to be very tempting for many developers to haphazardly make system calls as they see fit. But if that had been the way development worked at NeXT, you can bet your pants that this bug would have been discovered at least a decade ago. (Mr. Singh doesn't say exactly how far this thing goes back, but I'm going to guess it has been in NEXTSTEP the entire time - about two decades.)
NEXTSTEP/OS X has an incredibly layered architecture, and those layers are quite well-stratified. That stratification is a great design asset - it makes it a lot easier to keep the whole mess organized, and reduces the number of boundary conditions where bugs (such as this kernel bug
-BUT-, the bug is still there. While I normally hate old bugs as much as anyone, especially ones that cause kernel panics, in this case I am sincerely and profundly impressed at the amount of discipline that must have been present in the development culture at NeXT. (We'll see about Apple - on the inside, Classic MacOS became quite possibly the most tangled kludge of an operating system ever produced in its last few incarnations, and I do get the impression that Apple is starting to take OS X down that path, too.)
They sound like typical Mac user responses.
You don't talk to many Windows users, do you? It's pretty much the same thing.
I've also heard pretty similar things from people who say they use Linux, thoug admittedly not nearly as often.
Why not just disable USB flash drives and hard disks by removing the drivers?
But if your office is anything like mine, that is going to kill your workflow. I am always using my USB flash drive when I have to collaborate with my co-workers. Maybe your employees are the problem, not your computers? I take company IP home with me fairly frequently, because if I am enjoying what I am working on at the moment, I tend to take it to a coffee shop or park or whatever and work on it in my spare time for the fun of it.
But if it is your employees that are the problem, you have to take some blame with that - either you are hiring bad people, or you are hiring good people and then systematically crushing their motivation and integrity. I would _NEVER_ do work on the side for a company that locks down so tight. . . I'd be so annoyed with my employer that it would be impossible for me to be able to enjoy anything even remotely related to my job. I'd probably also lose touch with that subtle bond of mutual respect that makes me want to help rather than hurt my employer.
So maybe the solution is to be friends with your employees rather than enemies?
Also, sudo only gives you root permissions for a short time. . . if an app needs root privileges, you have to specifically run that app as root, rather than having everything run this way.
This is immensely important if you want to protect your computer from trojan horses, macro viruses, etc. - a great number of Windows viruses and such can't infect the computers of people who don't run as Administrator all the time.
To the third point - ObjC objects aren't toll-free bridged to the Carbon libraries, they are toll-free bridged to Core Foundation, a procedural C set of libraries that is secretly most of what Cocoa is. But the end result is still that, if you need to, you can treat your Objective-C objects as C structs with no extra work.
(Stupid me. I tend to (wrongly) think "C == Carbon" when I think about the OS X libraries.)
Every linux distro I have used since Yggdrasil has done this. Red Hat 5, Slackware ninetywhatever, Mandrake, Gentoo, Debian, Caldera OpenLinux, SuSE. . .
:-), but in my experience it's standard practise to start the user off with a root account and make the normal user account optional, possibly with a little admonishment saying that you really shouldn't use root if you can avoid it.
I've settled down in my Distro-hopping, so the examples I used in most cases were over four years old (Yggdrasil most certainly was.
None of them have ever spent much time explaining how sudo works and why you should use it.
If you're looking at writing native software, I would strongly recommend taking the long road and getting used to Objective-C, for a multitude of reasons.
The vast majority of frameworks available for OS X are written in Objective-C, and aren't necessarily well-documented. Even though there is an Objective-C - Java bridge, you'll still have to learn ObjC to use these frameworks just to learn how they work.
In my experience, ObjC apps run faster and consume less memory than Java Cocoa apps. I have also found that this tends to be a bigger issue in the Mac world than it is in the PC world, because Mac users tend to hold onto their computers for much longer. That, and the Java Runtime Environment for Macs doesn't seem to be nearly as well-optimized as the JRE for PCs. (well, Windows, at least.)
Massive portions of the OS X APIs have not been ported to Cocoa yet. If you use ObjC Cocoa, a lot of the ObjC objects you use will be toll-free bridged with the equivalent data structures in the Carbon libraries. It should also be a lot easier to deal with the even older C libraries that haven't even been included in Carbon yet.
But most of all, my impression is that if you're using the Cocoa libraries and the Java language, you have more or less given up all the benefits of the Java platform (such as the ability to write platform-independent apps), as well as the benefits of the Objective-C language (such as categories.) Unless you just really don't want to trade automatic garbage collection for reference counting or just really don't want to learn a new language, you're giving up a lot to gain a little by using Java for Cocoa development.
Zappa squatting out a huge sweaty dump while screaming at his fans would be a tongue-in-cheek gesture.
Lucas has been doing the same thing but with complete seriousness for 3/5 of the Star Wars movies he has made so far.
I'd love to see some numbers on that. To me, it just defies logic that a mugger would prefer to act that way.
Every ATM account jackpotting I know of involves cloning card and catching PIN numbers. Having someone actually take you to the ATM is maximizing the chance that somebody will notice that something is amiss - especially when you're having that person take you to a spot that is frequently visited (like an ATM).
And asking the person for their PIN is silly - everyone is capable of saying four numbers at random.
But most card-oriented crimes I know of skip the ATM thing entirely. involve just taking the person's card and making use of the fact that you can use it as a credit card, and then fence the goods.
You don't need to cut off a person's finger to get their fingerprint, nor do you need to cut out their eyes to have a model for what their retinas look like. In fact, both those plans would be inadvisable since a good biometrics system (which is what you'd be encountering anywhere you're willing to horribly mutilate or kill someone to get into) will involve sensors designed to tell if what's being scanned is alive.
The technology to mimic body identifiers will come. A cheap technique for mimicing a person's fingerprint well enough to fool a biometric scanner is already well-established, and will fool heat-sensing scanners, too, since all you need to do is coat your fingertip with some gelatin and then etch it.
And I would suggest that the "something you have, something you know" system is severely compromised if the "something you have" part is something that can't be voided and replaced. It means that you have to either re-do the entire security system from the ground up to use a different "something you have" whenever someone steals an important "something you have", or you are forced to fire the person who owned that "something you have", or you have to accept that for at least that one person, you no longer have a "something you have, something you know" system.
If you really need it to be attatched to your body, why not put it in the form of some sort of implant, like the ID chips people put in their pets?
I liked the Hitchhiker's series enough that I won't go see it if it doesn't do it justice. I get annoyed at folks who keep giving money to Hollywood just becaue it releases a movie with some characters they like. This whole Ep1&2&3 and remakes thing is a great example - I'd be much happier to see all the Star Wars fans out there vote with their feet to give George Lucas a strong message that he shouldn't take his fans for granted. Instead, they respond to his attempt to rape the series for cash by giving him oodles of cash.
Going to see Hitchhiker's if it's a stinker is even worse - you're rewarding a bunch of worthless freeloaders who don't have any right to lay claim to the Hitchhiker's universe with oodles of cash.
(ps - Han shot first.)