While I think that adults won't necessarily *stop* playing games, I think that they types they play will be different.
Unless they're playing for nostalgia (or one of the simple five-minute-killers like Tetris), I would guess the following:
* Patience for reptition is low.
* Demand for plot and writing to be of a higher quality than many games have been (poorly-translated Japanese text, a hallmark of many SNES games, is not acceptable).
* Meaninglessly thrown-in buxom girls will have less appeal (and in some cases will be treated negatively) compared to the traditional male teen audience.
* Cost will be less of an issue.
* There will be a lower tolerance for long learning curves. If you have N hours free on a weekend, you don't want to blow half of it learning the intricacies of some complex control system.
* There will be a lower tolerance for long setup times. If you have N hours free on a weekend, you don't want to blow half of it toggling 3d options to get things running properly on your system.
* The ability to play with a pair may become more highly valued. Traditionally, there have not been many games that allow cooperative play (Halo and FF Crystal Chronicles spring to mind), though there are many with competitive support. Not many teens have someone handy to play games with all the time (and if they do, it's a friend -- with whom human culture tends to dictate that we have a somewhat competitive relationship with). However, I've read about a surprising number of couples that play Everquest or similar games together. It's something fun to do with your spouse. Think of it as the bridge or mahjong of the future...
* Violent games will be less highly-valued (though, of course, there are exceptions
Is it only the linux zealots who support this standard? Is it just another opportunity for the penguin-lovers to thumb their nose at whoever they feel MP3 represents? Or am I just missing some beautiful benefit of ogg...
I finally sat down to determine which worked better, mp3 or ogg, and did some double-blind testing on the computer. This was a while ago, and encoders change a bit. I was using oggenc before the 1.0 release to do vorbis encoding, and lame at the same time. Both were VBR.
It turns out that after carefully listening to the original and encoded copies, my ability to tell the difference between the.ogg and uncompressed audio topped out significantly higher than.mp3, at least on the clip I was listening to.
I am using all.ogg today, however. Why? Because even though I can hear vorbis artifacts more clearly than mp3 artifacts, they don't sound *awful*, as mp3 ones do. I mostly notice vorbis modifying the sound of drum beats. It's hard to describe, and doesn't seem to make them sound worse -- they just sound slightly different, but still like drums. mp3 squashes cymbals and similar-sounding audio into a runny, mushy mess of sound, and makes music generally sound slightly less "atmospheric". The artifacts are unpleasant to hear.
There is also one pragmatic use for ogg if you're a P2P downloader -- all vorbis files that you're going to find on P2P networks are going to be VBR, whereas many MP3s are CBR. VBR is almost always a tremendous win over CBR for non-streaming listening, and should absolutely always be used.
There are a few other issues. MP3 encoding is covered by patents. Ogg encoding is not. (There was some noise at one point about mp3 decoding as well, but I think that blew over.) Fraunhoffer is working to try to add more of their patents into the standard to be able to make money off of it, with stuff like MP3+. Ogg and vorbis are produced by a group that is simply in it to make the best thing they can.
I think few people have any attachment to mp3 other than the fact that it's in wide use and it's effectively DRMless. I haven't seen many people using wma.
Given the opportunity, I'd probably prefer to use FLAC on my computer, and if I had a portable player, ogg vorbis on it.
It's not that I expect you to do so (I don't expect anyone *giving* something away to give beyond the degree they desire).
It's just that a lot of admins view blocking port 25 outbound as a solution to spam. It just isn't, and it's awfully frusterating (because it's become a tool used to force tiered service).
I run a mail server on my machine. I started doing so in university because I moved the thing between home and university, and both my home ISP and the university mail server disallowed relaying, so inevitably I'd forget to change my mail server settings, and my mail would start bouncing (except in the case of my home ISP, which simply silently dropped the mail -- usually it took a week or so for me to realize that none of my mail was going out). It also lets me get "undeliverable" warnings immediately and with the degree of information that I'd like -- one mail server that I used for a while at university was VMS, and was a royal pain in the ass.
So, while this is hardly a common usage, it is awfully frusterating when people simply try to ban servers or block ports with the intent of blocking spam. It hasn't stopped spam for years, and it isn't going to start, and it's a terrible inconvenience.
I just wish that instead of the next antispam hack being some half-assed attempt at pushing things off for another month until spammers modify their tools to deal with it (a la SPF), it would be a real move to a trust network with signatures. But that takes work to do properly, and it's so much easier to do bad hacks.:-(
I really dislike logging of things without my knowledge, but on the other hand, it's hard to do things like this.
If I had the opportunity to do something differently...well...
I think I'd like to see IP logs and connection logs kept for maybe a week at a public access location. I'm a little dubious about the access point person handing out dumps of the guy's connections (even if it was an interesting read) -- I could easily see nasty privacy violations. Suppose some guy was, say, a gay politician IMing partner while doing something unrelated that broke the law. The sysadmin here seemed pretty happy to be dumping out any interesting data onto the mailing lists -- what if he said "oh, and he spends his time sending IMs like the following...". In this case, things seemed to turn out pretty well, but I'd prefer to have a way that allows law enforcement to get data they need without anyone's rights or privacy being abused.
Plus, if this guy gets a decent lawyer and Ireland has laws anything like the US, he's going to have a field day with how all the evidence was obtained.
If you operate a public Internet access point (school, library, cafe, city park, etc.) please block egress port 25 traffic!
Ultimately, this is a dead end for avoiding spam. It relies on securing every potential entry point to the Internet of spam, which just plain won't happen -- despite heroic (and often frusterating in side effects) efforts over the past few years, no luck.
The proper answer is in securing recipient points (with my preferred approach, with a trust network and signing) -- having a recipient only accept mail that he wants to accept.
Out of curiosity, are you folks part of Microsoft Research? I've vaguely got it stuck in my head that that's the big stronghold of OSS-friendly people there...
Actually, on second thought, it might not be a ridiculous licensing idea. I probably wouldn't ever have heard of this game (nor would the game have reached Slashdot) had it not been for the pair of Elena stories, and I suspect that GSC will owe Elena for a fair number of copies sold. I recognize a few of the elements in the screenshots from Elena's photos (like the abandoned Ferris wheel...spooky.)
I have to say that with all the recent emphasis on the exclusion zone, and the possibility of placing games there (and the knowledge that in at least one game, players are going to be running around there), Westerners may know the ground of one part of the USSR -- Chernobyl, one of the most difficult places to actually visit in real life. Bizarre.
I have to admit that having a Ukranian woman screaming by on an overpowered touring motorcycle would be kind of a neat Easter egg, if a bit too in-jokish for many...
I don't know about you but I do not find it very surprising when I hear that Windows or a Windows software suffer from a vunerability
The funny thing is that the bug is in Mikmod code, which was originally written for DOS, has been Open Source (and LGPLed) for years, and is most heavily maintained and used on Linux and other UNIX variants.
Furthermore, xmms is probably vulnerable due to using the same decoder library, as well as the CLI mikmod player (which runs natively on Linux). Other Linux software that uses libmikmod (just from a quick dependency check out of the list of software currently installed on my system) includes gstreamer, alsaplayer, and xscorch.
Don't get me wrong -- I think that there are a lot of bad security practices in *Microsoft* code (different from "all software for Windows"), that some of the Windows architecture is not the greatest from a security standpoint, and that much Windows-based software doesn't have the greatest tradition of care being taken WRT security.
However, there are holes found all the time. I'd be surprised if mplayer and timdity don't have holes (and if mikmod doesn't have more holes) just because it's damned easy to allow a malicious media file to exploit some kind of bug in your code.
How come Winamp doesn't suck, despite all other media players owned by large companies rapidly beginning to suck once they are widely used? Windows Media Player, RealPlayer, Quicktime Player...I thought Winamp was going to do the same thing with v3, but apparently something's different at Nullsoft...
XMMS is commonly distributed (for example, by Red Hat) using mikmod as the default mod playing library, so it is probably vulnerable as well.
It's easy to disable Mikmod support in your Preferences-<Input Plugins list.
I would, in any event, suggest using the xmms Modplug plugin rather than the mikmod plugin to play xm/s3m/it/mod/etc-- it provides more features and (optionally) better audio quality.
This is actually a serious issue, even if you don't run into.XM files.
Viruses and malware have adapted to fit the times. At one point, they spread on disk boot blocks, when floppies moved around, and via executables. Then people started using hard drives and stopped swapping things around as much, but starting tossing.DOC files around. Macro viruses picked up. With the Internet, worms are becoming more of an issue.
Now that people swap files around via P2P and other systems, there must be consideration given to insufficiently robust file I/O code. When I'm writing a network-using application, I'm darn careful to validate that all the data coming in is correct. There's a much stronger temptation to assume that data is valid when reading in a data file, or to not check for every possible type of inconsistent data. As a result, there are probably many, many buffer overflows that can be exploited by opening documents in programs -- a program reading in a document should treat that document as if it is written by a hostile intruder.
Besides, isn't it better to be safe than sorry? I've known some holes that *seemed* obscure, but if people ignored them, they could have become very nasty.
XMMS has two independent xm/mod/s3m/etc player plugins -- mikmod and modplug. Even if one is vulnerable *and* you have set up your web browser to hand off mp3s to xmms (not default on any distro I know of), it should be easy to switch to the other.
FWIW, mikmod has traditionally been used more commonly by xmms users, but I find that modplug has pulled ahead in terms of features (like support for zip-/gz-compressed files).
I've never, ever managed to understand the whole "it doesn't matter if the language we are using is bloated, hungry and generally shit - the hardware can handle it" mentality.
I think it's more a collision between two different types of software developers.
Group (a) is smaller, but their software is used by many more people. They write games, word processors, spreadsheets, P2P clients, web browsers and image editors. This is horizontal market software. A little bit of extra effort on the part of developers translates to massive resource savings for many, many users. For group (a), Java makes very little sense. It is slower. It uses more memory. Sure, maybe it gives slightly faster development time, but that's not a big deal -- knocking sixty days off your development isn't worth a resultant review that your software is "sluggish and RAM-hungry". Java might save these users $60,000 in developer costs, but it's going to cause the users to pay many millions in resultant hardware costs.
Group (b) does custom and vertical market work. There are many, many people working in group (b), but each person's code is only used by a few people. They write in-house front-ends and code to interface to in-house databases, website backends and highly specialized software. In this case, it really does make more sense to blow money on hardware than on developer time. If you can knock sixty days off your project, and save $60,000 in developer costs, what's an extra gig of RAM and an extra CPU or two? $2,000? Java makes a lot of sense for these folks. This is the sort of stuff that would traditionally be implemented in perl or awk or shell on *IX. I have a lot of scripts that I run on my system or one other. It would be a silly waste of time for me to rewrite them in C -- I'd save a couple of CPU cycles, but on only one computer.
An end user at home should pretty much be using software developed by group (a), horizontal market software.
You don't double the storage needed for everything: just for things that are currently a single byte *and* must be individually addressable.
The advantage is that you get to eliminate logic that isn't generally used on your CPU, which lets the designers have space to work on optimizing common cases.
Technically, this does not have to be true, although it is likely that this will remain true on mainstream computers for a long time to come, if not ever, due to installed base.
A bit is defined as a binary digit.
A byte is defined as the smallest addressable chunk of data on the processor. You could have a system with 16 bit bytes, or 1 bit bytes if you wanted. Really, the only reason to make a byte eight bits is for interoperability purposes and because the common set of characters used in the United States fits nicely in one byte.
My guess is that someday, the byte will increase in size (probably to 16 or 32 bits) simply because many of the primary applications of the eight bit byte for a long time no longer apply. The growing importance of internationalization means that UTF-16 or UTF-32 are attractive replacements for eight bit characters. Few people use byte-sized integers any more in software. As pressure to increase color depth in display systems increases (especially in 3d gaming, where image processing exacerbates the limited precision), it is likely that we will commonly use more than eight bits per color channel per pixel in the future.
There's a reasonable argument that, instead of hiring one person that *definitely* cannot handle all the work within normal work hours, you should be hiring two people, each for a smaller amount of money, that can, but are not working at maximum much of the time.
I really wish dag/planetccrma/freshrpms/etc and the other major RPM third party builders would do RPM builds for the latest fc test build. They don't have to all work or even be tested, but it'd make testing out and working on the latest fc test build a lot more feasible.
I'm using 2.6 on Fedora Core 1. There are a number of articles that specifically describe how to do this on the Web.
However, if you're the kind of person that is interested in shaving a month off of the wait time to get to 2.6, you might want to consider just using Fedora Core 2 test 2, and put up with the fact that most of the third-party RPM archives aren't building for FC2 yet.
The big differences include modules.conf becoming modprobe.conf, a couple of/dev and/proc changes, IIRC you'll need a new version of modutils...
Honestly, unless you specifically need a new feature in 2.6, 2.6 is nice but not a "must have" change for a typical workstation user. I lost the ability to use my X10 drivers (only exist for 2.4) and I've noticed that changes to the VM system have improved process start times. Nice levels are more significant. I'm dubious that it's worth a whole lot of effort to save a month. If I were just considering doing the upgrade to 2.6 at this point, I'd probably hold off, as it's not long until you can get a packaged version of the kernel.
Oh, autoloading of modules relating to the input system works differently in 2.6 (I'd consider it "broken", but I'm not entirely up on whether there might be a good approach) so I've stopped building the input subsystem and USB and HID modules as modules, and started building them into the kernel.
Seriously, the reason most of these issues haven't been ironed out is because they aren't severe, or they're extremely difficult to hit, or else someone would have run into it before.
VM is an extremely complex beast that's not going to handle all situations ideally. You're always going to have something that only roughly approximates doing the right thing. If *any* vendor (Apple, Sun, you name it) isn't putting in VM patches, they either (a) just plain aren't trying to improve VM or (b) wrongly think that everything is perfect. Microsoft, for example, just made a major change to the way page permissions operate in XP in SP2, which is a rather serious change -- they keep moving. Of course, you won't hear the word "bug" associated with anything, or the word "security hole" -- but the Linux kernel changelog is a pretty honest look into what's going on.
Slashdot Mirror
While I think that adults won't necessarily *stop* playing games, I think that they types they play will be different.
Unless they're playing for nostalgia (or one of the simple five-minute-killers like Tetris), I would guess the following:
* Patience for reptition is low.
* Demand for plot and writing to be of a higher quality than many games have been (poorly-translated Japanese text, a hallmark of many SNES games, is not acceptable).
* Meaninglessly thrown-in buxom girls will have less appeal (and in some cases will be treated negatively) compared to the traditional male teen audience.
* Cost will be less of an issue.
* There will be a lower tolerance for long learning curves. If you have N hours free on a weekend, you don't want to blow half of it learning the intricacies of some complex control system.
* There will be a lower tolerance for long setup times. If you have N hours free on a weekend, you don't want to blow half of it toggling 3d options to get things running properly on your system.
* The ability to play with a pair may become more highly valued. Traditionally, there have not been many games that allow cooperative play (Halo and FF Crystal Chronicles spring to mind), though there are many with competitive support. Not many teens have someone handy to play games with all the time (and if they do, it's a friend -- with whom human culture tends to dictate that we have a somewhat competitive relationship with). However, I've read about a surprising number of couples that play Everquest or similar games together. It's something fun to do with your spouse. Think of it as the bridge or mahjong of the future...
* Violent games will be less highly-valued (though, of course, there are exceptions
Is it only the linux zealots who support this standard? Is it just another opportunity for the penguin-lovers to thumb their nose at whoever they feel MP3 represents? Or am I just missing some beautiful benefit of ogg...
.ogg and uncompressed audio topped out significantly higher than .mp3, at least on the clip I was listening to.
.ogg today, however. Why? Because even though I can hear vorbis artifacts more clearly than mp3 artifacts, they don't sound *awful*, as mp3 ones do. I mostly notice vorbis modifying the sound of drum beats. It's hard to describe, and doesn't seem to make them sound worse -- they just sound slightly different, but still like drums. mp3 squashes cymbals and similar-sounding audio into a runny, mushy mess of sound, and makes music generally sound slightly less "atmospheric". The artifacts are unpleasant to hear.
I finally sat down to determine which worked better, mp3 or ogg, and did some double-blind testing on the computer. This was a while ago, and encoders change a bit. I was using oggenc before the 1.0 release to do vorbis encoding, and lame at the same time. Both were VBR.
It turns out that after carefully listening to the original and encoded copies, my ability to tell the difference between the
I am using all
There is also one pragmatic use for ogg if you're a P2P downloader -- all vorbis files that you're going to find on P2P networks are going to be VBR, whereas many MP3s are CBR. VBR is almost always a tremendous win over CBR for non-streaming listening, and should absolutely always be used.
There are a few other issues. MP3 encoding is covered by patents. Ogg encoding is not. (There was some noise at one point about mp3 decoding as well, but I think that blew over.) Fraunhoffer is working to try to add more of their patents into the standard to be able to make money off of it, with stuff like MP3+. Ogg and vorbis are produced by a group that is simply in it to make the best thing they can.
I think few people have any attachment to mp3 other than the fact that it's in wide use and it's effectively DRMless. I haven't seen many people using wma.
Given the opportunity, I'd probably prefer to use FLAC on my computer, and if I had a portable player, ogg vorbis on it.
It's not that I expect you to do so (I don't expect anyone *giving* something away to give beyond the degree they desire).
:-(
It's just that a lot of admins view blocking port 25 outbound as a solution to spam. It just isn't, and it's awfully frusterating (because it's become a tool used to force tiered service).
I run a mail server on my machine. I started doing so in university because I moved the thing between home and university, and both my home ISP and the university mail server disallowed relaying, so inevitably I'd forget to change my mail server settings, and my mail would start bouncing (except in the case of my home ISP, which simply silently dropped the mail -- usually it took a week or so for me to realize that none of my mail was going out). It also lets me get "undeliverable" warnings immediately and with the degree of information that I'd like -- one mail server that I used for a while at university was VMS, and was a royal pain in the ass.
So, while this is hardly a common usage, it is awfully frusterating when people simply try to ban servers or block ports with the intent of blocking spam. It hasn't stopped spam for years, and it isn't going to start, and it's a terrible inconvenience.
I just wish that instead of the next antispam hack being some half-assed attempt at pushing things off for another month until spammers modify their tools to deal with it (a la SPF), it would be a real move to a trust network with signatures. But that takes work to do properly, and it's so much easier to do bad hacks.
I dunno.
I really dislike logging of things without my knowledge, but on the other hand, it's hard to do things like this.
If I had the opportunity to do something differently...well...
I think I'd like to see IP logs and connection logs kept for maybe a week at a public access location. I'm a little dubious about the access point person handing out dumps of the guy's connections (even if it was an interesting read) -- I could easily see nasty privacy violations. Suppose some guy was, say, a gay politician IMing partner while doing something unrelated that broke the law. The sysadmin here seemed pretty happy to be dumping out any interesting data onto the mailing lists -- what if he said "oh, and he spends his time sending IMs like the following...". In this case, things seemed to turn out pretty well, but I'd prefer to have a way that allows law enforcement to get data they need without anyone's rights or privacy being abused.
Plus, if this guy gets a decent lawyer and Ireland has laws anything like the US, he's going to have a field day with how all the evidence was obtained.
If you operate a public Internet access point (school, library, cafe, city park, etc.) please block egress port 25 traffic!
Ultimately, this is a dead end for avoiding spam. It relies on securing every potential entry point to the Internet of spam, which just plain won't happen -- despite heroic (and often frusterating in side effects) efforts over the past few years, no luck.
The proper answer is in securing recipient points (with my preferred approach, with a trust network and signing) -- having a recipient only accept mail that he wants to accept.
You're part of the team that built wix?
Out of curiosity, are you folks part of Microsoft Research? I've vaguely got it stuck in my head that that's the big stronghold of OSS-friendly people there...
Actually, on second thought, it might not be a ridiculous licensing idea. I probably wouldn't ever have heard of this game (nor would the game have reached Slashdot) had it not been for the pair of Elena stories, and I suspect that GSC will owe Elena for a fair number of copies sold. I recognize a few of the elements in the screenshots from Elena's photos (like the abandoned Ferris wheel...spooky.)
I have to say that with all the recent emphasis on the exclusion zone, and the possibility of placing games there (and the knowledge that in at least one game, players are going to be running around there), Westerners may know the ground of one part of the USSR -- Chernobyl, one of the most difficult places to actually visit in real life. Bizarre.
I have to admit that having a Ukranian woman screaming by on an overpowered touring motorcycle would be kind of a neat Easter egg, if a bit too in-jokish for many...
I don't know about you but I do not find it very surprising when I hear that Windows or a Windows software suffer from a vunerability
The funny thing is that the bug is in Mikmod code, which was originally written for DOS, has been Open Source (and LGPLed) for years, and is most heavily maintained and used on Linux and other UNIX variants.
Furthermore, xmms is probably vulnerable due to using the same decoder library, as well as the CLI mikmod player (which runs natively on Linux). Other Linux software that uses libmikmod (just from a quick dependency check out of the list of software currently installed on my system) includes gstreamer, alsaplayer, and xscorch.
Don't get me wrong -- I think that there are a lot of bad security practices in *Microsoft* code (different from "all software for Windows"), that some of the Windows architecture is not the greatest from a security standpoint, and that much Windows-based software doesn't have the greatest tradition of care being taken WRT security.
However, there are holes found all the time. I'd be surprised if mplayer and timdity don't have holes (and if mikmod doesn't have more holes) just because it's damned easy to allow a malicious media file to exploit some kind of bug in your code.
How come Winamp doesn't suck, despite all other media players owned by large companies rapidly beginning to suck once they are widely used? Windows Media Player, RealPlayer, Quicktime Player...I thought Winamp was going to do the same thing with v3, but apparently something's different at Nullsoft...
XMMS is commonly distributed (for example, by Red Hat) using mikmod as the default mod playing library, so it is probably vulnerable as well.
It's easy to disable Mikmod support in your Preferences-<Input Plugins list.
I would, in any event, suggest using the xmms Modplug plugin rather than the mikmod plugin to play xm/s3m/it/mod/etc-- it provides more features and (optionally) better audio quality.
I like to play with SoundTracker, mostly just because it works nicely with Linux.
This is actually a serious issue, even if you don't run into .XM files.
.DOC files around. Macro viruses picked up. With the Internet, worms are becoming more of an issue.
Viruses and malware have adapted to fit the times. At one point, they spread on disk boot blocks, when floppies moved around, and via executables. Then people started using hard drives and stopped swapping things around as much, but starting tossing
Now that people swap files around via P2P and other systems, there must be consideration given to insufficiently robust file I/O code. When I'm writing a network-using application, I'm darn careful to validate that all the data coming in is correct. There's a much stronger temptation to assume that data is valid when reading in a data file, or to not check for every possible type of inconsistent data. As a result, there are probably many, many buffer overflows that can be exploited by opening documents in programs -- a program reading in a document should treat that document as if it is written by a hostile intruder.
Besides, isn't it better to be safe than sorry? I've known some holes that *seemed* obscure, but if people ignored them, they could have become very nasty.
XMMS has two independent xm/mod/s3m/etc player plugins -- mikmod and modplug. Even if one is vulnerable *and* you have set up your web browser to hand off mp3s to xmms (not default on any distro I know of), it should be easy to switch to the other.
FWIW, mikmod has traditionally been used more commonly by xmms users, but I find that modplug has pulled ahead in terms of features (like support for zip-/gz-compressed files).
I've never, ever managed to understand the whole "it doesn't matter if the language we are using is bloated, hungry and generally shit - the hardware can handle it" mentality.
I think it's more a collision between two different types of software developers.
Group (a) is smaller, but their software is used by many more people. They write games, word processors, spreadsheets, P2P clients, web browsers and image editors. This is horizontal market software. A little bit of extra effort on the part of developers translates to massive resource savings for many, many users. For group (a), Java makes very little sense. It is slower. It uses more memory. Sure, maybe it gives slightly faster development time, but that's not a big deal -- knocking sixty days off your development isn't worth a resultant review that your software is "sluggish and RAM-hungry". Java might save these users $60,000 in developer costs, but it's going to cause the users to pay many millions in resultant hardware costs.
Group (b) does custom and vertical market work. There are many, many people working in group (b), but each person's code is only used by a few people. They write in-house front-ends and code to interface to in-house databases, website backends and highly specialized software. In this case, it really does make more sense to blow money on hardware than on developer time. If you can knock sixty days off your project, and save $60,000 in developer costs, what's an extra gig of RAM and an extra CPU or two? $2,000? Java makes a lot of sense for these folks. This is the sort of stuff that would traditionally be implemented in perl or awk or shell on *IX. I have a lot of scripts that I run on my system or one other. It would be a silly waste of time for me to rewrite them in C -- I'd save a couple of CPU cycles, but on only one computer.
An end user at home should pretty much be using software developed by group (a), horizontal market software.
You don't double the storage needed for everything: just for things that are currently a single byte *and* must be individually addressable.
The advantage is that you get to eliminate logic that isn't generally used on your CPU, which lets the designers have space to work on optimizing common cases.
1000 Bits= 1 byte
Technically, this does not have to be true, although it is likely that this will remain true on mainstream computers for a long time to come, if not ever, due to installed base.
A bit is defined as a binary digit.
A byte is defined as the smallest addressable chunk of data on the processor. You could have a system with 16 bit bytes, or 1 bit bytes if you wanted. Really, the only reason to make a byte eight bits is for interoperability purposes and because the common set of characters used in the United States fits nicely in one byte.
My guess is that someday, the byte will increase in size (probably to 16 or 32 bits) simply because many of the primary applications of the eight bit byte for a long time no longer apply. The growing importance of internationalization means that UTF-16 or UTF-32 are attractive replacements for eight bit characters. Few people use byte-sized integers any more in software. As pressure to increase color depth in display systems increases (especially in 3d gaming, where image processing exacerbates the limited precision), it is likely that we will commonly use more than eight bits per color channel per pixel in the future.
Japan has an uncomfortably dense population, too. It's not feasible to maintain the kind of services Japan has in the US at the same price point.
Certainly. See Columbia World of Quotations.
I dunno.
There's a reasonable argument that, instead of hiring one person that *definitely* cannot handle all the work within normal work hours, you should be hiring two people, each for a smaller amount of money, that can, but are not working at maximum much of the time.
Even without doing the math, I can pretty easily call you on that number. The cumulative number of gold pieces should always be odd.
Actually, with three call centers as data points, you can almost certainly isolate the guy's name. He did the right thing.
I really wish dag/planetccrma/freshrpms/etc and the other major RPM third party builders would do RPM builds for the latest fc test build. They don't have to all work or even be tested, but it'd make testing out and working on the latest fc test build a lot more feasible.
I'm using 2.6 on Fedora Core 1. There are a number of articles that specifically describe how to do this on the Web.
/dev and /proc changes, IIRC you'll need a new version of modutils...
However, if you're the kind of person that is interested in shaving a month off of the wait time to get to 2.6, you might want to consider just using Fedora Core 2 test 2, and put up with the fact that most of the third-party RPM archives aren't building for FC2 yet.
The big differences include modules.conf becoming modprobe.conf, a couple of
Honestly, unless you specifically need a new feature in 2.6, 2.6 is nice but not a "must have" change for a typical workstation user. I lost the ability to use my X10 drivers (only exist for 2.4) and I've noticed that changes to the VM system have improved process start times. Nice levels are more significant. I'm dubious that it's worth a whole lot of effort to save a month. If I were just considering doing the upgrade to 2.6 at this point, I'd probably hold off, as it's not long until you can get a packaged version of the kernel.
Oh, autoloading of modules relating to the input system works differently in 2.6 (I'd consider it "broken", but I'm not entirely up on whether there might be a good approach) so I've stopped building the input subsystem and USB and HID modules as modules, and started building them into the kernel.
Seriously, the reason most of these issues haven't been ironed out is because they aren't severe, or they're extremely difficult to hit, or else someone would have run into it before.
VM is an extremely complex beast that's not going to handle all situations ideally. You're always going to have something that only roughly approximates doing the right thing. If *any* vendor (Apple, Sun, you name it) isn't putting in VM patches, they either (a) just plain aren't trying to improve VM or (b) wrongly think that everything is perfect. Microsoft, for example, just made a major change to the way page permissions operate in XP in SP2, which is a rather serious change -- they keep moving. Of course, you won't hear the word "bug" associated with anything, or the word "security hole" -- but the Linux kernel changelog is a pretty honest look into what's going on.
What are your VM problems, anyway?