Designing your application around an RDBMS is great if what you want is a relation-oriented application, but it's terrible if you want an object-oriented application. I've actually done a relational application, and it was just the right thing; when you want to support complex queries spanning your database, there's nothing better than an RDBMS.
On the other hand, there are some cases where you want an object-oriented design, and limiting yourself to what you can fit in an RDBMS schema is a bad idea. There are cases in which you really want a base class extended by multiple subclasses, and now you can't write your foriegn key constraints properly. Alternatively, you could duplicate your common code for each table, but that's even worse.
Using Oracle for storing objects is basically bad; using it to store relations is good. Good design requires you to determine first what sort of data model you have, and then choose your programming paradigm appropriately; deciding to use a relational database just because you need persistence is foolish. You've done something wrong if your queries are mostly "SELECT * FROM tbl WHERE id=?".
I do agree that comp sci doesn't teach enough relational design, because it's often an appropriate design. But sometimes OOP is the right tool for the job, and then you need an appropriate storage system. Relational databases are really their own thing, with a different set of efficient and simple operation, and are not really not that much like objects.
Linux proper (the kernel) should be fine for both; it's designed to be modular and configurable, so you just don't build, install, or load the stuff you don't need for your particular application.
As for the complete system, I couldn't agree more. The first thing that needs to go is passwords on the desktop; nobody without physical access should have any way of getting to a password prompt. Once you've done that, you realize that there's a ton of stuff that gets installed on Linux desktop boxes which is only there because it's available for Linux. Why don't you ever see packages containing only the clients for telnet and ssh? Why don't you ever see MTA packages configured not to accept anything from outside of the machine?
I think the main reason that Linux hasn't taken over the desktop is that there isn't a distribution that actually behaves like a desktop machine, rather than a server or a group workstation.
I'll agree with you if you say "Solaris or Irix's NFS implementations", but mixing them can be very bad. I've personally had a particular combination zero the second half of each kilobyte I wrote.
NFS is poorly designed in ways that make it relatively easy to break. Unfortunately, there's no really trivial replacement.
It's a good idea because relational databases, XML files, and flat files are not really all that similar to objects. It'll be more efficient than using Oracle because Oracle is really designed for an entirely different sort of query; using Oracle for storing objects means that you've already got a badly-designed system. (Note: I think you can have a really good design using Oracle, but only if you're adding Oracle to be able to do SQL queries, not if you just want persistence.)
For cases where you want your objects to persist and don't want any other functionality that isn't done by your objects, a journal is really the right thing. It's interesting and useful to see somebody doing general support for this method. (I personally implemented a particular case of exactly this a few weeks ago, which wasn't too hard, but I haven't heard of a general library before.)
It should write over any memory it's giving you. For your temporary values, you actually don't generally get new memory from the OS, since free will generally not return the memory to the system, but will return it for a future call to malloc; malloc and free are library functions, not system calls (that's why it's (3), not (2, system calls); memory is gotten from the OS with either mmap or sbrk). This is the real reason you have to zero memory from malloc: *you* could have stored something at this address previously, freed it, and gotten it again, in which case the OS hasn't done anything with it and the library doesn't clear it.
Programs can't necessarily tell whether the contents of their memory is sensitive. Is stuff read from a file by a text editor sensitive? Generally not, but you might be editing/etc/passwd, in which case it is. The policy of having the OS clear any memory before giving it to a program actually started when people using ITS found that, by allocating a lot of memory and writing it to disk without initializing it, they could often steal the passwords in the system, which had been left there by other programs. Obviously, you can't depend on a hacker clearing the memory before searching for sensitive contents, and programs generally don't clear memory before freeing it; this leaves the OS as the only place to do it, and the OS is generally responsible for protecting programs from each other.
I can excuse not knowing that it's (3), but thinking it's (1), I'm not so sure about. Surely you encounter newly-written user commands...
We'll see the less affluent citizens searched whenever they travel. Or, more likely, we'll see anyone who doesn't change their habits to look innocent (that is, anyone who isn't a terrorist) searched. There are obviously a lot of false positives; in fact, there's only been one *true* positive, and that was a rather lame and unlucky attempt.
Given that everybody has grown accustomed to being searched when they travel, and security has grown accustomed to the people they search being innocent, I think this is a fine thing. People had previously lost the presumption of innocence; it's good to see an instance in which suspects are nearly certain to be innocent. If it were a one-in-a-million court case in which the defendant had done anything, juries would take a lot moe convincing than they do these days.
Dang, I knew I'd be missing out if I skipped it. But all those non-slashdot VIPs are so terribly boring, and they never say anything at all unexpected. "A huge country with a developing economy does really well." "A country that was just lying about most of its productivity doesn't do well." "Iraq is a good testbed for taking over countries." "People will let us do whatever we want as long as there are Al Quida officials out there." Blah, blah. If I'm going to bother travelling to hear people talk, I'd like them to say something I couldn't figure out by listening to NPR while I drive to the store. Sure, the food's higher quality, but I don't find it sufficiently filling.
The OS is not responsible for giving you zeroed memory; the OS *is* responsible for clearing memory from other programs that it gives to you. It is good practice to clear the memory anyway, so that you don't risk leaking information from freed memory in the same program. Also, the OS could fill the memory with some other value or with random data if it felt like it.
(You mean malloc(3), BTW, not malloc (1), which would be a user command rather than a C function)
People who play sports have a lot of fun, because people who don't have a lot of fun playing sports quit doing so as soon as they possibly can. People who build stage sets have lots of fun, and so do people who play computer games (both of which also require coodination). Getting exercise is also important, and is best when you're enjoying it, but some people find sports boring or unpleasant and are happier walking or going to the gym or doing a martial art.
They're probably glad they didn't get that law passed, because (I've heard) there were sufficiently drastic consequences for hacking someone who you couldn't prove had violated copyrights. That's why the MPAA isn't still pushing it.
Given how easy it is to set caller ID, and the fact that the phone company, as mentioned in the article, will actually set it to what you want them to (but not frequently enough for telemarketters to do anything useful with it), I doubt that predictive dialers can't do it. It's certainly possible that predictive dialers in common use automatically turn it off and can't be configured not to do that, though.
The system reduces the dead air by doing the check for live numbers faster. In the case where not all of the stations are on the line, there's still a pause with conventional systems which the dialer tries to determine whether the other end actually picked up with a real line. After that pause, there may be an additional pause if the dialer doesn't have a live operator (or, more likely, it uses a recording).
People do tend to buy if pestered, but these are people who've refused before, not people who have bought devices to prevent the phone calls, and probably not people who have threatened to sue.
Doesn't have anything to do with the root name server stuff; in fact, if you use your IP address instead of your hostname, you'll entirely skip the DNS part. Also, that site doesn't work very well, because all of the tricks to specify the IP address instead of the name point at the wrong IP address.
The feature of ignoring TeleZapper is probably not useful to telemarketters, because anyone with a TeleZapper who gets a call from a telemarketter is likely to pissed and hang up (or be pissed and yell at the person). People tend to be nice to telemarketters because they don't want to be rude, but will probably feel that the telemarketter is being rude if the call goes through a TeleZapper.
The thing evidentally can reduce the dead air before the caller is connected, which could help them avoid getting hung up on before they start talking.
It also can set the caller ID. People block based on lack of caller ID, but telemarketters could leave caller ID enabled if they really cared; the issue is mainly that they don't want people to call them back at the call center (they want people to call the client's number), but people rarely call telemarketters back anyway. The fact that they don't provide caller ID information suggests that they aren't really trying to reach people who don't want to be reached. They're mainly going after people who can be convinced over the phone to buy stuff, and these people generally answer the phone when it rings.
I'd actually like to see a TCO study done for a particular company that seriously considered Linux and determined that Windows was the better tool for the job. All of the pro-Windows outcomes I've seen have either been purely marketting (bunch of numbers, but no actual case study) or haven't made reasonable estimates for the Linux option. I assume this is because companies that come to such conclusions tend not to publish them. But, when I see all the slashdot posts that say, "TCO studies are useless; you have to consider the situation", I want to see a situation in which the right choice isn't Linux.
It seems to me that most of the studies actually end up saying that it will be cheaper to run Linux in terms of TCO, but you may not be able to do so and still do what you need to do.
A lot of people would go to randomstring.microsoft.com if it became the default search option for IE. I doubt many people would actually pick a Microsoft "googler" because of the name.
If you look at the terms of the license, it becomes clear that they want to limit the spread of broken, unreleased versions; they'd like anything that's going to continue running (and therefore be attackable) to have at least completed testing successfully.
This is an effort to have effective open source QA, not an attempt to limit the eyes on the code; the only source that's restricted is source that, once testing is complete, nobody will be running.
I think it's reasonable to have a middle ground between the totally private contents of my unsaved emacs buffers and the released version of the source in the tarballs in the archive. This includes my mode 755 working directory on a company-wide NFS server and the copies I send to someone who tests on PPC. Open source requires that once I'm providing the code *to a user* *for use*, the user then has the necessary freedoms.
I somewhat doubt that calling your search engine a "googler" would actually enable you to steal Google's business. Who would use a non-Google googler? It's quite a different situation from using a trademark noun as a noun for your product directly; the case where trademarks are important is when the infringing product may seem to be the original product itself, rather than to refer to the product. Why would you buy a product whose name suggests that it does what a Xerox machine does, when you could actually buy a Xerox machine?
Even if there's something seriously wrong with the Office interface, you grow to like it. Or, at least, you get used to it. The mysterious thing is that MicroSoft moves menu options around every few years and people still get used to each interface. Everything on my desktop has been in the same place for almost 7 years now, except when I've decided to move things.
Was there a big hole in the fence, like there was (according to Richard Feynman) while the first nuclear weapons were being developed? Los Alamos security has always been largely based on the difficulty of looking like you're supposed to be at a small military lab when you're actually messing with anything important. The gates and such just slow you down to the point where it's unlikely that you'd be in and out without anybody happening to see you.
Linus says that all those pushes and pops turn out to be a good thing for x86; it means that Intel puts their effort into cache and memory performance, which are good for other things, too, rather than register file interconnects, which is only good for in-processor stuff. With an efficient cache and a small number of registers, you get really good performance on the few most common variables, and pretty good performance on the top thousand. With 32 registers, you get good performance on the 32 most common variables; you don't get as good performance on the top few, nor on the 33rd, nor do you get as good batch performance going through bunches of memory.
The issue here is that it costs some money to develop a drug and it costs much less money to produce the drug. The inventors have to pay the development costs as well as the production costs; generic companies only pay the production costs. In order for it to be better to invent the drug than to wait for somebody else to invent it, you have to make enough money on the initial shipment to pay for the development costs. But nobody is going to buy a lifetime supply of a brand-new drug at novelty-inflated prices; why not wait a little while for the price to come down, since you're probably not that desperate, and you're not going to use that much? That means the price the market will bear falls rapidly to the price of generic drugs, which is based on the production costs, since that's all most producers have to worry about.
In fact, the situation is worse for inventors, because the generic companies that haven't been investing in research have been investing instead in production capabilities, meaning that they can always make things cheaper once they know what to make.
Their solution is that the inventor sells the formulas to the generic companies to make up the research costs; the generic companies all buy the formula because they compete with each other and don't want to be late to market (which they would be if they had to figure out how to make the stuff from looking at a pill) and want to add to their product lines. Everything is more efficient overall, because the pills are always produced in the efficient plants.
It's an interesting question: if I offer to make lemonade for everybody comes by, provided that I get paid $10 up front, will people go for it? It is in everybody else's interests to wait for somebody else to pay me, except that they're thirsty until somebody does. Most likely what will happen is that people will gather until there is a group of people who value the lemonade they'll drink at $10, and then the deal with go through, and everybody else is just lucky; even if you can't speculate in the commodity because its cost will obviously drop, it has some worth to you over the time you'd otherwise not have it. The interesting thing is that this depends on the customers being able to negotiate with each other what they plan to pay; if nobody knows about anyone else, their only option is to pay $10 or wait, and nobody wants to pay $10 for lemonade.
Huge documents almost always have little portions which are the really incriminating bits. Heck, most people who are actually supposed to receive huge documents tend to just skim them for the important bits.
Re:The Romanticizing of "The Linux Uprising"
on
The Linux Uprising
·
· Score: 2, Insightful
People who are trying to always support the underdog will continue to follow Linux, because they go for one out-of-the-way technology and a number of not-overly-restrictive technologies, because it's impractical to try to build a system out of exclusively obscure parts.
Presently, people run the underdog Linux on the reigning champion x86, which uses the US standard 120V power supply using the worldwide standard A/C supply. Once Linux because too mainstream, they'll keep running Linux, but run it on obscure processors, or run obscure programs on it,
No, the emacs macro is a sequence of meaningless words with hyphens. M-x turn-on-the-power... no, wait, M-x turn-power-on... um, M-x power-enable? Oh, right, M-x enable-flow-control. Obviously...
Slashdot Mirror
Designing your application around an RDBMS is great if what you want is a relation-oriented application, but it's terrible if you want an object-oriented application. I've actually done a relational application, and it was just the right thing; when you want to support complex queries spanning your database, there's nothing better than an RDBMS.
On the other hand, there are some cases where you want an object-oriented design, and limiting yourself to what you can fit in an RDBMS schema is a bad idea. There are cases in which you really want a base class extended by multiple subclasses, and now you can't write your foriegn key constraints properly. Alternatively, you could duplicate your common code for each table, but that's even worse.
Using Oracle for storing objects is basically bad; using it to store relations is good. Good design requires you to determine first what sort of data model you have, and then choose your programming paradigm appropriately; deciding to use a relational database just because you need persistence is foolish. You've done something wrong if your queries are mostly "SELECT * FROM tbl WHERE id=?".
I do agree that comp sci doesn't teach enough relational design, because it's often an appropriate design. But sometimes OOP is the right tool for the job, and then you need an appropriate storage system. Relational databases are really their own thing, with a different set of efficient and simple operation, and are not really not that much like objects.
Linux proper (the kernel) should be fine for both; it's designed to be modular and configurable, so you just don't build, install, or load the stuff you don't need for your particular application.
As for the complete system, I couldn't agree more. The first thing that needs to go is passwords on the desktop; nobody without physical access should have any way of getting to a password prompt. Once you've done that, you realize that there's a ton of stuff that gets installed on Linux desktop boxes which is only there because it's available for Linux. Why don't you ever see packages containing only the clients for telnet and ssh? Why don't you ever see MTA packages configured not to accept anything from outside of the machine?
I think the main reason that Linux hasn't taken over the desktop is that there isn't a distribution that actually behaves like a desktop machine, rather than a server or a group workstation.
I'll agree with you if you say "Solaris or Irix's NFS implementations", but mixing them can be very bad. I've personally had a particular combination zero the second half of each kilobyte I wrote.
NFS is poorly designed in ways that make it relatively easy to break. Unfortunately, there's no really trivial replacement.
It's a good idea because relational databases, XML files, and flat files are not really all that similar to objects. It'll be more efficient than using Oracle because Oracle is really designed for an entirely different sort of query; using Oracle for storing objects means that you've already got a badly-designed system. (Note: I think you can have a really good design using Oracle, but only if you're adding Oracle to be able to do SQL queries, not if you just want persistence.)
For cases where you want your objects to persist and don't want any other functionality that isn't done by your objects, a journal is really the right thing. It's interesting and useful to see somebody doing general support for this method. (I personally implemented a particular case of exactly this a few weeks ago, which wasn't too hard, but I haven't heard of a general library before.)
It should write over any memory it's giving you. For your temporary values, you actually don't generally get new memory from the OS, since free will generally not return the memory to the system, but will return it for a future call to malloc; malloc and free are library functions, not system calls (that's why it's (3), not (2, system calls); memory is gotten from the OS with either mmap or sbrk). This is the real reason you have to zero memory from malloc: *you* could have stored something at this address previously, freed it, and gotten it again, in which case the OS hasn't done anything with it and the library doesn't clear it.
/etc/passwd, in which case it is. The policy of having the OS clear any memory before giving it to a program actually started when people using ITS found that, by allocating a lot of memory and writing it to disk without initializing it, they could often steal the passwords in the system, which had been left there by other programs. Obviously, you can't depend on a hacker clearing the memory before searching for sensitive contents, and programs generally don't clear memory before freeing it; this leaves the OS as the only place to do it, and the OS is generally responsible for protecting programs from each other.
Programs can't necessarily tell whether the contents of their memory is sensitive. Is stuff read from a file by a text editor sensitive? Generally not, but you might be editing
I can excuse not knowing that it's (3), but thinking it's (1), I'm not so sure about. Surely you encounter newly-written user commands...
We'll see the less affluent citizens searched whenever they travel. Or, more likely, we'll see anyone who doesn't change their habits to look innocent (that is, anyone who isn't a terrorist) searched. There are obviously a lot of false positives; in fact, there's only been one *true* positive, and that was a rather lame and unlucky attempt.
Given that everybody has grown accustomed to being searched when they travel, and security has grown accustomed to the people they search being innocent, I think this is a fine thing. People had previously lost the presumption of innocence; it's good to see an instance in which suspects are nearly certain to be innocent. If it were a one-in-a-million court case in which the defendant had done anything, juries would take a lot moe convincing than they do these days.
Dang, I knew I'd be missing out if I skipped it. But all those non-slashdot VIPs are so terribly boring, and they never say anything at all unexpected. "A huge country with a developing economy does really well." "A country that was just lying about most of its productivity doesn't do well." "Iraq is a good testbed for taking over countries." "People will let us do whatever we want as long as there are Al Quida officials out there." Blah, blah. If I'm going to bother travelling to hear people talk, I'd like them to say something I couldn't figure out by listening to NPR while I drive to the store. Sure, the food's higher quality, but I don't find it sufficiently filling.
How's Devos in January?
The OS is not responsible for giving you zeroed memory; the OS *is* responsible for clearing memory from other programs that it gives to you. It is good practice to clear the memory anyway, so that you don't risk leaking information from freed memory in the same program. Also, the OS could fill the memory with some other value or with random data if it felt like it.
(You mean malloc(3), BTW, not malloc (1), which would be a user command rather than a C function)
People who play sports have a lot of fun, because people who don't have a lot of fun playing sports quit doing so as soon as they possibly can. People who build stage sets have lots of fun, and so do people who play computer games (both of which also require coodination). Getting exercise is also important, and is best when you're enjoying it, but some people find sports boring or unpleasant and are happier walking or going to the gym or doing a martial art.
Who needs sports? People who enjoy sports.
They're probably glad they didn't get that law passed, because (I've heard) there were sufficiently drastic consequences for hacking someone who you couldn't prove had violated copyrights. That's why the MPAA isn't still pushing it.
Given how easy it is to set caller ID, and the fact that the phone company, as mentioned in the article, will actually set it to what you want them to (but not frequently enough for telemarketters to do anything useful with it), I doubt that predictive dialers can't do it. It's certainly possible that predictive dialers in common use automatically turn it off and can't be configured not to do that, though.
The system reduces the dead air by doing the check for live numbers faster. In the case where not all of the stations are on the line, there's still a pause with conventional systems which the dialer tries to determine whether the other end actually picked up with a real line. After that pause, there may be an additional pause if the dialer doesn't have a live operator (or, more likely, it uses a recording).
People do tend to buy if pestered, but these are people who've refused before, not people who have bought devices to prevent the phone calls, and probably not people who have threatened to sue.
Doesn't have anything to do with the root name server stuff; in fact, if you use your IP address instead of your hostname, you'll entirely skip the DNS part. Also, that site doesn't work very well, because all of the tricks to specify the IP address instead of the name point at the wrong IP address.
The feature of ignoring TeleZapper is probably not useful to telemarketters, because anyone with a TeleZapper who gets a call from a telemarketter is likely to pissed and hang up (or be pissed and yell at the person). People tend to be nice to telemarketters because they don't want to be rude, but will probably feel that the telemarketter is being rude if the call goes through a TeleZapper.
The thing evidentally can reduce the dead air before the caller is connected, which could help them avoid getting hung up on before they start talking.
It also can set the caller ID. People block based on lack of caller ID, but telemarketters could leave caller ID enabled if they really cared; the issue is mainly that they don't want people to call them back at the call center (they want people to call the client's number), but people rarely call telemarketters back anyway. The fact that they don't provide caller ID information suggests that they aren't really trying to reach people who don't want to be reached. They're mainly going after people who can be convinced over the phone to buy stuff, and these people generally answer the phone when it rings.
I'd actually like to see a TCO study done for a particular company that seriously considered Linux and determined that Windows was the better tool for the job. All of the pro-Windows outcomes I've seen have either been purely marketting (bunch of numbers, but no actual case study) or haven't made reasonable estimates for the Linux option. I assume this is because companies that come to such conclusions tend not to publish them. But, when I see all the slashdot posts that say, "TCO studies are useless; you have to consider the situation", I want to see a situation in which the right choice isn't Linux.
It seems to me that most of the studies actually end up saying that it will be cheaper to run Linux in terms of TCO, but you may not be able to do so and still do what you need to do.
A lot of people would go to randomstring.microsoft.com if it became the default search option for IE. I doubt many people would actually pick a Microsoft "googler" because of the name.
If you unplug and replug a phone 1000000 times, the little pin will break off of the plug and the plug won't stay in.
If you look at the terms of the license, it becomes clear that they want to limit the spread of broken, unreleased versions; they'd like anything that's going to continue running (and therefore be attackable) to have at least completed testing successfully.
This is an effort to have effective open source QA, not an attempt to limit the eyes on the code; the only source that's restricted is source that, once testing is complete, nobody will be running.
I think it's reasonable to have a middle ground between the totally private contents of my unsaved emacs buffers and the released version of the source in the tarballs in the archive. This includes my mode 755 working directory on a company-wide NFS server and the copies I send to someone who tests on PPC. Open source requires that once I'm providing the code *to a user* *for use*, the user then has the necessary freedoms.
I somewhat doubt that calling your search engine a "googler" would actually enable you to steal Google's business. Who would use a non-Google googler? It's quite a different situation from using a trademark noun as a noun for your product directly; the case where trademarks are important is when the infringing product may seem to be the original product itself, rather than to refer to the product. Why would you buy a product whose name suggests that it does what a Xerox machine does, when you could actually buy a Xerox machine?
Even if there's something seriously wrong with the Office interface, you grow to like it. Or, at least, you get used to it. The mysterious thing is that MicroSoft moves menu options around every few years and people still get used to each interface. Everything on my desktop has been in the same place for almost 7 years now, except when I've decided to move things.
Was there a big hole in the fence, like there was (according to Richard Feynman) while the first nuclear weapons were being developed? Los Alamos security has always been largely based on the difficulty of looking like you're supposed to be at a small military lab when you're actually messing with anything important. The gates and such just slow you down to the point where it's unlikely that you'd be in and out without anybody happening to see you.
Linus says that all those pushes and pops turn out to be a good thing for x86; it means that Intel puts their effort into cache and memory performance, which are good for other things, too, rather than register file interconnects, which is only good for in-processor stuff. With an efficient cache and a small number of registers, you get really good performance on the few most common variables, and pretty good performance on the top thousand. With 32 registers, you get good performance on the 32 most common variables; you don't get as good performance on the top few, nor on the 33rd, nor do you get as good batch performance going through bunches of memory.
The issue here is that it costs some money to develop a drug and it costs much less money to produce the drug. The inventors have to pay the development costs as well as the production costs; generic companies only pay the production costs. In order for it to be better to invent the drug than to wait for somebody else to invent it, you have to make enough money on the initial shipment to pay for the development costs. But nobody is going to buy a lifetime supply of a brand-new drug at novelty-inflated prices; why not wait a little while for the price to come down, since you're probably not that desperate, and you're not going to use that much? That means the price the market will bear falls rapidly to the price of generic drugs, which is based on the production costs, since that's all most producers have to worry about.
In fact, the situation is worse for inventors, because the generic companies that haven't been investing in research have been investing instead in production capabilities, meaning that they can always make things cheaper once they know what to make.
Their solution is that the inventor sells the formulas to the generic companies to make up the research costs; the generic companies all buy the formula because they compete with each other and don't want to be late to market (which they would be if they had to figure out how to make the stuff from looking at a pill) and want to add to their product lines. Everything is more efficient overall, because the pills are always produced in the efficient plants.
It's an interesting question: if I offer to make lemonade for everybody comes by, provided that I get paid $10 up front, will people go for it? It is in everybody else's interests to wait for somebody else to pay me, except that they're thirsty until somebody does. Most likely what will happen is that people will gather until there is a group of people who value the lemonade they'll drink at $10, and then the deal with go through, and everybody else is just lucky; even if you can't speculate in the commodity because its cost will obviously drop, it has some worth to you over the time you'd otherwise not have it. The interesting thing is that this depends on the customers being able to negotiate with each other what they plan to pay; if nobody knows about anyone else, their only option is to pay $10 or wait, and nobody wants to pay $10 for lemonade.
Huge documents almost always have little portions which are the really incriminating bits. Heck, most people who are actually supposed to receive huge documents tend to just skim them for the important bits.
People who are trying to always support the underdog will continue to follow Linux, because they go for one out-of-the-way technology and a number of not-overly-restrictive technologies, because it's impractical to try to build a system out of exclusively obscure parts.
Presently, people run the underdog Linux on the reigning champion x86, which uses the US standard 120V power supply using the worldwide standard A/C supply. Once Linux because too mainstream, they'll keep running Linux, but run it on obscure processors, or run obscure programs on it,
No, the emacs macro is a sequence of meaningless words with hyphens. M-x turn-on-the-power... no, wait, M-x turn-power-on... um, M-x power-enable? Oh, right, M-x enable-flow-control. Obviously...