True, XML is overkill for many many uses, but the matter of fact upside is ubiquity. I disagree in that a DTD gives you anything other than validation. Even if you have a DTD you can only validate the STRUCTURE of the XML...you still can't glean any MEANING from it. Which is why a lot of platforms simply choose to parse XML loosely with regular expressions and just treat it as a simple hierarchical format.
There are certain discrepencies between XML and S-expressions. It is true that any of these other formats "would do", and believe me, I am by no means an advocate of inappropriate, and over- use of XML, but the reality is that the proposed format is so tiny to begin with, and XML is so universally accepted, that it is practically moot whether this or that format would be "better". There are already a wealth of tools to index, mine, translate, etc. etc. XML.
So don't comply and risk getting your mail dropped. You can have your privacy, but you can't FORCE others to read mail from suspicious and unknown sources. Your call. There are plenty of non-email alternatives to be anonymous. Post in a random newsgroup from a web cafe. Or use a secure IM protocol, or secure IRC.
Sort of. You don't REALLY need a DTD - you only need one if you are validating the XML. XML can still be used as a generic ad-hoc hierarchical data format... of course you'd only want to do so because by now XML parsers are pretty ubiquitous and it makes it as good a choice as P-lists, or any other ad-hoc format.
My guess is Routing and Remote Access, which along with the alarming Remote Registry Service, should be one of the things you turn off by default on a new install. No different from turning off all the crap that is installed on a typical default Linux installation.
I think you mean "totally in favour of PERMITTING abortion". I don't think anybody on any side is thinking "Hey, these abortions are great, everybody should get them!". The issue is whether you have the right to have one or not and presumably libertarians would side on individual rights.
The flip side of that coin is the realization that, in absence of any sort of permanent worthwhile activity, any ACTION undertaken with passion is better ("more meaningful") than no action. Witness the South in the Civil War or any number of "futile" revolutions around the world. The conclusion is that: 1) all movements and revolutions will be destroyed independent of their moral value 2) so hurry up and find one so you can distract yourself from that fact.
For me, it is only small arbitrary sparks of joy like Bokononism or Lala (art movement) that punctuate that miserable reality.
Given the option of living in the detached Taoist "creation-destruction" cycle, or living 180 degrees in resentful strife...I pick strife, if only because I'm stubborn. However I have not found the opposite of the phrase "Wu Wei" ("action through inaction", i'm looking for "inaction through struggle";). Any Chinese people around here?
As an aside, I find it confusing that having deconstructed my worldview into nihilism, that I in fact can say that I am an objectively "good" person. I'm not yet sure whether this is because people are inherently "good" by nature or for some other reason... ("brought up right")
True, 'Library' doesn't necessarily have much meaning. But if you look at some of the other things Mac OS X has done, they are, dare I say, "ergonomic". For instance, Mac OS X has a real dependency checking System init mechanism that enumerates configuration files to determine subsystems to bring up. These are simple configuration files that integrate with the startup to do novel things such as, oh, display a message in the graphical UI as to what is actually starting up. I'll note that Seth Nickel is investigating a similar "real" startup system called System Services, for Linux, which is integrated into d-Bus and desktop environments.
Mac OS X is partly a bad example because they have "solved" the problem by putting a vast layer on top of it. If the user never even sees the underlying layer, what value is there in it being there in the first place? The answer for Mac OS X is traditional unix compatibility, and while this plays well in server environments, I think we can start to demand more of desktop systems.
You'll notice that the file system drives many things - for instance, one of the solutions to obscenely long file paths, was not to actually solve the problem, but to add automatic file path completion to the shell, how nifty!
As far as layout, my preference would be uniform app/ directories with conventional subdirectory contents (bin/, doc/, conf/, etc.), which are then index into by other apps (like 'man'). This also vastly simplifies package management, as "uninstalling" becomes a matter of simply removing a single directory instead of crawling the file system for every file associated with the program that got stuck anywhere.
I know how bundles are implemented. I sort of implied that by mentioning that Stow does essentially the same thing under Linux (just hide the hierarchy under a top-level BlahApp/ directory). If you want to get even more technical, it was my understanding that/bin and/sbin were furthermore distinguished by being *statically linked* binaries which could be used during boot in case the/usr volume fails, and hence dynamic libraries are not available. The same goes for/boot, as you should still be able to boot off/boot if the other volumes are trashed. My point is: exactly what value does this provide the user? None. I don't give a damn about statically linked this or boot volume that. Those are the details the OS should handle - those distinctions should not pollute a user-facing namespace/interface. I understand the technical and historical reasons why those directories exist, I'm just saying it does not necessarily have to be so, and that in any case it should not have any bearing on user experience. Example: FreeBSD has now started doing away with the whole statically linked binary concept (http://kerneltrap.org/node/view/1628) and is moving to a dynamically linked root. Also, the distinction between "system app" and "non-system app" is academic to me as a user. They are both apps. Same goes for "distro's files" and "locally-installed software". It's ALL locally installed software unless you are mounting a common network share, in which case, why can't that just be a peer structure instead of nesting under/usr/? (I believe Mac OS X mounts shares at a peer level instead of nested, correct me if I'm wrong). And last I check OS X IS symlink hell at the root level...all the top level "unixish" directories are links into another nested level.
As for the technical question of how to "abstract" a dirty filesytem to begin with - filesystems like ReiserFS already have implicit support for metadata and attributes, and I believe there are 'ls' and other binaries that know how to do the right thing. This is all besides the point because I'm not advocating hiding the ugliness but instead refactoring the damn namespace so it makes sense in the first place and we don't have to put layer upon layer of abstraction to make it look "nice". One straightforward suggestion, make *everything* an app/ directory with conventional layout, and then rely on *indexing* (or symlinking to) the documentation, binaries, configuration, etc., instead of doing the inverse, which is breaking down each app into constituent pieces littered over the files system. One example is 'man' - which can *easily* be set up to index into all installed apps, instead of all apps installing docs into/usr/share/man. Another is libraries, where search paths can be explicitly enumerated for desired libraries, instead of putting ALL libraries (even irrelevant ones) into a top level lib/ dir.
I could make more suggestions as to what I think a better layout would look like, but that is besides the point - the issue is not necessarily about any given proposal, but that the issue be heard at all. The "unix community" if there ever was such a thing, is very conservative and resistent to changing things like that, mostly because it is proven, and works today, and therefore it shouldn't be messed with.
However, I do believe more work on the desktop will drive this refactoring. We have already seen several concessions from "unixisms" to the desktop, so hopefully this will be true (actually I think a refactoring would help BOTH the server and desktop, but the server people judge satisfaction by how LITTLE they have to use the system (how stable and consistent it is), while desktop users judge it by how MUCH they have to use the system (how user friendly/productive/efficient it is to use).
Whatchoo talkin' 'bout Willis!? There are two fundamental approaches to high load: threaded blocking IO, or non-threaded async IO. Both are different abstractions for the same fundamental goal of adding concurrance to a system. In reality most sites will do just FINE by modelling concurrency with a threadpool and blocking IO. Sure you CAN use non-threaded (or "less-threaded") async IO, but you incur a complexity overhead (this is the "overhead" hidden by the simplicity of threads). Unless you are writing an eBay or Amazon.com or Yahoo.com, a threaded/blocking-IO approach will work fine. Since it IS such a popular model, I think it is definately legitimate to compare kernel performance on those grounds. Note that I keep saying "abstraction" and "model". In reality there is nothing mandating that the thing I call a "thread" must really be implemented by a 1:1 mapping to a kernel lieghtweight process. Many systems use "green" threads or some other sort of user-space threading, so the implementation distinction is not as important.
To be completely optimal you wouldn't want a pure implementation of EITHER model, but some sort of hybrid in which you have a some number of threads, which each do some async IO. It all depends on the CPU/IO ratio for your app.
Maintainability is consistently underrated. You should shoot for a performance goal, and then create the SIMPLEST POSSIBLE SOLUTION to meet that goal...not spend days, weeks, months in coding kung foo zen. By the time you get out of your optimization stupor, hardware and network advances will probably have rendered your solution unnecessary.
Exactly my point. What Apple has done with Mac OS X is smear a layer on top of the unix internals since they are so useless. Under the covers it symlink hell. They have also done a lot to replace some unixish things (e.g. NetInfo). Also, look at how they treat applications. They are self-contained directory "bundles" which are represented by a single icon, but contain binaries and all other data needed. Something like this is what I was proposing.
Because you can hide the ugliness is not itself a justification for it being there in the first place.
Because any time anybody (like me) points out that the tradional "unix" file system with/usr and.../bin/... and.../sbin/... and../local/.., etc. etc. etc., is vestigial and retarded, everybody flames back: U R n0t a rEEL hax0r d00d, with a thousand apologies about why that has to be to compensate for some stupid clustering strategy cooked up in the early eighties (don't know about you, but it seems obvious to me that all configurations for all my applications go in/etc/, while the cryptic/usr/local/sbin is translated into "user-level administrative applications deployed for the local network of this machine". Boy that taxonomy is USEFUL!).
The nearest thing I can find to a decent package manager is 'stow' which essentially does *nothing* but hide all that hierarchical complexity behind top-level directories. A new package *format* is not the problem, it's layout and management that is the problem. Everything else is a new wrapper on the same old problem.
Wtf is that rant about? As far as I can tell, the.NET has support for versioning far above any current platform, as it was designed in from the beginning. No, I do not know from practice, but I HAVE read the whitepapers, reviews and interviews. It specifically has provisions for concurrent versions of libraries (even in the same program), and has various compilation and runtime options. This directly obviates the need for static linking in the first place. Java doesn't have a linker either, and has about a 9 MB download last time I checked. I don't know what the hell he is talking about having to download so much stuff. I somehow got.NET automatically and didn't even NOTICE I got it until I opened Add/Remove Programs app, for some unrelated reason. (that is an entirely seperate issue).
News flash - new technology requires new, usually larger, downloads. BFD.
OMG I DIDN'T REALIZE I HAD TO PUT GAS IN MY CAR WHAT A RIP OFF!! I'M SO RESENTFUL NOW!!!
Doesn't thermodynamics imply that expending energy to remove the impurities can never result in more net energy? Sure your fuel might be cleaner and pack more punch...but presumably some energy somewhere was expended to "clean" the fuel.
Are you talking about a preprocessing, or dynamic processing of the fuel in the car?
This is just biased rant against particularly awful implementations of sniper rifles. Plenty of games feature real reloading, instability, losing focus after shooting, whatever. It may well be that sniper rifles are bad in general in computer games for specific reasons but the author fails woefully to prove the case.
One of the things I think make it special is that it is written by an ex-BeOS developer. At least I *think* that is true, but now that the site is slashdotted I can't verify that.
What the hell? This is just a product training course.. not an IT curriculum.
An IT curriculum would look like
* introduction to programming (some intro language) * statistics or some numerical mathematics course * data structures * concurrency * operating system design * database design * artificial intelligence * network topology and routing theory
Yeah! The game I've been waiting for! I've always wondered: "Me, is there a game that fulfills my need to break things, and then keep the broken pieces of that thing?" and I've always had to answer "No, Me, there isn't, you will just have to continue buying and breaking plastic silverware."
I hope this spawns a whole new genre of pointless games:
__Breakey: Crowbar Vs. Car__ __Breakey: Baseball Bat Vs. Seedy Convenience Store Window__ __Breakey: Install New Drivers Vs. Stable System___ __Breakey: Ethnic Slur Vs. Your Nose__
and finally:
__Breakey: Slashdot Reader Vs. Serious Human Relationship__
I noticed over the last decade or so that Lego changed from concentrating on abstract bricks that you could use to make anything you imagined, to these dumbass licensing schemes with special useless pieces and characters and funky objects and stupid spring-loaded action-oriented gimmicks. What utter crap. I also noticed that at some point there was a distinct CHANGE in the formula for their bricks. I can tell because they seem a bit more "slick" and "smooth" than I remember them being and when they connect they leave a more rough seem, and more easily fall apart. Can anybody verify this? I know I am not going insane, I just don't know if it is limited to region or series or what.
Thank god they are going back to what they used to do.
Isn't the design of DNS especially relevant to host names because hosts, and hence host names are dynamically distributed?
Why would it necessarily follow that we would want to use DNS to store other arbitrary types of data (that do not necessarily have a decentralized nature) instead of a central database?
Because ideological zealots will resent you for selectively believing (or disbelieving) their particular ideological abstraction, and because of this other independents (like you) will probably be jaded and cynical to the point that they do not bother caring what you think in the first place. Accept that you will probably never have any political weight (is this the "silent majority") because of this, and because it is hard to get independent-minded people to stick together. The requirement that you are constantly skeptical of your own ideas will alienate you from your very self. Finally, you will have to face the possibility that either there is no truth, or that there is truth but that the fundamental nature of human societies is architected in such a manner as to preclude any hope that it will ever comprise the majority of commonly held belief.
Do you want to replace your warm pillow of ideology with the cold hard brick of reason? Do you want the red pill, or do you want another thick chunk of prime steak with fine aged wine?
Slashdot Mirror
True, XML is overkill for many many uses, but the matter of fact upside is ubiquity. I disagree in that a DTD gives you anything other than validation. Even if you have a DTD you can only validate the STRUCTURE of the XML...you still can't glean any MEANING from it. Which is why a lot of platforms simply choose to parse XML loosely with regular expressions and just treat it as a simple hierarchical format.
There are certain discrepencies between XML and S-expressions. It is true that any of these other formats "would do", and believe me, I am by no means an advocate of inappropriate, and over- use of XML, but the reality is that the proposed format is so tiny to begin with, and XML is so universally accepted, that it is practically moot whether this or that format would be "better". There are already a wealth of tools to index, mine, translate, etc. etc. XML.
So don't comply and risk getting your mail dropped. You can have your privacy, but you can't FORCE others to read mail from suspicious and unknown sources. Your call. There are plenty of non-email alternatives to be anonymous. Post in a random newsgroup from a web cafe. Or use a secure IM protocol, or secure IRC.
Not only would it be difficult, it would be POINTLESS because spam prevention only works if EVERYBODY DOES IT.
Sort of. You don't REALLY need a DTD - you only need one if you are validating the XML. XML can still be used as a generic ad-hoc hierarchical data format... of course you'd only want to do so because by now XML parsers are pretty ubiquitous and it makes it as good a choice as P-lists, or any other ad-hoc format.
windows services
My guess is Routing and Remote Access, which along with the alarming Remote Registry Service, should be one of the things you turn off by default on a new install. No different from turning off all the crap that is installed on a typical default Linux installation.
To nitpick: "totally in favour of abortion"
I think you mean "totally in favour of PERMITTING abortion". I don't think anybody on any side is thinking "Hey, these abortions are great, everybody should get them!". The issue is whether you have the right to have one or not and presumably libertarians would side on individual rights.
The flip side of that coin is the realization that, in absence of any sort of permanent worthwhile activity, any ACTION undertaken with passion is better ("more meaningful") than no action. Witness the South in the Civil War or any number of "futile" revolutions around the world. The conclusion is that: 1) all movements and revolutions will be destroyed independent of their moral value 2) so hurry up and find one so you can distract yourself from that fact.
;). Any Chinese people around here?
For me, it is only small arbitrary sparks of joy like Bokononism or Lala (art movement) that punctuate that miserable reality.
Given the option of living in the detached Taoist "creation-destruction" cycle, or living 180 degrees in resentful strife...I pick strife, if only because I'm stubborn. However I have not found the opposite of the phrase "Wu Wei" ("action through inaction", i'm looking for "inaction through struggle"
As an aside, I find it confusing that having deconstructed my worldview into nihilism, that I in fact can say that I am an objectively "good" person. I'm not yet sure whether this is because people are inherently "good" by nature or for some other reason... ("brought up right")
True, 'Library' doesn't necessarily have much meaning. But if you look at some of the other things Mac OS X has done, they are, dare I say, "ergonomic". For instance, Mac OS X has a real dependency checking System init mechanism that enumerates configuration files to determine subsystems to bring up. These are simple configuration files that integrate with the startup to do novel things such as, oh, display a message in the graphical UI as to what is actually starting up. I'll note that Seth Nickel is investigating a similar "real" startup system called System Services, for Linux, which is integrated into d-Bus and desktop environments.
Mac OS X is partly a bad example because they have "solved" the problem by putting a vast layer on top of it. If the user never even sees the underlying layer, what value is there in it being there in the first place? The answer for Mac OS X is traditional unix compatibility, and while this plays well in server environments, I think we can start to demand more of desktop systems.
You'll notice that the file system drives many things - for instance, one of the solutions to obscenely long file paths, was not to actually solve the problem, but to add automatic file path completion to the shell, how nifty!
As far as layout, my preference would be uniform app/ directories with conventional subdirectory contents (bin/, doc/, conf/, etc.), which are then index into by other apps (like 'man'). This also vastly simplifies package management, as "uninstalling" becomes a matter of simply removing a single directory instead of crawling the file system for every file associated with the program that got stuck anywhere.
I know how bundles are implemented. I sort of implied that by mentioning that Stow does essentially the same thing under Linux (just hide the hierarchy under a top-level BlahApp/ directory). If you want to get even more technical, it was my understanding that /bin and /sbin were furthermore distinguished by being *statically linked* binaries which could be used during boot in case the /usr volume fails, and hence dynamic libraries are not available. The same goes for /boot, as you should still be able to boot off /boot if the other volumes are trashed. My point is: exactly what value does this provide the user? None. I don't give a damn about statically linked this or boot volume that. Those are the details the OS should handle - those distinctions should not pollute a user-facing namespace/interface. I understand the technical and historical reasons why those directories exist, I'm just saying it does not necessarily have to be so, and that in any case it should not have any bearing on user experience. Example: FreeBSD has now started doing away with the whole statically linked binary concept (http://kerneltrap.org/node/view/1628) and is moving to a dynamically linked root. Also, the distinction between "system app" and "non-system app" is academic to me as a user. They are both apps. Same goes for "distro's files" and "locally-installed software". It's ALL locally installed software unless you are mounting a common network share, in which case, why can't that just be a peer structure instead of nesting under /usr/? (I believe Mac OS X mounts shares at a peer level instead of nested, correct me if I'm wrong). And last I check OS X IS symlink hell at the root level...all the top level "unixish" directories are links into another nested level.
/usr/share/man. Another is libraries, where search paths can be explicitly enumerated for desired libraries, instead of putting ALL libraries (even irrelevant ones) into a top level lib/ dir.
As for the technical question of how to "abstract" a dirty filesytem to begin with - filesystems like ReiserFS already have implicit support for metadata and attributes, and I believe there are 'ls' and other binaries that know how to do the right thing. This is all besides the point because I'm not advocating hiding the ugliness but instead refactoring the damn namespace so it makes sense in the first place and we don't have to put layer upon layer of abstraction to make it look "nice". One straightforward suggestion, make *everything* an app/ directory with conventional layout, and then rely on *indexing* (or symlinking to) the documentation, binaries, configuration, etc., instead of doing the inverse, which is breaking down each app into constituent pieces littered over the files system. One example is 'man' - which can *easily* be set up to index into all installed apps, instead of all apps installing docs into
I could make more suggestions as to what I think a better layout would look like, but that is besides the point - the issue is not necessarily about any given proposal, but that the issue be heard at all. The "unix community" if there ever was such a thing, is very conservative and resistent to changing things like that, mostly because it is proven, and works today, and therefore it shouldn't be messed with.
However, I do believe more work on the desktop will drive this refactoring. We have already seen several concessions from "unixisms" to the desktop, so hopefully this will be true (actually I think a refactoring would help BOTH the server and desktop, but the server people judge satisfaction by how LITTLE they have to use the system (how stable and consistent it is), while desktop users judge it by how MUCH they have to use the system (how user friendly/productive/efficient it is to use).
Whatchoo talkin' 'bout Willis!? There are two fundamental approaches to high load: threaded blocking IO, or non-threaded async IO. Both are different abstractions for the same fundamental goal of adding concurrance to a system. In reality most sites will do just FINE by modelling concurrency with a threadpool and blocking IO. Sure you CAN use non-threaded (or "less-threaded") async IO, but you incur a complexity overhead (this is the "overhead" hidden by the simplicity of threads). Unless you are writing an eBay or Amazon.com or Yahoo.com, a threaded/blocking-IO approach will work fine. Since it IS such a popular model, I think it is definately legitimate to compare kernel performance on those grounds. Note that I keep saying "abstraction" and "model". In reality there is nothing mandating that the thing I call a "thread" must really be implemented by a 1:1 mapping to a kernel lieghtweight process. Many systems use "green" threads or some other sort of user-space threading, so the implementation distinction is not as important.
To be completely optimal you wouldn't want a pure implementation of EITHER model, but some sort of hybrid in which you have a some number of threads, which each do some async IO. It all depends on the CPU/IO ratio for your app.
Maintainability is consistently underrated. You should shoot for a performance goal, and then create the SIMPLEST POSSIBLE SOLUTION to meet that goal...not spend days, weeks, months in coding kung foo zen. By the time you get out of your optimization stupor, hardware and network advances will probably have rendered your solution unnecessary.
Exactly my point. What Apple has done with Mac OS X is smear a layer on top of the unix internals since they are so useless. Under the covers it symlink hell. They have also done a lot to replace some unixish things (e.g. NetInfo). Also, look at how they treat applications. They are self-contained directory "bundles" which are represented by a single icon, but contain binaries and all other data needed. Something like this is what I was proposing.
Because you can hide the ugliness is not itself a justification for it being there in the first place.
Because any time anybody (like me) points out that the tradional "unix" file system with /usr and .../bin/... and .../sbin/... and ../local/.., etc. etc. etc., is vestigial and retarded, everybody flames back: U R n0t a rEEL hax0r d00d, with a thousand apologies about why that has to be to compensate for some stupid clustering strategy cooked up in the early eighties (don't know about you, but it seems obvious to me that all configurations for all my applications go in /etc/, while the cryptic /usr/local/sbin is translated into "user-level administrative applications deployed for the local network of this machine". Boy that taxonomy is USEFUL!).
The nearest thing I can find to a decent package manager is 'stow' which essentially does *nothing* but hide all that hierarchical complexity behind top-level directories. A new package *format* is not the problem, it's layout and management that is the problem. Everything else is a new wrapper on the same old problem.
[whine] [whine] [whine]
.NET has support for versioning far above any current platform, as it was designed in from the beginning. No, I do not know from practice, but I HAVE read the whitepapers, reviews and interviews. It specifically has provisions for concurrent versions of libraries (even in the same program), and has various compilation and runtime options. This directly obviates the need for static linking in the first place. Java doesn't have a linker either, and has about a 9 MB download last time I checked. I don't know what the hell he is talking about having to download so much stuff. I somehow got .NET automatically and didn't even NOTICE I got it until I opened Add/Remove Programs app, for some unrelated reason. (that is an entirely seperate issue).
Wtf is that rant about? As far as I can tell, the
News flash - new technology requires new, usually larger, downloads. BFD.
OMG I DIDN'T REALIZE I HAD TO PUT GAS IN MY CAR WHAT A RIP OFF!! I'M SO RESENTFUL NOW!!!
Doesn't thermodynamics imply that expending energy to remove the impurities can never result in more net energy? Sure your fuel might be cleaner and pack more punch...but presumably some energy somewhere was expended to "clean" the fuel.
Are you talking about a preprocessing, or dynamic processing of the fuel in the car?
This is just biased rant against particularly awful implementations of sniper rifles. Plenty of games feature real reloading, instability, losing focus after shooting, whatever. It may well be that sniper rifles are bad in general in computer games for specific reasons but the author fails woefully to prove the case.
Ok, my mistake, perhaps it was NewOS that was written by an ex-BeOS developer. In any case i'm pretty sure it was [Something]OS ;)
One of the things I think make it special is that it is written by an ex-BeOS developer. At least I *think* that is true, but now that the site is slashdotted I can't verify that.
What the hell? This is just a product training course.. not an IT curriculum.
An IT curriculum would look like
* introduction to programming (some intro language)
* statistics or some numerical mathematics course
* data structures
* concurrency
* operating system design
* database design
* artificial intelligence
* network topology and routing theory
etc.
Yeah! The game I've been waiting for! I've always wondered: "Me, is there a game that fulfills my need to break things, and then keep the broken pieces of that thing?" and I've always had to answer "No, Me, there isn't, you will just have to continue buying and breaking plastic silverware."
I hope this spawns a whole new genre of pointless games:
__Breakey: Crowbar Vs. Car__
__Breakey: Baseball Bat Vs. Seedy Convenience Store Window__
__Breakey: Install New Drivers Vs. Stable System___
__Breakey: Ethnic Slur Vs. Your Nose__
and finally:
__Breakey: Slashdot Reader Vs. Serious Human Relationship__
I noticed over the last decade or so that Lego changed from concentrating on abstract bricks that you could use to make anything you imagined, to these dumbass licensing schemes with special useless pieces and characters and funky objects and stupid spring-loaded action-oriented gimmicks. What utter crap. I also noticed that at some point there was a distinct CHANGE in the formula for their bricks. I can tell because they seem a bit more "slick" and "smooth" than I remember them being and when they connect they leave a more rough seem, and more easily fall apart. Can anybody verify this? I know I am not going insane, I just don't know if it is limited to region or series or what.
Thank god they are going back to what they used to do.
Engineers just can't see the forest for the trees.
Here is an introductory text which might shed some light for you: le click
Isn't the design of DNS especially relevant to host names because hosts, and hence host names are dynamically distributed?
Why would it necessarily follow that we would want to use DNS to store other arbitrary types of data (that do not necessarily have a decentralized nature) instead of a central database?
"Men who drank 6 cups of coffee a day"
I suppose dying of a heart attack at 30 would certain reduce the risk of contracting diabetes...
If I have more than one cup of coffee in a day I get twitching and cannot go to sleep...I can only imagine these poor zombies...
download your mp3s?
Because ideological zealots will resent you for selectively believing (or disbelieving) their particular ideological abstraction, and because of this other independents (like you) will probably be jaded and cynical to the point that they do not bother caring what you think in the first place. Accept that you will probably never have any political weight (is this the "silent majority") because of this, and because it is hard to get independent-minded people to stick together. The requirement that you are constantly skeptical of your own ideas will alienate you from your very self. Finally, you will have to face the possibility that either there is no truth, or that there is truth but that the fundamental nature of human societies is architected in such a manner as to preclude any hope that it will ever comprise the majority of commonly held belief.
Do you want to replace your warm pillow of ideology with the cold hard brick of reason? Do you want the red pill, or do you want another thick chunk of prime steak with fine aged wine?