% of geeks that enjoy Anime: 93% % of geeks that enjoy "Quake III" type "Sports": 62% % of geeks that enjoy "traditional" Sports: 3%
Well, we have a Games section now and AFAICT any "sports" that most geeks would enjoy would fit there pretty well. If you happen to actually be a geek that actually likes real world sports, well all 7 of you can easily find www.espn.com, you don't need/.
My "dishonest" MP3 collection is entirely copys of friends' collections, which they ripped from their own CDs (and they have copies of my CD collection). Only one person I know uses Kazza et al; my roommate's lifeless 18 year old son who, having no life whatsoever (or music taste for that matter), has all the time in the world to go hunting down music via p2p all day long (and trashing our shared DSL line in the process, just with the search trafic alone, let alone the rare times he actually manages to find the songs he wants to download).
While I can't claim my own life is super filled either, that goes even more to the point that even as un-busy as I am I don't have time to waste searching for crappy encodings and *slowly* downloading from other Kazza users who've also trashed their DSL connections on their own searches/downloads. Live is far, far too short to waste it on such pathetic activities.
Maybe Kazza life is better sitting in a college dorm where you're sharing mostly via 100BaseT, but somehow I doubt it. For honest people that work for a living and have anything slightly close to an interesting life, the "dishonest alternative" of Kazza et al isn't better, it's complete shit.
Furthermore, if you can actually find music you like on Kazza et al, you obviously have no music taste either.
Geeks, get a life and get a clue. Apple's service is for real people with real lives, and for us it's a fantastic first step. You can take your Kazza and shove it!
For myself I've realized I'm simply not going to send rebates in. I've let $100 rebates go at times that I thought when I bought the item, "It's $100, this I'll send in for sure, I'm not that stupid...". Yes, yes I am...
I must say that my buying life has been much, much less stressful and guilt-free since I adopted the position that rebates simply don't exist. Whatever the non-rebate price is, that's my price and my choice to buy it or not will based on that, not the mythical rebate/smail spam sign up that won't ever actually happen.
FreeBSD jails are chroot jails on major steriods, but in practice not really comparable.
There are dozens of ways to break out (gain access to the full filesystem) of standard chroot jails. Even without filesystem access, chroot jails have the same access to the parent system's resources as any other non-chroot process. Binding sockets, shared memory, etc.
Chroot jails slow a hacker down a bit, but not by much. The methods to break out of a chroot environment are so many and so common that r00tkits easily automate the process.
None of this is true of a FreeBSD "jail". While a FreeBSD jail does run under an alternate root (chroot), that's where the similarity ends. Jailed processes can't create device files (like disk devices that a simple chroot could then mount). Even if the device file exists, a jail process, even one running as root, is denied access to the syscalls required to do a file system mount. A jailed process is bound to a single IP address (typically done as an alias), and can not bind other addresses (again the kernel syscall is blocked for J (jailed) processes). Shared memory can't be accessed through a jail (IIRC a jail can use shared memory with other processes in the same jail, but not with the base system or other jails).
A chroot is little more then a virtual barbed wire fence and about as effective (ie, almost none). A FreeBSD jail is much closer to a fully secured virtual machine, but with almost none of the overhead such a system (think VMWare or User Mode Linux) normally implies.
The original poster is correct; FreeBSD jails have no real equal in Linux or most Unix systems.
So if it's "just" an automatic delegation pattern, could this be yet another programing methodology that Perl has "built in" support for? -For those not familar, Perl's AUTOLOAD system can make quick work of mass delegation, even if you're targeting multiple possible delegate objects.
,not haveing a drivers license bars you from participating in a wide variety of activities in this country.
I'm curious; have you ever actually made a real effort to live without the use of a car? As someone who's been car-free by choice for about four years now, I'll be a bit presumtious and guess not.
While you've "Heard this crap before", so have I, from the other side of the fence. On a good day only about one in ten of the drivers on the road should be anywhere near a car. While I'll quickly admit the US is far, far behind most sane countries wrt cycling and transit programs, it's not in the complete stone age. You aren't barred from anything by not having a license. In many parts of the country, you're infact liberated by the lack of a license.
Disclaimer: I'm a FreeBSD fan and generally consider Linux et al to be one of the most choatic and sloppy large-scale development projects ever created. Just being a Linux user requires dealing with an absolutely insane about of pointless choas; I fear to imagine what trying to be a maintainer must be like...
That said...
"Just use CVS" isn't anything remotely close to an answer. SCM, release control, whatever you'd like to call it is 99% about the PROCESS, not the tools. CVS is a tool. It's a great tool and one I highly recommend, but at best it's 1% of a solution. It seems quite obvious that Linus's current process is incredibly flawed. It would seem a drastically different process needs to be devised. Only once you have figured out what your process is going to be can you even start shopping for tools (CVS, whatever) to help you create it (and even then...the tools are only 1%, if you even have tools. The PROCESS is what's important).
Of course "CVS forks" of Linux failed. Anyone with even the slightest understanding of CM could have easily predicted such an end. You've got a handful of people, not even the top people, trying to constantly fold in the efforts of thousands of contributers all using a completely different process (ad-hoc patches emailed to devnull@linus.org). What did you expect?
You have two choices. Devise a workable process which Linus will agree to (with or without CVS, whatever). Or, you can devise a workable process that everyone else is happy with...and simply throw Linus off his paper throne. The first option will likely never, ever happen...at least if every single word Linus has ever uttered on the subject isn't true. The second option might actually welcome the dawn of a non-choatic Linux, one which wouldn't be so easily cast aside as a cheap toy made by a small man with a big ego.
The article is mostly talking about building games, and the ability to create the tools to do so.
That said, think about the market for the "highend" gamers. You know...the %4 of us that actually buy a GeForce 3 when they first come out? Many such gamers would love to move off of Windows, especially the 98 variants. While Win2k helps a lot, in the end it's still Windows. Many are pushing for Linux to be the next great gaming OS, so much so that more then a few major game companies have already targeted it (even if not completely successful, ala Loki). Linux however, has a long, long way to go (to be very, very kind).
If all the "hot new games" start coming out for Mac (even if they also come out for Windows and/or Linux), it suddenly makes Mac an extremely attractive system for gamers. Gamers of course, being the only people who own a computer that are likely to actually buy a new one before 2030...
Now, if building games on Mac is easier, faster, and thus results in better games to market sooner...
If building a game under Mac implies open standards such as OpenGL instead of DirectX, thus enabling the game to target Mac, Windows, Linux, etc without nearly so much trouble...
The math becomes easy. Develop under Windows and we sell to say, 90% of the market. Develop our game under Mac and we sell to 100% of the market (5% Mac lets say another %5 Linux/Other)...AND we get to market faster AND our development is cheaper... The choice is clear, IMHO.
You're making the assumtion that there is much/any improvement on MS's part to the BSD TCP/IP stack code.
What do you want "passed back"? Windows itself? If you're a GPL advocate, the answer of course is, "YES! A small fragement of Windows used our code so now we should by RIGHT have full and complete access to everything that is Windows!".
But that's an even sillier argument then it sounds out loud...
If possibilities like MS using the BSD network stack kept BSD developers up at night, they wouldn't be developing BSD licensed code. If such things do keep you up at night, then you shouldn't consider writing free software, and thus probably use the GPL.
# IPSTEALTH enables code to support stealth forwarding (i.e., forwarding
# packets without touching the ttl). This can be useful to hide firewalls
# from traceroute and similar tools.
Simply add "option IPSTEALTH" to your kernel config and rebuild. *poof* Firewall? What firewall?
Of course, you'll probably want to couple this with the standard anti-stack finger printing methods of IPF/IPFW, but the idea of "Stealth NAT/firewall" isn't particuarly new.
Sure, you can return you disk for a non-protected one...but to do so you need to call a number (thus likely giving them your phone number) and likely give them your name, home address, and maybe the store you got it at.
Seems to me like a pretty good way to start making a list of potential "law breakers". "See how many people are ADMITTING to breaking the law!"
Of course, all this is mute if one can exchange the disk without disclosing any information at the record store or such (hidden cameras not withstanding), but still for those that do call and do it by mail, who DOESN'T think they will make an explicit effort to create such a list?
There are rare exceptions, to be sure (one extremely notiable exception you didn't list is Half-Life and with it Counter-Strike), but for the vast, vast majority the life span is incredibly short. And even better point however...is looking at how incredibly few of those exceptionally long-living games haven't been ported to other platforms.
Remember, the extra coding required isn't the only cost for multi-platform...you have to think about QA, packaging (which is typically a different box per OS), and most importantly...tech support.
The added tech support costs alone could very likely eat up not just the extra ~8% you made by selling to Mac/Linux users (I'm being generous here), but quite likely go far beyond that and start eatting the profits otherwise gleamed from your primary platform.
My platform of choice for general use is FreeBSD, but my game boxes have been, and for the forseeable future will be, Windows.
I hate to say it, but even if the next five games I'll likely want to buy (Dark Age of Camelot, Shadowbane, Operation: Flashpoint, EVE - The
Second Genesis, Earth and Beyond) all were released for FreeBSD (or Linux, Mac, whatever), I still would buy the Windows versions. For as much as I too dispise the Evil that is forged in Redmond, there simply is not to be found a single champion with the might to stand against it.
If Linux wants games...it has to stop sucking complete ass as a gaming platform (which isn't likely...ever, IMHO). The only possible challenger at this point to the all mighty Windows for a gaming system is MacOS X. But it's not there yet, at the very least it needs to prove itself (as a game platform).
By the way, BSD didn't exist in a Free form until after Linux was already started.
Yes and no. It did exist in "free form", then it got attacked by AT&T (for trying to be "free") and was in limbo until the courts and coders pulled the last bits of AT&T code out and created 4.4BSD Lite. Had this useless exchange never happened, it's very unlikely that Linux would have existed at all. -At least according to interviews I've read of Linus, stating how he'd probably have just used FreeBSD for study way back when...if it hadn't been encombered.
On other notes...
BSD didn't invent TCP/IP, but it did give Unix it's first incarnation through the Berkeley Sockets interface. First VM in a Unix system was also BSD. Reliable signals, BSD again. Fast File System, BSD. Passing descriptors over UDP, BSD.
Not that SysV just stood there. Most all ideas from BSD have been adopted by SysV, as well as many the other way (shared memory, streams, etc).
A HUGE part of what all Unix is today is directly traced to BSD work. Work from Linux so far, hasn't shown really up anywhere else. Don't get me wrong, Linux is a great system...but innovative it isn't. Thankfully, one doesn't need to innovate to be useful. -Hell, if that was the case Unix itself would be long since dead.:-)
Who needs to bust the thing out? All you need to do is block the lens, no need to blow it away.
A paintball gun won't likely get you as much time as a.22, is quieter, cheaper, and doesn't require a license.
I'm playing Desu Ex right now...and there are security cameras everywhere, including in the streets. Life mimicing art I guess...
Well, perhaps if you had read the other/. article recently about TiVo, you'd understand why "downgrading" to 1.3 would be far from pointless or stupid. Perhaps you should join the world of the clueful before proclaiming something stupid...
When we yell about this site or that site getting cracked while using MS products, it is typically tied with a report explicitly stating that it was, infact, a MS product that had the security hole.
But right now, we don't know anything about this attack. We don't even know if software is to blame. It could be a bad admin, it could be a buggy kernal patch, it could be someone sniffed an admin's root password while they unknowingly used a cracked copy of MS Terminal on a Windows box...
Until we know what actually happend we can spin it any which way.
Sorry, but computer equipment requires DC...but at many different voltages. To efficently convert from one voltage to another you need transformers...which require AC.
No, to make practical use of solar power you need to bring it up to line spec, 110 volts/60hz. The fact solar power source is DC is a disadvantage, not an advantage.
About the cold/high humidity air...sure, it's fine as it passes over hot components like the CPU...but what happends when it's around systems that don't run very hot? You can't fry an egg on everything found in a datacenter. You talk about dew drops...I'd hate to see what happends when dew starts to form on the cooler parts of many computer systems...
Do you have any URLs pointing to anyone trying to sink large amounts of heat through the earth?
Palamino, etc chips will be great...but still 1/2 mil of them is going to be hot. And that's ignoring the fact that all the world is not x86, but maybe if we bury the E10ks in the ground the'll stay cool enough.:-)
Actually, for Half-Life there's a program called PunkBuster which does just this, and a few other things. Half-Life has a mostly-unused challenge-response system for this; PunkBuster checks file sizes to detect known cheats and disconnects anyone using one. It also does some other tricks (how they work is not well publicized) to detect external cheats, probably involving some memory scanning.
PunkBuster was an interesting idea, but failed. Counter-cheats to PB have often taken only hours to be released after a given PB update. One of the large problems is that it's impossible to reliably CRC check files on a client machine from a server....For starters, you can't even be sure you're actually talking to the same client machine that is running the game. NAT the PB traffic to a "good" machine and the "l33t" machine continues to freely run.
PunkBuster was a valiant effort made by people who sadly have very little idea what they are really up against. Apparently...they still don't...
This is an interesting proposal, but I'll tell you this, and I'm not alone: I will not play on any computer but my own, ever, especially not at a LAN party. Moving to a new computer means moving to new input devices; I find it takes days at the very least to get used to new input devices. This would also be strongly discriminating against people with unusual control devices (joysticks, trackballs, DVORAK keyboards--yes, they are out there) and, much worse, people with unusual control configurations (I'm left-handed, and couldn't possibly play with any config vaguely resembling default.
Ditto. Anyone that would be able to compete at this level is going to be in a similar boat.
Including my scripts, my configuration is massive (I compile them with a preprocessor), and couldn't possibly be reconstructed by hand).
Ok, this is pushing it, I think... A preprocessor?!?! What game are these configs for again? There is a fair amount of power in most FPS scripting engines...but not that much. I'd be very interested in what you found you needed to pass off to a preprocessor.
IMHO, it would be fine for most people to simply bring their configs on a floopy/CDR and loaded by an "official" of the event. Automated text scanners could detect most/all of the config cheats and such (lambert, gl_zmax, fast walk, etc).
If people were to move between computers, their configuration files, their input devices, and the drivers for those input devices would have to move with them--and since device drivers are arbitrarily powerful executables, that puts you right back at the start.
I'd say let them bring their own input devices. Drivers shouldn't be an issue, simply download them at the event from the company website.
-Unless someone thinks that a gamer will have a friend at Logitech who will be able to get hacked drivers put up on the company web site for a day. Anyone with "off-brand" input devices could simply apply for approval before the event.
In the world of online gaming, there are tons of exploits at every level. Even simply tweaking the gamma level of the monitor in the basic Windows control panel can yeld HUGE advantages in tactical games such as Counter-Strike, as it effectively removes all dark hiding places. Monitors would have to have their configs locked down, including the external adjustments.
Slashdot Mirror
Er, yah...right...
/.
% of geeks that enjoy Anime: 93%
% of geeks that enjoy "Quake III" type "Sports": 62%
% of geeks that enjoy "traditional" Sports: 3%
Well, we have a Games section now and AFAICT any "sports" that most geeks would enjoy would fit there pretty well. If you happen to actually be a geek that actually likes real world sports, well all 7 of you can easily find www.espn.com, you don't need
Better my ass.
My "dishonest" MP3 collection is entirely copys of friends' collections, which they ripped from their own CDs (and they have copies of my CD collection). Only one person I know uses Kazza et al; my roommate's lifeless 18 year old son who, having no life whatsoever (or music taste for that matter), has all the time in the world to go hunting down music via p2p all day long (and trashing our shared DSL line in the process, just with the search trafic alone, let alone the rare times he actually manages to find the songs he wants to download).
While I can't claim my own life is super filled either, that goes even more to the point that even as un-busy as I am I don't have time to waste searching for crappy encodings and *slowly* downloading from other Kazza users who've also trashed their DSL connections on their own searches/downloads. Live is far, far too short to waste it on such pathetic activities.
Maybe Kazza life is better sitting in a college dorm where you're sharing mostly via 100BaseT, but somehow I doubt it. For honest people that work for a living and have anything slightly close to an interesting life, the "dishonest alternative" of Kazza et al isn't better, it's complete shit.
Furthermore, if you can actually find music you like on Kazza et al, you obviously have no music taste either.
Geeks, get a life and get a clue. Apple's service is for real people with real lives, and for us it's a fantastic first step. You can take your Kazza and shove it!
For myself I've realized I'm simply not going to send rebates in. I've let $100 rebates go at times that I thought when I bought the item, "It's $100, this I'll send in for sure, I'm not that stupid...". Yes, yes I am...
I must say that my buying life has been much, much less stressful and guilt-free since I adopted the position that rebates simply don't exist. Whatever the non-rebate price is, that's my price and my choice to buy it or not will based on that, not the mythical rebate/smail spam sign up that won't ever actually happen.
Rebates suck.
FreeBSD jails are chroot jails on major steriods, but in practice not really comparable.
There are dozens of ways to break out (gain access to the full filesystem) of standard chroot jails. Even without filesystem access, chroot jails have the same access to the parent system's resources as any other non-chroot process. Binding sockets, shared memory, etc.
Chroot jails slow a hacker down a bit, but not by much. The methods to break out of a chroot environment are so many and so common that r00tkits easily automate the process.
None of this is true of a FreeBSD "jail". While a FreeBSD jail does run under an alternate root (chroot), that's where the similarity ends. Jailed processes can't create device files (like disk devices that a simple chroot could then mount). Even if the device file exists, a jail process, even one running as root, is denied access to the syscalls required to do a file system mount. A jailed process is bound to a single IP address (typically done as an alias), and can not bind other addresses (again the kernel syscall is blocked for J (jailed) processes). Shared memory can't be accessed through a jail (IIRC a jail can use shared memory with other processes in the same jail, but not with the base system or other jails).
A chroot is little more then a virtual barbed wire fence and about as effective (ie, almost none). A FreeBSD jail is much closer to a fully secured virtual machine, but with almost none of the overhead such a system (think VMWare or User Mode Linux) normally implies.
The original poster is correct; FreeBSD jails have no real equal in Linux or most Unix systems.
So if it's "just" an automatic delegation pattern, could this be yet another programing methodology that Perl has "built in" support for? -For those not familar, Perl's AUTOLOAD system can make quick work of mass delegation, even if you're targeting multiple possible delegate objects.
,not haveing a drivers license bars you from participating in a wide variety of activities in this country.
I'm curious; have you ever actually made a real effort to live without the use of a car? As someone who's been car-free by choice for about four years now, I'll be a bit presumtious and guess not.
While you've "Heard this crap before", so have I, from the other side of the fence. On a good day only about one in ten of the drivers on the road should be anywhere near a car. While I'll quickly admit the US is far, far behind most sane countries wrt cycling and transit programs, it's not in the complete stone age. You aren't barred from anything by not having a license. In many parts of the country, you're infact liberated by the lack of a license.
Disclaimer: I'm a FreeBSD fan and generally consider Linux et al to be one of the most choatic and sloppy large-scale development projects ever created. Just being a Linux user requires dealing with an absolutely insane about of pointless choas; I fear to imagine what trying to be a maintainer must be like...
That said...
"Just use CVS" isn't anything remotely close to an answer. SCM, release control, whatever you'd like to call it is 99% about the PROCESS, not the tools. CVS is a tool. It's a great tool and one I highly recommend, but at best it's 1% of a solution. It seems quite obvious that Linus's current process is incredibly flawed. It would seem a drastically different process needs to be devised. Only once you have figured out what your process is going to be can you even start shopping for tools (CVS, whatever) to help you create it (and even then...the tools are only 1%, if you even have tools. The PROCESS is what's important).
Of course "CVS forks" of Linux failed. Anyone with even the slightest understanding of CM could have easily predicted such an end. You've got a handful of people, not even the top people, trying to constantly fold in the efforts of thousands of contributers all using a completely different process (ad-hoc patches emailed to devnull@linus.org). What did you expect?
You have two choices. Devise a workable process which Linus will agree to (with or without CVS, whatever). Or, you can devise a workable process that everyone else is happy with...and simply throw Linus off his paper throne. The first option will likely never, ever happen...at least if every single word Linus has ever uttered on the subject isn't true. The second option might actually welcome the dawn of a non-choatic Linux, one which wouldn't be so easily cast aside as a cheap toy made by a small man with a big ego.
Linux/Linus Flame (-1k Karma)
The article is mostly talking about building games, and the ability to create the tools to do so.
That said, think about the market for the "highend" gamers. You know...the %4 of us that actually buy a GeForce 3 when they first come out? Many such gamers would love to move off of Windows, especially the 98 variants. While Win2k helps a lot, in the end it's still Windows. Many are pushing for Linux to be the next great gaming OS, so much so that more then a few major game companies have already targeted it (even if not completely successful, ala Loki). Linux however, has a long, long way to go (to be very, very kind).
If all the "hot new games" start coming out for Mac (even if they also come out for Windows and/or Linux), it suddenly makes Mac an extremely attractive system for gamers. Gamers of course, being the only people who own a computer that are likely to actually buy a new one before 2030...
Now, if building games on Mac is easier, faster, and thus results in better games to market sooner...
If building a game under Mac implies open standards such as OpenGL instead of DirectX, thus enabling the game to target Mac, Windows, Linux, etc without nearly so much trouble...
The math becomes easy. Develop under Windows and we sell to say, 90% of the market. Develop our game under Mac and we sell to 100% of the market (5% Mac lets say another %5 Linux/Other)...AND we get to market faster AND our development is cheaper... The choice is clear, IMHO.
You're making the assumtion that there is much/any improvement on MS's part to the BSD TCP/IP stack code.
What do you want "passed back"? Windows itself? If you're a GPL advocate, the answer of course is, "YES! A small fragement of Windows used our code so now we should by RIGHT have full and complete access to everything that is Windows!".
But that's an even sillier argument then it sounds out loud...
If possibilities like MS using the BSD network stack kept BSD developers up at night, they wouldn't be developing BSD licensed code. If such things do keep you up at night, then you shouldn't consider writing free software, and thus probably use the GPL.
From FreeBSD (/usr/src/sys/i386/conf/LINT):
# IPSTEALTH enables code to support stealth forwarding (i.e., forwarding
# packets without touching the ttl). This can be useful to hide firewalls
# from traceroute and similar tools.
Simply add "option IPSTEALTH" to your kernel config and rebuild. *poof* Firewall? What firewall?
Of course, you'll probably want to couple this with the standard anti-stack finger printing methods of IPF/IPFW, but the idea of "Stealth NAT/firewall" isn't particuarly new.
Sure, you can return you disk for a non-protected one...but to do so you need to call a number (thus likely giving them your phone number) and likely give them your name, home address, and maybe the store you got it at.
Seems to me like a pretty good way to start making a list of potential "law breakers". "See how many people are ADMITTING to breaking the law!"
Of course, all this is mute if one can exchange the disk without disclosing any information at the record store or such (hidden cameras not withstanding), but still for those that do call and do it by mail, who DOESN'T think they will make an explicit effort to create such a list?
There are rare exceptions, to be sure (one extremely notiable exception you didn't list is Half-Life and with it Counter-Strike), but for the vast, vast majority the life span is incredibly short. And even better point however...is looking at how incredibly few of those exceptionally long-living games haven't been ported to other platforms.
Remember, the extra coding required isn't the only cost for multi-platform...you have to think about QA, packaging (which is typically a different box per OS), and most importantly...tech support.
The added tech support costs alone could very likely eat up not just the extra ~8% you made by selling to Mac/Linux users (I'm being generous here), but quite likely go far beyond that and start eatting the profits otherwise gleamed from your primary platform.
My platform of choice for general use is FreeBSD, but my game boxes have been, and for the forseeable future will be, Windows.
I hate to say it, but even if the next five games I'll likely want to buy (Dark Age of Camelot, Shadowbane, Operation: Flashpoint, EVE - The Second Genesis, Earth and Beyond) all were released for FreeBSD (or Linux, Mac, whatever), I still would buy the Windows versions. For as much as I too dispise the Evil that is forged in Redmond, there simply is not to be found a single champion with the might to stand against it.
If Linux wants games...it has to stop sucking complete ass as a gaming platform (which isn't likely...ever, IMHO). The only possible challenger at this point to the all mighty Windows for a gaming system is MacOS X. But it's not there yet, at the very least it needs to prove itself (as a game platform).
By the way, BSD didn't exist in a Free form until after Linux was already started.
:-)
Yes and no. It did exist in "free form", then it got attacked by AT&T (for trying to be "free") and was in limbo until the courts and coders pulled the last bits of AT&T code out and created 4.4BSD Lite. Had this useless exchange never happened, it's very unlikely that Linux would have existed at all. -At least according to interviews I've read of Linus, stating how he'd probably have just used FreeBSD for study way back when...if it hadn't been encombered.
On other notes...
BSD didn't invent TCP/IP, but it did give Unix it's first incarnation through the Berkeley Sockets interface. First VM in a Unix system was also BSD. Reliable signals, BSD again. Fast File System, BSD. Passing descriptors over UDP, BSD.
Not that SysV just stood there. Most all ideas from BSD have been adopted by SysV, as well as many the other way (shared memory, streams, etc).
A HUGE part of what all Unix is today is directly traced to BSD work. Work from Linux so far, hasn't shown really up anywhere else. Don't get me wrong, Linux is a great system...but innovative it isn't. Thankfully, one doesn't need to innovate to be useful. -Hell, if that was the case Unix itself would be long since dead.
Who needs to bust the thing out? All you need to do is block the lens, no need to blow it away. A paintball gun won't likely get you as much time as a .22, is quieter, cheaper, and doesn't require a license.
I'm playing Desu Ex right now...and there are security cameras everywhere, including in the streets. Life mimicing art I guess...
Well, perhaps if you had read the other /. article recently about TiVo, you'd understand why "downgrading" to 1.3 would be far from pointless or stupid. Perhaps you should join the world of the clueful before proclaiming something stupid...
When we yell about this site or that site getting cracked while using MS products, it is typically tied with a report explicitly stating that it was, infact, a MS product that had the security hole.
But right now, we don't know anything about this attack. We don't even know if software is to blame. It could be a bad admin, it could be a buggy kernal patch, it could be someone sniffed an admin's root password while they unknowingly used a cracked copy of MS Terminal on a Windows box...
Until we know what actually happend we can spin it any which way.
Sorry, but computer equipment requires DC...but at many different voltages. To efficently convert from one voltage to another you need transformers...which require AC.
:-)
No, to make practical use of solar power you need to bring it up to line spec, 110 volts/60hz. The fact solar power source is DC is a disadvantage, not an advantage.
About the cold/high humidity air...sure, it's fine as it passes over hot components like the CPU...but what happends when it's around systems that don't run very hot? You can't fry an egg on everything found in a datacenter. You talk about dew drops...I'd hate to see what happends when dew starts to form on the cooler parts of many computer systems...
Do you have any URLs pointing to anyone trying to sink large amounts of heat through the earth?
Palamino, etc chips will be great...but still 1/2 mil of them is going to be hot. And that's ignoring the fact that all the world is not x86, but maybe if we bury the E10ks in the ground the'll stay cool enough.
PunkBuster was a valiant effort made by people who sadly have very little idea what they are really up against. Apparently...they still don't... Ditto. Anyone that would be able to compete at this level is going to be in a similar boat. Ok, this is pushing it, I think... A preprocessor?!?! What game are these configs for again? There is a fair amount of power in most FPS scripting engines...but not that much. I'd be very interested in what you found you needed to pass off to a preprocessor.
IMHO, it would be fine for most people to simply bring their configs on a floopy/CDR and loaded by an "official" of the event. Automated text scanners could detect most/all of the config cheats and such (lambert, gl_zmax, fast walk, etc). I'd say let them bring their own input devices. Drivers shouldn't be an issue, simply download them at the event from the company website. -Unless someone thinks that a gamer will have a friend at Logitech who will be able to get hacked drivers put up on the company web site for a day. Anyone with "off-brand" input devices could simply apply for approval before the event.
In the world of online gaming, there are tons of exploits at every level. Even simply tweaking the gamma level of the monitor in the basic Windows control panel can yeld HUGE advantages in tactical games such as Counter-Strike, as it effectively removes all dark hiding places. Monitors would have to have their configs locked down, including the external adjustments.