And what Certificate Authorities (CA) will your email server consider acceptable?
Any of them.
Two things need to work different from the current system for obtaining web server certs, which is primarily designed around enriching CAs and has a number of flaws when it comes to actually being secure (like, for instance, the look-alike name problem).
First, anyone must be able to produce a certificate endorsing an address as a "non-spam" address and have them publically published. Root CAs and an "email tax" are unacceptable for many, many reasons. A company could have a cert signed by their domain authority and sign off on each employee.
Second, trust must be non-binary (this is where GPG comes up short). People that endorse people that spam have their trust reduced. This is transitive -- people that endorse people that endorse people that spam have their trust slightly reduced. An email would be accepted if it is above some spam threshhold.
While not absolutely required, I would recommend signing on the client (and optionally signing on the server -- the benefit is that companies can quickly switch to a trusted email system without immediately transitioning and changing their clients at the risk of allowing people within their company to impersonate someone else if the company lacks authentication on outbound email.
Most people would probably trust a number of "root authorities" by default, like "ICANN" or the domain name registrars (though I'd guess that such folks would be trusted a relatively low ammount). They'd probably trust their business, which would sign off on businesses that they have business relationships with. This would not require much by way of user-visible functionality.
What happens if Bob's account at Acme Widgets gets compromised and he starts sending out spam? Bob quickly gets lots of certs saying "Bob is a spammer" from folks clicking the "this is a spam" button in their client. Bob's email quickly becomes ignored, and Acme Widgets is trusted somewhat less.
What if Acme Widgets' user-cert-granting system is compromised, and a spammer starts making new "trusted by Acme Widgets" IDs and spamming with them? Eventually, Acme Widgets loses their trust, and mail from their system starts bouncing.
The system could even be modified to avoid horribly blacklisting a company that is badly compromised once -- make such "this is a spammer" certs have a short lifespan at first -- say, a week. Exponentially increase this lifespan by default in clients. If a normally well-trusted domain sends out masses of spam once, they're only "offline" for a week. If they keep doing so, however (say, email security sucks at this place and the email server is rooted once a week), they are rapidly made unusable.
This doesn't rely on a single central authority, doesn't favor businesses over individuals, doesn't make an "email tax", doesn't not require a change en-masse (though people who haven't switched don't recieve the benefits of the system, and such a system becomes more useful the more people are in the system), does not inconvenience those who want to run their own mail server or forward (in fact, it facilitates folks doing exactly that, since they can sign things using their work certificate through their home certificate). The only drawbacks that I can think of are in increased CPU and network usage for normal operation (though the decrease in spam may more than cancel at least the network load out), and the folks who nobody knows or trusts may initially have trouble sending to people. The side effects are *positive* rather than negative -- people lose the ability to spoof email (why email is used as a business tool when it's so easy to intercept and spoof is beyond me), and a distribution system for signing keys could just as easily be used to distribute encryption keys, providing end-to-end content encryption for all users.
So many people seem adamant about converting DNS into some kind of addressing-and-securi
I want to know how SPF/Caller ID (systems with severe side effects) can be seriously proposed without any reasonable attempt to deal with the throwaway domain problem. The SPF folks have some vague hand-waving about trust networks theoretically being a fix, but if we allow a trust network infrastructure, we can provide much better systems (such as signed-by-the-user email) that would eliminate security problems, not have many of the nasty side effects that the Caller ID/SPF proposals do (like the inability to forward, the inability to run one's own mail server, poor (domain-level) granularity when it comes to blacklisting, etc).
I'm particularly frusterated because Microsoft is a crucial element in making something like this come together (without support for signing and trust metrics natively in Outlook/OE, it won't happen) and instead aiming for another "this will slow down spam for six months" hack -- and one that will severely inconvenience "innocent" users once again.
Open Source doesn't, by default, mean more secure any more than a published algorithm is more secure than an unpublished article, only that it has the *potential* to be more secure.
While you are technically correct, I believe that you are being misleading. I have the *potential* to be safer running in front of cars than staying on the sidewalk as well -- the issue that most people would be concerned about is what your chances are.
I think that there are few cryptographers that would trust an unpublished algorithm -- many of us do not trust unpublished code.
That doesn't mean that published code is automatically safe -- just that there are more grounds to trust it.
I agree with you that this hole is not an open-source vs closed-source issue (the problem was in design, and enough of the design was available that someone who wanted to identify this could have done so), though I do think that decision decisions like this remind me more of desktop than traditional *IX developers.
The proper technical way to do this, if the approach was actually feasible, would be to use an additional header, perhaps X-Sexually-Explicit. However, Outlook Express is a crippled email client that cannot filter based on arbitrary headers. Many people use this client, therefore the rest of us must suffer abuse of the Subject line.
I can't speak for the specific long-term IP storage Slashdot does, but Slashdot *does* log IPs for at least 36 hours or so to allow temp-banning people who are mass trolling.
I would personally guess that Slashdot does log IPs long term and is thus able to associate IPs with usernames.
*That* would make an interesting saleable membership option: "log in to your account, check 'post anonymously', and we will not retain any record of your IP/post association after 36 hours".
You only quoted the portion of my post where I was talking about having a hierarchical organization system, so I assumed that was what you were referring to.
I think this would require looking though all the file records, don't you? Especially if they're not indexed and/or in a database.
Okay, as for search strings, yes, you'd have to read the data for all the files (technically, you're wrong about reading all the file records, since using the Boyer-Moore substring matching algorithm could allow doing a search without looking at all the data in the content being searched through) . However, there's no reason not to extract the data to be searched -- album, artist, and title. It's a bit trickier that it might seem, since the iPod exposes a USB Mass Storage interface, which means it sees things as blocks rather than files until it's actively using the filesystem. However, it's pretty easy and computationally inexpensive to lazily index things.
If you allow the iPod to extract id3 tags itself, then you have an id3 database. Say we have an average of 50 bytes (which is probably being over-generous) for those three things). For your 10K song example, that's 500KB to read. I've seen the iPod drive transfer rate conservatively listed at around 3-4MB/sec, which means that it should be able to do such a search in less than a fifth of a second (assuming it's I/O bound, of course, but searching is pretty computationally cheap).
As for battery power, it's unlikely that people are going to search constantly -- just search and use the results, possibly leaving them on their drive as a playlist. So this is not a common operation compared to playing an MP3. In addition, the drive power usage would be about a tenth that of reading a single MP3 (ignoring the decoding and playback battery cost of dealing with the MP3, so I'm being even more conservative with my estimate).
This is not a pair of features that Apple was unable to add to the iPod. It is a pair that they did not add.
I wish that the iPod would have, y'know, Vorbis support. iTunes support doesn't do folks a whole lot of good -- it's easy to use any audio playing application on the Mac, including one that can understand Ogg Vorbis, but when it comes to the iPod, you're stuck.
What *I*'d like to know is why the iPod lacks both a hierarchical organization system (like, folders?) *and* the ability to enter search strings (quite doable with the jog wheel -- search results could be saved as a playlist).
I don't really care about either WMA or AAC, as both are closed formats.
I haven't ever heard of Musepack.
When comparing VBR LAME to Vorbis, doing double-blind tests, I've found that I can tell the difference between Vorbis and original audio at higher bitrates than MP3. However, the vorbis artifacts that I do hear are much less annoying -- percussion sounds slightly different, but MP3 turns cymbals into swooshy sounds.
To be accurate, SMTP (via Sendmail) is enabled by default in RedHat 9, though it only listens on the loopback interface.
And this means that it is only vulnerable to local exploit.
RH9 is also two major releases old. Look at the current Red Hat release -- FC2 -- and you will find not one open port in a default out-of-box workstation install.
For a brief illustration of OS X security issues, may I point you to here?
Nonetheless, that's an astonishing improvement over previous RedHat sins, even as late as v6.2, where a machine was guaranteed to be 0wn3d within 15 minutes of gaining internet access, courtesy of wu-ftpd.
Oh, for Chrissake. That was, what, a year before Mac OS X was even *out*? Windows 2000 had barely been released. I admit that 6.2 was when the Linux userbase was definitely moving away from the "everyone's a sysadmin or *IX hobbyist stage", and so it would have behooved them to have wu-ftpd off by default, but you're having to look a lot of releases back here.
If you want to consider that ancient timeframe and mention local exploits as you did above, consider the fact that the Mac OS of the time had effectively no local security, either on the filesystem or in memory.
Well, you made that comparison, not me. Anyway, my point is that even today, most UNIX and Linux (including RedHat) systems come shipped with lots of services enabled by default, with the exception of Mac OS X (and OpenBSD).
Look what's out there. In one way or another, the market is dominated by killing simulations.
That, my friend, has little to nothing to do with engineers writing code. It's because that's what sells. There have been no shortage of games that were quite different, had artistic merit, weren't bloodfests, and flopped in the marketplace (one of my favorite examples: The Longest Journey. That's what society (well, US society) wants.
So then we ask ourselves -- why is this what society wants?
The main source of glamorizing killing is not, to my way of thinking, video games. It's Hollywood, which has been doing action movies forever, and instilled a good solid bloodlust in the market. Yeah, those "art and humanities" people that are supposed to wisely steer engineers.
Of course, the real root of all this is that violence is exciting because it gets our blood moving -- it's an easy mechanism to use to sell things. But the black turtleneck types were where violent media became popularized for the mass market in the US. The pocket-protector types do not deservve that blame.
It's a religion of polygon counts and frames per second.
Because the largest detracting factor from the terrifying experience of *actually being in such an environment* is how inaccurate current graphics systems are at reproducing such an environment. It's being frantically worked on by many companies.
The commercial text adventure, the literature of the games industry, is long dead.
The IF industry isn't dead -- there's still the occasional commercial release. Lack of IF content producers is not the problem. Have you *played* the amateur games out there? They go much further than the Zorks of yesteryear. The reason that commercial IF has fallen to such a low simmer is that:
(a) current amateur content is so good that it is very difficult to enter the market.
(b) People don't like *thinking* for entertainment. Books have been crucified by movies and TV as a form of entertainment, and the same thing happened in the video games realm. Dead tree authors and TV producers are not the "hard sciency" types that you claim are at fault, and the same thing happens in that arena, and on a far larger scale.
Games with meaningful inter-personal communication are impossibly rare.
Right. This has, if anything, to do with a *lack* of computer science researchers in the game field. It is *extremely* difficult to simulate a human to even a basic conversational level, and to do so effectively is beyond the best of our science. If you want to have interpersonal relationships, you require conversation capable of evoking emotion -- truly *human*-sounding responses. We are not there yet.
And try to name a game that displays more than a passing interest in any the humanistic studies--literature, history, philosophy and, arguably, religion.
The problem is that society as a whole does not seem to be interested in literate entertainment when there is much easier-to-deal-with simple entertainment. Further, efficiency of production of content ri
No TCP/IP services are enabled by default under Mac OS X.
And none of the ones that you're listing as attackable -- SMTP, DNS, HTTP, etc ship on, say, a Red Hat Linux box or have for years (once the userbase stopped being all sysadmins). I think the last release that had good ol' finger still around was 5.x. Oh, and I'm running postfix on my RH box, nicely packaged and all, and you can certainly install sendmail on Mac OS X, just like you can on any other *IXes. It's not *that* uncommon to use something from fink or something that doesn't come stock with OS X -- the only person that I personally know that uses OS X on a home machine runs Apache 2 on it, for instance.
My point is that it's absurd to compare a traditional *IX box of ten years ago to a Mac OS X box of today.
SSL support to the server doesn't do you much good -- the server still gets to see things in plaintext. You need end-to-end encryption to help on this point.
Yeah, I was talking about the other year, not this one.
Yes, I took OS. OS doesn't have much conceptually difficult material. There's a lot of code to write relative to other classes, but the concepts involved are not very difficult. So it's a pain to debug your page management -- it isn't that hard to actually do up the code.
...I'm not saying that there's no merit, but not being able to easily write to the CD with updates is not a trivial issue, and having to rewrite new CDs is a bit of a pain (and would require at least some scripting if you wanted this to be reasonably low-effort). I'm not willing to go through that degree of effort for a relatively slow copy of Linux when all I'm doing is web browsing -- the Windows version of Firefox hardly differs that much from the Linux version.
Now, if I were writing software or something, then things might be different.
Actually, Outlook exploits aren't posted because of severity, it's because it's "further proof that Microsoft is completely incompetent, doesn't care, and everybody's karma is a little low anyway."
I'm not saying that that isn't a factor, but the damage a worm can cause (and that worms *have* caused in the past) are simply much more widespread than a webbrowser exploit.
I built one for my company's website. 2 weeks later it was rooted.
You shoulda seen Linux a couple years ago, when everyone shipped it with finger, sendmail, and everything on earth on out of box, and a slowly growing number of users that didn't have any idea how to turn things off.:-)
Yeah, IMHO, ensuring that security is simple and intuitive is one of the most important UI portions of a piece of software (the most important being that destructive features not be accidentally invoked).
Game design is a different sort of thing though. I think both are interesting. There are a number of properties that a good game should have (and I haven't seen much attempt to analytically break it down). For example, repetition is generally a bad thing. Syncing visual stimmuli to audio stimuli tends to be exciting (if you can put together an intelligent music engine and sync beats to something, you might have something interesting going -- Rez depended heavily on this, for example, but it'd be okay to be less blatently music-oriented. Minimizing time that a player is "out of the game", be it chapter screens or a "death screen" reduces addictiveness, since it provides opportunity for a player to stop playing. Quake did a good job here -- click and you're back in the game. Players become more involved in a game if they feel that they are "gaining" something constantly -- RPGs lived for a while on almost this characteristic alone. So on and so forth...
I went to CMU. I also had the opportunity to work with one of the people in the class a bit early on (I remember one nasty late night session with that guy finding an inverted branch bug in the compiler that Bob Rost had written).
CMU has a couple of game dev classes. James Kuffer teaches an *excellent* game dev class that started on the PC (Windows/Linux, whatever you're interested in) but apparently this year has moved to including the XBox for some folks interested in brewing up XBox games. The party he threw at the end of the class, with game systems and games as prizes, tons of projectors playing games on a huge screen, and people chatting about algorithms and the like was cool. There were guest speakers from a ton of dev houses, and the class was co-taught with someone fromm the UT2004 team. There's another class aimed at game design that I'm not familiar with, and Randy Pausch's Building Virtual Worlds. CMU has recently had a bad streak of luck with graphics classes (every time they start beefing up their graphics department, ATI or NVidia or someone comes in and hires them away -- I never had the opportunity to take Graphics II for this reason), but it's still fun to muck around with this stuff.
While this sort of thing is cool, it's not something that cannot be done anywhere. These classes are more something that people do because they're fun or for the hell of it. NES Dev in particular only gave a three credits (and CMU's metric is roughly a credit for each hour a week you should spend on a class, including homework, which is wildly unrealistic for NES Dev). It's run entirely by a student that thought that getting together a bunch of people who wanted to do up some NES games for the heck of it would be fun. You can do the same thing with folks online. These classes aren't really part of the core curriculum (especially this one).
I do have to say one thing -- while it's neat to have new NES games, the limitations of the system are...stunning. It's very frusterating to do a lot of things, and difficult to indulge in the cleaner designs of today. In many ways, it's nice to develop on newer systems.
I think that CMU is a blast, and I'll recommend it to folks interested in CS (particularly if they want to go into research). However, you really can get a good education anywhere -- if you take classes and do the bare minimum anywhere, you can get by only doing a minimal amount. There are few resources at CMU that you can't get at elsewhere with a bit more effort. Do stuff you're interested in! If you want to learn about networks, run out and add some cool features to one of the P2P clients out there. Like graphics? Hook up with the Crystal Space team or one of the raytracer folks out there, and try implementing somem of your ideas. Hanging out with people that are enthusiastic about the same things you are and like trying out new stuff is, IMHO, the biggest benefit of being somewhere like CMU, and while you may not be able to be physically where you are, they're all over FreeNode and on tons of computer science forums and the like. Even for grad school -- all the stuff you can learn from is out there on research papers, and I've found that professors are marvelously helpful if you simply fire off a randomm, nice email with a question -- I've sent emails to people at all kinds of academic instutions that I wasn't at with short questions that aren't answered on the 'Net, and if they get intrigued (and good professors are generally pretty easy to intrigue) it's often not hard to get a friendly answer or two.
The single best (and IMHO, the toughest) undergrad CS course at CMU is Steven Rudich's 15-251 class. All the course notes assignments, and content are freely available online, and you are free to go through the course yourself. Prof. Rudich is a great lecturer (an example: his first lecture each year involves him ru
Slashdot Mirror
And what Certificate Authorities (CA) will your email server consider acceptable?
Any of them.
Two things need to work different from the current system for obtaining web server certs, which is primarily designed around enriching CAs and has a number of flaws when it comes to actually being secure (like, for instance, the look-alike name problem).
First, anyone must be able to produce a certificate endorsing an address as a "non-spam" address and have them publically published. Root CAs and an "email tax" are unacceptable for many, many reasons. A company could have a cert signed by their domain authority and sign off on each employee.
Second, trust must be non-binary (this is where GPG comes up short). People that endorse people that spam have their trust reduced. This is transitive -- people that endorse people that endorse people that spam have their trust slightly reduced. An email would be accepted if it is above some spam threshhold.
While not absolutely required, I would recommend signing on the client (and optionally signing on the server -- the benefit is that companies can quickly switch to a trusted email system without immediately transitioning and changing their clients at the risk of allowing people within their company to impersonate someone else if the company lacks authentication on outbound email.
Most people would probably trust a number of "root authorities" by default, like "ICANN" or the domain name registrars (though I'd guess that such folks would be trusted a relatively low ammount). They'd probably trust their business, which would sign off on businesses that they have business relationships with. This would not require much by way of user-visible functionality.
What happens if Bob's account at Acme Widgets gets compromised and he starts sending out spam? Bob quickly gets lots of certs saying "Bob is a spammer" from folks clicking the "this is a spam" button in their client. Bob's email quickly becomes ignored, and Acme Widgets is trusted somewhat less.
What if Acme Widgets' user-cert-granting system is compromised, and a spammer starts making new "trusted by Acme Widgets" IDs and spamming with them? Eventually, Acme Widgets loses their trust, and mail from their system starts bouncing.
The system could even be modified to avoid horribly blacklisting a company that is badly compromised once -- make such "this is a spammer" certs have a short lifespan at first -- say, a week. Exponentially increase this lifespan by default in clients. If a normally well-trusted domain sends out masses of spam once, they're only "offline" for a week. If they keep doing so, however (say, email security sucks at this place and the email server is rooted once a week), they are rapidly made unusable.
This doesn't rely on a single central authority, doesn't favor businesses over individuals, doesn't make an "email tax", doesn't not require a change en-masse (though people who haven't switched don't recieve the benefits of the system, and such a system becomes more useful the more people are in the system), does not inconvenience those who want to run their own mail server or forward (in fact, it facilitates folks doing exactly that, since they can sign things using their work certificate through their home certificate). The only drawbacks that I can think of are in increased CPU and network usage for normal operation (though the decrease in spam may more than cancel at least the network load out), and the folks who nobody knows or trusts may initially have trouble sending to people. The side effects are *positive* rather than negative -- people lose the ability to spoof email (why email is used as a business tool when it's so easy to intercept and spoof is beyond me), and a distribution system for signing keys could just as easily be used to distribute encryption keys, providing end-to-end content encryption for all users.
So many people seem adamant about converting DNS into some kind of addressing-and-securi
I want to know how SPF/Caller ID (systems with severe side effects) can be seriously proposed without any reasonable attempt to deal with the throwaway domain problem. The SPF folks have some vague hand-waving about trust networks theoretically being a fix, but if we allow a trust network infrastructure, we can provide much better systems (such as signed-by-the-user email) that would eliminate security problems, not have many of the nasty side effects that the Caller ID/SPF proposals do (like the inability to forward, the inability to run one's own mail server, poor (domain-level) granularity when it comes to blacklisting, etc).
I'm particularly frusterated because Microsoft is a crucial element in making something like this come together (without support for signing and trust metrics natively in Outlook/OE, it won't happen) and instead aiming for another "this will slow down spam for six months" hack -- and one that will severely inconvenience "innocent" users once again.
Open Source doesn't, by default, mean more secure any more than a published algorithm is more secure than an unpublished article, only that it has the *potential* to be more secure.
While you are technically correct, I believe that you are being misleading. I have the *potential* to be safer running in front of cars than staying on the sidewalk as well -- the issue that most people would be concerned about is what your chances are.
I think that there are few cryptographers that would trust an unpublished algorithm -- many of us do not trust unpublished code.
That doesn't mean that published code is automatically safe -- just that there are more grounds to trust it.
I agree with you that this hole is not an open-source vs closed-source issue (the problem was in design, and enough of the design was available that someone who wanted to identify this could have done so), though I do think that decision decisions like this remind me more of desktop than traditional *IX developers.
The proper technical way to do this, if the approach was actually feasible, would be to use an additional header, perhaps X-Sexually-Explicit. However, Outlook Express is a crippled email client that cannot filter based on arbitrary headers. Many people use this client, therefore the rest of us must suffer abuse of the Subject line.
I can't speak for the specific long-term IP storage Slashdot does, but Slashdot *does* log IPs for at least 36 hours or so to allow temp-banning people who are mass trolling.
I would personally guess that Slashdot does log IPs long term and is thus able to associate IPs with usernames.
*That* would make an interesting saleable membership option: "log in to your account, check 'post anonymously', and we will not retain any record of your IP/post association after 36 hours".
You only quoted the portion of my post where I was talking about having a hierarchical organization system, so I assumed that was what you were referring to.
I think this would require looking though all the file records, don't you? Especially if they're not indexed and/or in a database.
Okay, as for search strings, yes, you'd have to read the data for all the files (technically, you're wrong about reading all the file records, since using the Boyer-Moore substring matching algorithm could allow doing a search without looking at all the data in the content being searched through) . However, there's no reason not to extract the data to be searched -- album, artist, and title. It's a bit trickier that it might seem, since the iPod exposes a USB Mass Storage interface, which means it sees things as blocks rather than files until it's actively using the filesystem. However, it's pretty easy and computationally inexpensive to lazily index things.
If you allow the iPod to extract id3 tags itself, then you have an id3 database. Say we have an average of 50 bytes (which is probably being over-generous) for those three things). For your 10K song example, that's 500KB to read. I've seen the iPod drive transfer rate conservatively listed at around 3-4MB/sec, which means that it should be able to do such a search in less than a fifth of a second (assuming it's I/O bound, of course, but searching is pretty computationally cheap).
As for battery power, it's unlikely that people are going to search constantly -- just search and use the results, possibly leaving them on their drive as a playlist. So this is not a common operation compared to playing an MP3. In addition, the drive power usage would be about a tenth that of reading a single MP3 (ignoring the decoding and playback battery cost of dealing with the MP3, so I'm being even more conservative with my estimate).
This is not a pair of features that Apple was unable to add to the iPod. It is a pair that they did not add.
Why would the existence of folders on the iPod ever entail looking through 10K file records?
I mean, I can't think of a single instance where this would be necessary, not even for infrequent operations like the initial addition of the file.
I wish that the iPod would have, y'know, Vorbis support. iTunes support doesn't do folks a whole lot of good -- it's easy to use any audio playing application on the Mac, including one that can understand Ogg Vorbis, but when it comes to the iPod, you're stuck.
What *I*'d like to know is why the iPod lacks both a hierarchical organization system (like, folders?) *and* the ability to enter search strings (quite doable with the jog wheel -- search results could be saved as a playlist).
I don't really care about either WMA or AAC, as both are closed formats.
I haven't ever heard of Musepack.
When comparing VBR LAME to Vorbis, doing double-blind tests, I've found that I can tell the difference between Vorbis and original audio at higher bitrates than MP3. However, the vorbis artifacts that I do hear are much less annoying -- percussion sounds slightly different, but MP3 turns cymbals into swooshy sounds.
To be accurate, SMTP (via Sendmail) is enabled by default in RedHat 9, though it only listens on the loopback interface.
And this means that it is only vulnerable to local exploit.
RH9 is also two major releases old. Look at the current Red Hat release -- FC2 -- and you will find not one open port in a default out-of-box workstation install.
For a brief illustration of OS X security issues, may I point you to here?
Nonetheless, that's an astonishing improvement over previous RedHat sins, even as late as v6.2, where a machine was guaranteed to be 0wn3d within 15 minutes of gaining internet access, courtesy of wu-ftpd.
Oh, for Chrissake. That was, what, a year before Mac OS X was even *out*? Windows 2000 had barely been released. I admit that 6.2 was when the Linux userbase was definitely moving away from the "everyone's a sysadmin or *IX hobbyist stage", and so it would have behooved them to have wu-ftpd off by default, but you're having to look a lot of releases back here.
If you want to consider that ancient timeframe and mention local exploits as you did above, consider the fact that the Mac OS of the time had effectively no local security, either on the filesystem or in memory.
Well, you made that comparison, not me. Anyway, my point is that even today, most UNIX and Linux (including RedHat) systems come shipped with lots of services enabled by default, with the exception of Mac OS X (and OpenBSD).
And my point is that this is not the case.
And he's honest about it, which I suspect a lot of people wouldn't be.
Sigh. What a world we live in.
And do *you* do it?
What on earth is JBoss?
I always wondered what it was, but the official site, instead of giving a concise description, has a bunch of corporatese crap.
This story means that I won't ever have to worry about finding out, which is just good for me.
Look what's out there. In one way or another, the market is dominated by killing simulations.
That, my friend, has little to nothing to do with engineers writing code. It's because that's what sells. There have been no shortage of games that were quite different, had artistic merit, weren't bloodfests, and flopped in the marketplace (one of my favorite examples: The Longest Journey. That's what society (well, US society) wants.
So then we ask ourselves -- why is this what society wants?
The main source of glamorizing killing is not, to my way of thinking, video games. It's Hollywood, which has been doing action movies forever, and instilled a good solid bloodlust in the market. Yeah, those "art and humanities" people that are supposed to wisely steer engineers.
Of course, the real root of all this is that violence is exciting because it gets our blood moving -- it's an easy mechanism to use to sell things. But the black turtleneck types were where violent media became popularized for the mass market in the US. The pocket-protector types do not deservve that blame.
It's a religion of polygon counts and frames per second.
Because the largest detracting factor from the terrifying experience of *actually being in such an environment* is how inaccurate current graphics systems are at reproducing such an environment. It's being frantically worked on by many companies.
The commercial text adventure, the literature of the games industry, is long dead.
The IF industry isn't dead -- there's still the occasional commercial release. Lack of IF content producers is not the problem. Have you *played* the amateur games out there? They go much further than the Zorks of yesteryear. The reason that commercial IF has fallen to such a low simmer is that:
(a) current amateur content is so good that it is very difficult to enter the market.
(b) People don't like *thinking* for entertainment. Books have been crucified by movies and TV as a form of entertainment, and the same thing happened in the video games realm. Dead tree authors and TV producers are not the "hard sciency" types that you claim are at fault, and the same thing happens in that arena, and on a far larger scale.
Games with meaningful inter-personal communication are impossibly rare.
Right. This has, if anything, to do with a *lack* of computer science researchers in the game field. It is *extremely* difficult to simulate a human to even a basic conversational level, and to do so effectively is beyond the best of our science. If you want to have interpersonal relationships, you require conversation capable of evoking emotion -- truly *human*-sounding responses. We are not there yet.
And try to name a game that displays more than a passing interest in any the humanistic studies--literature, history, philosophy and, arguably, religion.
Heck, my favorite FPS does that -- take a look at some of the Marathon Story site. You'll find a number of uses of literature and history, and philosophy. Religion doesn't show up much, though. Here's a sample subset: Shakespeare, Lovecraft , Beowulf (a bit dubious). There are references to mythology (Greek, Egyptian, Nordic), The Song of Roland (also see this, use of Latin, and so forth.
The problem is that society as a whole does not seem to be interested in literate entertainment when there is much easier-to-deal-with simple entertainment. Further, efficiency of production of content ri
The problem is, you rabid *nix d00dz want OSS installed for everything.
Damn straight. I've had it up to here with Darl and SCO users pushing for OSS for everything.
No TCP/IP services are enabled by default under Mac OS X.
And none of the ones that you're listing as attackable -- SMTP, DNS, HTTP, etc ship on, say, a Red Hat Linux box or have for years (once the userbase stopped being all sysadmins). I think the last release that had good ol' finger still around was 5.x. Oh, and I'm running postfix on my RH box, nicely packaged and all, and you can certainly install sendmail on Mac OS X, just like you can on any other *IXes. It's not *that* uncommon to use something from fink or something that doesn't come stock with OS X -- the only person that I personally know that uses OS X on a home machine runs Apache 2 on it, for instance.
My point is that it's absurd to compare a traditional *IX box of ten years ago to a Mac OS X box of today.
SSL support to the server doesn't do you much good -- the server still gets to see things in plaintext. You need end-to-end encryption to help on this point.
Yeah, I was talking about the other year, not this one.
Yes, I took OS. OS doesn't have much conceptually difficult material. There's a lot of code to write relative to other classes, but the concepts involved are not very difficult. So it's a pain to debug your page management -- it isn't that hard to actually do up the code.
15-251 has theoretically difficult content.
...I'm not saying that there's no merit, but not being able to easily write to the CD with updates is not a trivial issue, and having to rewrite new CDs is a bit of a pain (and would require at least some scripting if you wanted this to be reasonably low-effort). I'm not willing to go through that degree of effort for a relatively slow copy of Linux when all I'm doing is web browsing -- the Windows version of Firefox hardly differs that much from the Linux version.
Now, if I were writing software or something, then things might be different.
There is...another...
Patrick Henry American revolutionary, freedom fighter and patriot March 23, 1775
Revolutions are always hijacked by less-than-idealistic profiteers.
George W. Bush is not even remotely Patrick Henry.
If you repeat a lie enough times, it will be believed.
My new sig will be "Monkeys grow on trees".
Actually, Outlook exploits aren't posted because of severity, it's because it's "further proof that Microsoft is completely incompetent, doesn't care, and everybody's karma is a little low anyway."
:-)
I'm not saying that that isn't a factor, but the damage a worm can cause (and that worms *have* caused in the past) are simply much more widespread than a webbrowser exploit.
I built one for my company's website. 2 weeks later it was rooted.
You shoulda seen Linux a couple years ago, when everyone shipped it with finger, sendmail, and everything on earth on out of box, and a slowly growing number of users that didn't have any idea how to turn things off.
Yeah, IMHO, ensuring that security is simple and intuitive is one of the most important UI portions of a piece of software (the most important being that destructive features not be accidentally invoked).
Game design is a different sort of thing though. I think both are interesting. There are a number of properties that a good game should have (and I haven't seen much attempt to analytically break it down). For example, repetition is generally a bad thing. Syncing visual stimmuli to audio stimuli tends to be exciting (if you can put together an intelligent music engine and sync beats to something, you might have something interesting going -- Rez depended heavily on this, for example, but it'd be okay to be less blatently music-oriented. Minimizing time that a player is "out of the game", be it chapter screens or a "death screen" reduces addictiveness, since it provides opportunity for a player to stop playing. Quake did a good job here -- click and you're back in the game. Players become more involved in a game if they feel that they are "gaining" something constantly -- RPGs lived for a while on almost this characteristic alone. So on and so forth...
I went to CMU. I also had the opportunity to work with one of the people in the class a bit early on (I remember one nasty late night session with that guy finding an inverted branch bug in the compiler that Bob Rost had written).
CMU has a couple of game dev classes. James Kuffer teaches an *excellent* game dev class that started on the PC (Windows/Linux, whatever you're interested in) but apparently this year has moved to including the XBox for some folks interested in brewing up XBox games. The party he threw at the end of the class, with game systems and games as prizes, tons of projectors playing games on a huge screen, and people chatting about algorithms and the like was cool. There were guest speakers from a ton of dev houses, and the class was co-taught with someone fromm the UT2004 team. There's another class aimed at game design that I'm not familiar with, and Randy Pausch's Building Virtual Worlds. CMU has recently had a bad streak of luck with graphics classes (every time they start beefing up their graphics department, ATI or NVidia or someone comes in and hires them away -- I never had the opportunity to take Graphics II for this reason), but it's still fun to muck around with this stuff.
While this sort of thing is cool, it's not something that cannot be done anywhere. These classes are more something that people do because they're fun or for the hell of it. NES Dev in particular only gave a three credits (and CMU's metric is roughly a credit for each hour a week you should spend on a class, including homework, which is wildly unrealistic for NES Dev). It's run entirely by a student that thought that getting together a bunch of people who wanted to do up some NES games for the heck of it would be fun. You can do the same thing with folks online. These classes aren't really part of the core curriculum (especially this one).
I do have to say one thing -- while it's neat to have new NES games, the limitations of the system are...stunning. It's very frusterating to do a lot of things, and difficult to indulge in the cleaner designs of today. In many ways, it's nice to develop on newer systems.
I think that CMU is a blast, and I'll recommend it to folks interested in CS (particularly if they want to go into research). However, you really can get a good education anywhere -- if you take classes and do the bare minimum anywhere, you can get by only doing a minimal amount. There are few resources at CMU that you can't get at elsewhere with a bit more effort. Do stuff you're interested in! If you want to learn about networks, run out and add some cool features to one of the P2P clients out there. Like graphics? Hook up with the Crystal Space team or one of the raytracer folks out there, and try implementing somem of your ideas. Hanging out with people that are enthusiastic about the same things you are and like trying out new stuff is, IMHO, the biggest benefit of being somewhere like CMU, and while you may not be able to be physically where you are, they're all over FreeNode and on tons of computer science forums and the like. Even for grad school -- all the stuff you can learn from is out there on research papers, and I've found that professors are marvelously helpful if you simply fire off a randomm, nice email with a question -- I've sent emails to people at all kinds of academic instutions that I wasn't at with short questions that aren't answered on the 'Net, and if they get intrigued (and good professors are generally pretty easy to intrigue) it's often not hard to get a friendly answer or two.
The single best (and IMHO, the toughest) undergrad CS course at CMU is Steven Rudich's 15-251 class. All the course notes assignments, and content are freely available online, and you are free to go through the course yourself. Prof. Rudich is a great lecturer (an example: his first lecture each year involves him ru