He's also assuming that everyone thinks and interacts with computers exactly the same way he does.
But now you're assuming that computer-interaction-style is intrinsic rather than aquired. This is very similar to the world of education, where everybody seems to want to believe in people having different 'learning styles' (e.g. "I'm a visual learner") but the data just does not support that learning styles even exist. Instead, it appears that there are those who are willing to practice, and those that expect to be spoonfed. I computer-interaction-styles are similarly bogus.
Eh, it wasn't meant to be a flame, just that the jargon file is generally centered around the "hacker" culture, that specific term is more script kiddie-centric.
I do not believe that your sample size is large enough (or random enough) to support that distinction.
Not only did they build enough value to sell the company for $400 million, but they got to run the company that acquired them. That's success in my book. Yesterday's announcement by Apple was made possible by the foundation laid by NeXT.
You know, virii isn't, never has been, and never will be the correct plural form of virus.
It would be foolish to assume that the poster didn't know that s/he was violating the official rules. Say what you will about ESR and/or the jargon file, but this particular page could help you understand why you're wasting your efforts.
NeXTstep straddled the endian-ness divide with no problems. You could get fat binaries for x86, 68040, sparc, and pa-risc simultaneously. A lot of endian issues can be handled by good library design. That's not saying that a developer can't get themselves into trouble...just that it may not be a dire situation.
This QuickTransit solution really only needs to smooth things over until FAT binaries start appearing for applications. I bet we'll see FAT binaries for freeware/shareware hit the net within days, with several commercial apps within weeks.
Moreover, it won't be long until pics of celebrities hit the web. There will probably be entire sites devoted to indexing them. Minnie Driver in Heathrow, J Lo in Newark...
We just have no way of knowing if you're merely pretending to believe that "we" means only 2 people,
Um, the problem is even worse when n > 2. Hypocrisy is a charge that only makes sense when n=1. In other words, when the same person utters the incompatible statements. Why is that so difficult to comprehend?
The Open Source community had better examine itself pretty hard on this. We complained for years about lack of corporate support, but once we make "our" version of something, not only do we discourage the use of corporate software, we condemn companies for even trying.
I think a matter of greater urgency, however, is examining the use of the concepts "us", "we", "our" (etc.) in conjunction with the implication of hypocrisy.
If person A posts one opinion about event X on a website, and person B posts a conflicting opinion about event Y on the same website, that doesn't mean that the collective {A,B} is guilty of hypocrisy. Honestly, it's like overhearing two different conversations at two different tables in a restaurant and standing up in outrage, forcing people who don't even know each other to resolve the disparity in their world views.
This, my friend, is the greater threat to The Community(tm).
Whoa, that's out-of-bounds, dude. How are we going
to keep up this pan-fora flamewar if people go around apologizing and admitting that the other side was reasonable!? If you don't have something destructive to say, don't say anything at all.
I bet y'all are gonna peel the quartz/cocoa/CoreFoo/Aqua layers off of Mach and release a kick ass linux distribution to go head-to-head with Longhorn on Intel hardware.
See what happens when you ask people to ponder?:-)
In fact I was refering to the abstractions that you use to describe the functional overlap. I didn't mean abstractions to refer to code structure, but to the concepts that you use to describe function. If you describe them as event-based-process-launchers, then it's much easier to see the functional overlap. If you describe each system in concrete, specific terms then you blind yourself to the functional overlap.
As for consolidating configuration, there is practical benefit in having one well-debugged configuration system shared among many, as opposed to each daemon maintaining its own exotic mechanism.
You see these programs as "NOT doing the same thing" because of the abstractions that you have used in describing the functions of these programs. If you reframe the description using a common abstraction then it is easy to see that launchd is, in fact, consolidating function (and eradicating complexity) in a right proper way: all of those systems are merely handling the startup of processes in response to system events.
The only thing that is different between these systems is that each specializes in certain event types...which is thin justification for a bajillion different configuration formats, if you ask me.
Considering RSS fits into the same part of the "transportation" equation as HTML. The above isn't saying that much. Control is what you make it out to be.
The semantic differences between the two make all of the difference. RSS is entirely data, wherease HTML is a mix of data and presentation (not necessarily, but as practiced). The bogosity comes when someone uses HTML's presentation features to force bogosity in your face.
If you have problems with different version of documents in your organization perhaps you should use a version control system like CVS or Subversion
Baby steps, Taladar. That's the way to make progress. It's much easier to get an organization to swallow the idea of capturing communication if you sneak up on them. Issue-tracking systems and wikis can be set up with email gateways so that many people don't know that they're using them. It's much easier than trying to convince management that everybody in the organization needs to be trained on a version-control system.
Even if you were to succeed in getting everybody to put their Word documents into CVS or SVN (a task that neither was really intended for) you will find that you're still in the situation where all of this valuable knowledge is trapped within Word documents...ugh.
I'd rather kill both birds with one stone, thank you.
The lightbulb didn't come one for me until I tried a really nice RSS reader. It's provides a way to skim large amounts of information looking for nuggets in a very small amount of time. (In my case, it was NetNewsWire). In my opinion the RSS phenomenon is an example of information-consumers re-routing around bogosity, such as poorly designed sites and intrusive advertisements. You could either take control over how you consume information, or you can be a gullet with an upwardly-open maw at the end of a conveyor. Your choice.
There are things that RSS is NOT good for. Like, sending and receiving email or most forms of office communications.
I'm not sure I agree with you a hundred percent on your analysis, there, Flexible.
The point here is not that RSS should be used for sending and receiving email. Rather, the point is that email leads to lots of problems in office communications...too much valuable knowledge ends up scattered in various inboxes, unavailable to the organization as a whole. Or even worse than that, you end up with a bajillion revisions of miscellaneous documents flying around as attachments.
A much better idea would be to deprecate email as it is currently used, and actually capture intra-office communication in some issue-tracking system, wiki, or other appropriate system.
Where I work we started doing this with JIRA and Confluence, both of which offer RSS feeds so that you can stay up-to-date on the changes within those systems. The combination is powerful, and I recommend it without hesitation.
I feel a good use for Dual-core systems is to put the OS on one core, including all explorer.exe instances and threads.
I've read this sentiment several times now since the dual-core craze came about. So long as your kernel and web/file browser tasks get scheduled, why should you care which core they're running on?
I remember in the early days there was a program called 'crashme' that threw randomly-generated executables at the system, and it was credited bolstering stability. Do tests like this still hapen frequently by the unappreciated? Is there a good place online to read about these tests and their results for different point-releases?
Along similar lines, I recall someone throwing random input at the various gnu utilities, and it was discovered that they were more robust against this sort of abuse than the commercial unix equivalents.
Are there any other interesting tests that anybody knows about? Breaking stuff is fun.
Slashdot Mirror
But now you're assuming that computer-interaction-style is intrinsic rather than aquired. This is very similar to the world of education, where everybody seems to want to believe in people having different 'learning styles' (e.g. "I'm a visual learner") but the data just does not support that learning styles even exist. Instead, it appears that there are those who are willing to practice, and those that expect to be spoonfed. I computer-interaction-styles are similarly bogus.
I do not believe that your sample size is large enough (or random enough) to support that distinction.
Not only did they build enough value to sell the company for $400 million, but they got to run the company that acquired them. That's success in my book. Yesterday's announcement by Apple was made possible by the foundation laid by NeXT.
It would be foolish to assume that the poster didn't know that s/he was violating the official rules. Say what you will about ESR and/or the jargon file, but this particular page could help you understand why you're wasting your efforts.
NeXTstep straddled the endian-ness divide with no problems. You could get fat binaries for x86, 68040, sparc, and pa-risc simultaneously. A lot of endian issues can be handled by good library design. That's not saying that a developer can't get themselves into trouble...just that it may not be a dire situation.
This QuickTransit solution really only needs to smooth things over until FAT binaries start appearing for applications. I bet we'll see FAT binaries for freeware/shareware hit the net within days, with several commercial apps within weeks.
That's an odd thing to say. I would have guessed that an 'efficient' processor is one that had a very good MIPS/Watt ratio.
Dude, that's poetry.
Moreover, it won't be long until pics of celebrities hit the web. There will probably be entire sites devoted to indexing them. Minnie Driver in Heathrow, J Lo in Newark...
Subtle distinction here: bashing that uses truth, and bashing that distorts it.
Um, the problem is even worse when n > 2. Hypocrisy is a charge that only makes sense when n=1. In other words, when the same person utters the incompatible statements. Why is that so difficult to comprehend?
I think a matter of greater urgency, however, is examining the use of the concepts "us", "we", "our" (etc.) in conjunction with the implication of hypocrisy.
If person A posts one opinion about event X on a website, and person B posts a conflicting opinion about event Y on the same website, that doesn't mean that the collective {A,B} is guilty of hypocrisy. Honestly, it's like overhearing two different conversations at two different tables in a restaurant and standing up in outrage, forcing people who don't even know each other to resolve the disparity in their world views.
This, my friend, is the greater threat to The Community(tm).
Whoa, that's out-of-bounds, dude. How are we going to keep up this pan-fora flamewar if people go around apologizing and admitting that the other side was reasonable!? If you don't have something destructive to say, don't say anything at all.
See what happens when you ask people to ponder? :-)
In fact I was refering to the abstractions that you use to describe the functional overlap. I didn't mean abstractions to refer to code structure, but to the concepts that you use to describe function. If you describe them as event-based-process-launchers, then it's much easier to see the functional overlap. If you describe each system in concrete, specific terms then you blind yourself to the functional overlap. As for consolidating configuration, there is practical benefit in having one well-debugged configuration system shared among many, as opposed to each daemon maintaining its own exotic mechanism.
The only thing that is different between these systems is that each specializes in certain event types...which is thin justification for a bajillion different configuration formats, if you ask me.
What could be friendlier than releasing unified diffs that can be applied with patch, plus the entire source tree so that you can do your own diffs?
Simon Says for the NeXT, 1992.
Just in case anybody was curious about what the term LP64 implies, or what the alternatives choices where, this page describes them.
The semantic differences between the two make all of the difference. RSS is entirely data, wherease HTML is a mix of data and presentation (not necessarily, but as practiced). The bogosity comes when someone uses HTML's presentation features to force bogosity in your face.
Baby steps, Taladar. That's the way to make progress. It's much easier to get an organization to swallow the idea of capturing communication if you sneak up on them. Issue-tracking systems and wikis can be set up with email gateways so that many people don't know that they're using them. It's much easier than trying to convince management that everybody in the organization needs to be trained on a version-control system.
Even if you were to succeed in getting everybody to put their Word documents into CVS or SVN (a task that neither was really intended for) you will find that you're still in the situation where all of this valuable knowledge is trapped within Word documents...ugh.
I'd rather kill both birds with one stone, thank you.
The lightbulb didn't come one for me until I tried a really nice RSS reader. It's provides a way to skim large amounts of information looking for nuggets in a very small amount of time. (In my case, it was NetNewsWire). In my opinion the RSS phenomenon is an example of information-consumers re-routing around bogosity, such as poorly designed sites and intrusive advertisements. You could either take control over how you consume information, or you can be a gullet with an upwardly-open maw at the end of a conveyor. Your choice.
I'm not sure I agree with you a hundred percent on your analysis, there, Flexible.
The point here is not that RSS should be used for sending and receiving email. Rather, the point is that email leads to lots of problems in office communications...too much valuable knowledge ends up scattered in various inboxes, unavailable to the organization as a whole. Or even worse than that, you end up with a bajillion revisions of miscellaneous documents flying around as attachments.
A much better idea would be to deprecate email as it is currently used, and actually capture intra-office communication in some issue-tracking system, wiki, or other appropriate system.
Where I work we started doing this with JIRA and Confluence, both of which offer RSS feeds so that you can stay up-to-date on the changes within those systems. The combination is powerful, and I recommend it without hesitation.
I've read this sentiment several times now since the dual-core craze came about. So long as your kernel and web/file browser tasks get scheduled, why should you care which core they're running on?
I remember in the early days there was a program called 'crashme' that threw randomly-generated executables at the system, and it was credited bolstering stability. Do tests like this still hapen frequently by the unappreciated? Is there a good place online to read about these tests and their results for different point-releases? Along similar lines, I recall someone throwing random input at the various gnu utilities, and it was discovered that they were more robust against this sort of abuse than the commercial unix equivalents. Are there any other interesting tests that anybody knows about? Breaking stuff is fun.