What D-Link did was unprofessional and irresponsible, they should be condemned for it, and Kamp had every right to complain to them. Nevertheless, it's good that this has been resolved without legal action. If Kamp had actually prevailed in court, it might have set a dangerous precedent: Linux distributions are distributed with hundreds of preconfigured links to all sorts of sites. Generally, those sites have agreed to that, but if their ownership or their policies changed, this could cause serious trouble for the distributor.
"Have to" in what sense? In the sense that people bitch at you if you don't, then yes. "Have to" in the sense that there is some special rule for NTP servers that allows them to define acceptable use policies without getting a legal agreement, well, that hasn't been resolved.
It's not going to happen. Microsoft manages to keep its position by keeping the barriers to entry high through a bunch of approaches: aggressive marketing, bundling, tying, loss leaders, proprietary formats and APIs, and monopolistic practices.
Open source is about keeping barriers to entry low. If a Linux company had 90% of the market, it would be because 90% of the market actually chose them freely, and they'd only keep that market share as long as they did a good job because anybody can take the system, fork it, and compete.
(I know that Microsoft advocates often argue that people chose Microsoft freely, too, but it's clear that that's not the whole truth. The great majority of their users probably doesn't have a choice, either because they don't know anything else, or because they are locked in in some way.)
The languages you cite, except for Lisp, are also low level languages
Well, good, so you recognize the existence of other "low level languages" suitable for writing kernels.
Now, what's your point? I'm not arguing that kernels should be written in some particular language "level", I'm arguing that specifically the C programming language is a bad language to write kernels in. Writing a kernel in Modula-2, ObjectPascal, or Oberon avoids many of the problems that writing a kernel in C has.
(You're wrong on both Lisp and Python. One can write a kernel for x86 in Lisp--I have done it, and Python's problem isn't that it's "high level", whatever that may mean, but that it's designed as a scripting language and can't be compiled well.)
I'll eat my words, without catsup, when you can manage to show me a running usable kernel (for a reasonably traditional CPU) in a high level language
Apple Lisa (ObjectPascal), Alto (Cedar/Mesa), Lisp Machine (Lisp), Ceres workstation (Oberon), SPIN (Modula-3), embedded systems (Ada, Modula-2), to name just a few. There are dozens more if you only care to look around.
C is no more low-level than those other languages (you can do in all of them what you can do in C).
C isn't a low level language, it's just an unnecessarily badly designed high level language.
Microkernels like Mach have been unsuccessful because putting everything into separate address spaces makes a lot of things quite difficult.
C-based monolithic kernels like Linux and UNIX run into software engineering problems--it gets harder and harder to ensure stability and robustness as the code mushrooms because there is no fault isolation.
The solution? Simple: get the best of both worlds through language-supported fault isolation (this can even be a pure compile-time mechanism, with no runtime overhead). It's not rocket science, it's been done many times before. You get all the fault isolation of microkernels and still everything can access anything else when it needs to, as long as the programmer just states what he is doing clearly.
C-based monolithic kernels were a detour caused by the UNIX operating system, an accident of history. UNIX has contributed enormously to information technology, but its choice of C as the programming language has been more a curse than a blessing.
Networks will disable various features on the phone at their whim.
In most European countries, there is no such thing as "the network's phone"; you can get a phone cheaper with a contract, but you can certainly use your own, complete with Bluetooth and everything else.
it is about the fact that the major software that supports the OpenDocument formats does not have adequate accessibility
MS Office supports ODF (through a plug-in), so the point is moot.
I find it funny that many people seem to be pointing at the fact that Microsoft Office will have an ODF plugin and that those disabled people should just use that. This only affirms the fact that Microsoft Office is a superior product to all of its competitors, or at least the open source ones supporting OpenDocument.
No, it only affirms that people believe it has superior accessibility right now. But even if Microsoft really were the overall best office suite in the market (not an unreasonable assertion), so what? That's the end result of a decade of vendor lock-in and monopolistic behavior. Microsoft Office is, for practical purposes, the best office suite because Microsoft has killed all the competitors through monopolistic practices.
Ask yourself this: why has Microsoft consistently refused to open up their format? If they were secure in the belief that their product is much better than everybody else's, then everybody would be buying and using it, even if other products had the ability to read and write it. But, instead, they have chosen a technically worse, incompatible "alternative" XML format for Office, patented it, and made it the dfeault.
In reality, Microsoft themselves keeps demonstrating that they know that their product has serious problems and that they fear they'd lose lots of market share in a competitive market because, while there may or may not be good competitors out there right now, once the format is open, there will be good competitors.
Having said all this - the man died in an afternoon nap, right after a big lunch, in his sleep of entirely natural causes.
Cancer and heart disease are "natural causes". And people don't die from sleeping, so something was wrong.
They may hold SOME of the cure for cancer. No one ever had it on either side of my family, for the last 3 generations that I could dig up. Everyone died from 80+ to about 95.
You can bet that scientists are doing extensive family studies looking for genetic markers related to absence of specific diseases, as well as long life, with the goal of eventually creating treatments.
A better question would be "Are there cancer resistant humans and we don't know about it?" [...] Perhaps there is cancer resistant strains of humans and we just don't know about it.
Actually, there are. Some genes make you highly likely to develop certain kinds of cancers, and others appear to confer some protection. I think it's been pretty well established, too, that some people are much more tolerant of pollutants, including smoking, than others.
The fact that this mouse appears to be "resistant to cancer" in general is probably an overgeneralization from too little data. There are so many different cancers with so many causes and pathologies that it's unlikely that there will be a single cure for them all, ever.
It's good that they are thinking in this direction, but I think this is a two-edged sword. In the end, identifying patents is a lot of work; who is going to sit in front of the Wiki every day and weed out one bad patent after another? Maybe companies will do it for their own products, maybe not.
Also, if the site gets used a lot, there are going to be many comments on approvable patents, and many valid comments questioning the validity of a patent application will require quite a bit of work to understand and verify. So, this still means a lot of effort for the USPTO; in fact, it probably means more work to do right than they are willing to invest right now.
If a bad patent isn't caught at that stage for whatever reason, then the people obtaining the patent will have an even stronger case: "look, not only did the patent examiners look at it, the public had a chance to review it, too, and there were no objections back then".
If the geeks of this world get together some kind of organization (informal or formal) to review these patents and ensure that the USPTO at least gets a lot of good comments. Furthermore, the comments should become part of the record of the patent application so that they can be reviewed later by a judge, who might then have more support to decide that a patent never should have been granted in the first place.
That view is frustratingly short-sighted. Microsoft Office is a tool developed for people with no disabilities; accessibility will never be a primary consideration. Using Microsoft Office with a screen reader or a magnifier is at best a crutch.
Much better interaction styles are possible for the disabled. In the past, they haven't been commercially viable because Microsoft Office formats have dominated the market With open document formats, there would finally be new companies entering the market with high quality tools specifically for people with disability.
Let's not even dwell on the fact that the disabled have experienced first hand how frustrating it is to be at the mercy of Microsoft; do you really think that other groups aren't equally frustrated with Microsoft's predominance but lack the lobbying power to get Microsoft to hire a 40 person crew to address their needs? And what happens with the next paradigm shift? GUIs will have transparency, high resolution visualization, and other features, and it will take many years for accessibility tools to catch up--do you want to continue to be at the mercy of a single company to meet your needs in perpetuity?
Adoption of open document formats is a huge win for the disabled, without any downside. You can even continue to use Microsoft Word, since there will be plug-ins. But you may want to work with the OOo people to improve accessibility there. And you will see ODF apps aimed at people with disabilities soon after the format becomes reasonably widely adopted. Please, don't screw this one up, for your own sake and the sake of everybody else.
Re my previous message, if you're doing this as a self-run business, just tell customers you don't get along with to go somewhere else. The problem may be on their end, it may be on your end, but either way, it's a relationship not worth continuing. Say something nice like "I'm sorry, but I have more business than I can handle right now. But I know Smith's Computer Support, and they'll be happy to help you."
If they included its whistling personality and the song they use for the whistling, there is a GOOD chance they can copyright that specific interpretation of the smiley as a cartoon character, much in the way the Church of the Subgenius seems to hold the copyright for 'Bob's pipe-wielding visage, despite how common the image of a clean-cut 50's male with a pipe actually was in those times.
You're confusing copyrights and trademarks. They can't "copyright" the smiley face because they didn't create it. They can trademark it. But if the smiley face actually were under copyright, then they couldn't trademark it because you couldn't reproduce it (so they could never use it).
Legally, WalMart may be able to get away with registering a trademark on the smiley face, if it is really in the public domain. Ethically, that's wrong: the smiley face is a cultural icon that no company ought to be able to claim rights to.
However, one can throw a monkey wrench in their plans simply by re-creating the association between the smiley face and psychotic killers, since those seem to love the symbol. Given stories by WalMart employees, perhaps their choice of trademark isn't so inappropriate after all.
Well, presumably you have a manager, discuss your time allocation with him and ask him how to prioritize your tasks. (If your "demanding end user" is your manager, you have a problem.)
As for personal problems, harsh as it is, you get paid for a certain number of hours of work, and all things being equal, you have to perform them, come rain or come shine, no more and no less. If you're valuable to your employer, they may try to accommodate you and give you more room for a little while, or if it's a good employer, they may have a policy in place. If not, you might take vacation days (maybe just every few days), go part time temporarily, or take an unpaid leave.
Current operating systems have two characteristics that make them unreliable and insecure: They are huge and they have very poor fault isolation
And the reason is simple: they're written in C. And they will continue to be huge and have very poor fault isolation even if they become microkernels, as long as the programming language is still C. Fault isolation needs to be provided at the language level so that every object is isolated from every other, not just a bunch of bigger chunks, and so that you can do recovery without restarting a whole subsystem.
On the other hand, it matters less and less. Kernels may be big and ugly and hard to maintain, but there isn't a lot of functionality that should go into the kernel that isn't already there, and current kernels are pretty stable thanks to the enormous efforts of their maintainers.
So, Tanenbaum has identified most of the problem, but he is prescribing the wrong remedy.
Of course, there are no good, widely used languages that you can currently use. Well, to be specific, C# would be a decent language for a modern kernel, but none of the current implementations are up to the taks. Maybe we'll get a static "gcc#" compiler eventually and that might be suitable for the next generation kernel. Or maybe a simple statically compiled Java subset, similar to embedded Java, with some unavoidable unsafe extensions.
The only software other than browsers and other internet software I know I'll specifically use is Open Office. Perl more than likely, and other programming tools, say maybe Eclipse. I may use Macromedia Studio but I'm not sure right now. I'd also like to find a program for Macs like XML Spy for Windows.
Then the Mac is fine for you. OpenOffice 2.0 is not all that great with X11 (no X11 apps really are), but the NeoOffice port of 2.0 is progressing.
I'm going with Macs instead of PCs simply because I prefer Macs.
Oh, there's no question: Macs are much nicer than PCs.
What I object to is claims that they are a better replacement for a UNIX or Linux machine--they are not. Both Macs and Linux machines each have their advantages and disadvantages in practice, and which to run is really a case-by-case decision.
Actually, let me be clarify: the examples on the second page "involve" fatigue, but the fatigue is not part of the hysteresis effect itself. The dictionary definition (Webster) is pretty good: "n : the lagging of an effect behind its cause; especially the phenomenon in which the magnetic induction of a ferromagnetic material lags behind the changing magnetic field"; it's a lagging, not a degradation. Hysteresis often occurs without degradation (like on your harddisk). and degradation often occurs with hysteresis.
As I was saying: term "hysteresis" is not used to describe permanent fatigue or degradation of a material. The Wikipedia article specifically talks about "immediate history", and the new link you posted likewise gives correct examples of hysteresis, none of which involve fatigue or degradation. Shape memory alloys exhibit hysteresis and they also exhibit fatigue; the two are two distinct effects.
No, that's not what "hysteresis" means. Hysteresis means that their behavior depends on their immediate history (meaning, one or two contractions earlier). Long term degradation is called something else, depending on the cause and behavior (e.g., "fatigue").
If you want to know more about it, just go to the next X.org developer's conference.
I know the history of X11 well, having used the X Window System since its X10 days.
unfortunately, you'll also find that the term X11 effectively refers to one shared codebase:)
If X.org seriously starts treating X11 like a codebase rather than a protocol, that's the end of the X11 window system. With its network transparency already effectively broken by both Gnome and KDE, it would really open the floodgates to mutually incompatible direct-to-display graphics systems.
when someone says "hey, there is a problem with X11", they are almost certainly, without knowing anything about it, referring to a single codebase that has the problem.
Yes, and that's why it's important to correct them because if X11 and X.org become identified, the aspects of X11 that have allowed it to survive several generations of Macintosh and Windows and still be relevant will be lost.
Apple should do something that you consider common-sensical THEREFORE they have a hidden agenda.
No, I'm not saying that Apple "should do" something, I'm saying that they "should be" considered published copyrighted materials because the alternatives don't make any sense (trade secret, etc.).
Now, why am I arguing that Apple has a hidden agenda? It's because they are taking this extraordinary step of treating service manuals like trade secrets.
Apple clearly has a policy that to hassle people who "steal" their IP.
Yeah, and now think about why that policy exist. It's not decided on randomly, you know.
He does not have the discretion to say "Oh, I should give them a pass, that's probably fair use."
He better have, because Apple's legal fees could get pretty high if they pursue copyright infringement cases where there are none.
You've obviously never worked in any private organization bigger than a little league team.
You're obviously prone to incorrect overgeneralizations.
Yeah, you can recompile, if you have the time and patience. You can even use Fink or DarwinPorts, which requires less time and patience, but not much.
In the end, even with lots of time and patience, you still only get a small fraction of the software that comes standard with a Linux desktop distribution, and it ends up working nowhere near as well, among other things, because Apple's X11 implementation isn't very good. And even to the degree that it does work, OS X applications won't interoperate well with X11 applications.
Running UNIX and Linux apps on OS X is a stop-gap measure, it's not something you want to do day-to-day. I've tried, and in the end, I erased all Linux ports from my Mac--I'd prefer many of them to their Mac equivalents, but they just don't work well enough under OS X to use regularly.
The kernel isn't the problem (technically, it's Mach, not BSD, but close enough).
The problem is software installation: Fink and DarwinPorts are slow, require lots of disk space, only cover a fraction of the packages from any standard Linux distribution, and often don't work at all.
When you get software installed, any kind of Linux GUI software tends to work poorly: Apple's X11 server is slow, and integration between X11 and OS X is poor (not even keymaps work properly). Even when people try hard (like the OpenOffice port), integration doesn't work well.
OS X is not a drop-in replacement for a UNIX workstation or a Linux desktop. It's something that will run many UNIX and Linux apps in a pinch, but you'll be happier with OS X apps on OS X, because that's what's supported best.
Now, if you think you don't need all that Linux software, that's fine. However, take it from me: trying to replace all the software you might want to use that comes on SuSE, RedHat, or Ubuntu with OS X equivalents is expensive.
If you're buying an OS X laptop expecting to get a "better" UNIX system, as Apple likes to claim, you'll be disappointed--it just doesn't fulfill that promise. Well, you'll be disappointed unless you didn't want a UNIX system in the first place and just like the sound of it.
Slashdot Mirror
What D-Link did was unprofessional and irresponsible, they should be condemned for it, and Kamp had every right to complain to them. Nevertheless, it's good that this has been resolved without legal action. If Kamp had actually prevailed in court, it might have set a dangerous precedent: Linux distributions are distributed with hundreds of preconfigured links to all sorts of sites. Generally, those sites have agreed to that, but if their ownership or their policies changed, this could cause serious trouble for the distributor.
Public or not, you have to follow the rules.
"Have to" in what sense? In the sense that people bitch at you if you don't, then yes. "Have to" in the sense that there is some special rule for NTP servers that allows them to define acceptable use policies without getting a legal agreement, well, that hasn't been resolved.
It's not going to happen. Microsoft manages to keep its position by keeping the barriers to entry high through a bunch of approaches: aggressive marketing, bundling, tying, loss leaders, proprietary formats and APIs, and monopolistic practices.
Open source is about keeping barriers to entry low. If a Linux company had 90% of the market, it would be because 90% of the market actually chose them freely, and they'd only keep that market share as long as they did a good job because anybody can take the system, fork it, and compete.
(I know that Microsoft advocates often argue that people chose Microsoft freely, too, but it's clear that that's not the whole truth. The great majority of their users probably doesn't have a choice, either because they don't know anything else, or because they are locked in in some way.)
The languages you cite, except for Lisp, are also low level languages
Well, good, so you recognize the existence of other "low level languages" suitable for writing kernels.
Now, what's your point? I'm not arguing that kernels should be written in some particular language "level", I'm arguing that specifically the C programming language is a bad language to write kernels in. Writing a kernel in Modula-2, ObjectPascal, or Oberon avoids many of the problems that writing a kernel in C has.
(You're wrong on both Lisp and Python. One can write a kernel for x86 in Lisp--I have done it, and Python's problem isn't that it's "high level", whatever that may mean, but that it's designed as a scripting language and can't be compiled well.)
I'll eat my words, without catsup, when you can manage to show me a running usable kernel (for a reasonably traditional CPU) in a high level language
Apple Lisa (ObjectPascal), Alto (Cedar/Mesa), Lisp Machine (Lisp), Ceres workstation (Oberon), SPIN (Modula-3), embedded systems (Ada, Modula-2), to name just a few. There are dozens more if you only care to look around.
C is no more low-level than those other languages (you can do in all of them what you can do in C).
C isn't a low level language, it's just an unnecessarily badly designed high level language.
Microkernels like Mach have been unsuccessful because putting everything into separate address spaces makes a lot of things quite difficult.
C-based monolithic kernels like Linux and UNIX run into software engineering problems--it gets harder and harder to ensure stability and robustness as the code mushrooms because there is no fault isolation.
The solution? Simple: get the best of both worlds through language-supported fault isolation (this can even be a pure compile-time mechanism, with no runtime overhead). It's not rocket science, it's been done many times before. You get all the fault isolation of microkernels and still everything can access anything else when it needs to, as long as the programmer just states what he is doing clearly.
C-based monolithic kernels were a detour caused by the UNIX operating system, an accident of history. UNIX has contributed enormously to information technology, but its choice of C as the programming language has been more a curse than a blessing.
Networks will disable various features on the phone at their whim.
In most European countries, there is no such thing as "the network's phone"; you can get a phone cheaper with a contract, but you can certainly use your own, complete with Bluetooth and everything else.
They're in the business of providing telephone service, after all.
Yeah, and they should price their telephone service so that it's in line with VoIP, reflecting actual cost plus a small margin.
Instead, they are massively distorting the telephone market (in collusion with other providers).
it is about the fact that the major software that supports the OpenDocument formats does not have adequate accessibility
MS Office supports ODF (through a plug-in), so the point is moot.
I find it funny that many people seem to be pointing at the fact that Microsoft Office will have an ODF plugin and that those disabled people should just use that. This only affirms the fact that Microsoft Office is a superior product to all of its competitors, or at least the open source ones supporting OpenDocument.
No, it only affirms that people believe it has superior accessibility right now. But even if Microsoft really were the overall best office suite in the market (not an unreasonable assertion), so what? That's the end result of a decade of vendor lock-in and monopolistic behavior. Microsoft Office is, for practical purposes, the best office suite because Microsoft has killed all the competitors through monopolistic practices.
Ask yourself this: why has Microsoft consistently refused to open up their format? If they were secure in the belief that their product is much better than everybody else's, then everybody would be buying and using it, even if other products had the ability to read and write it. But, instead, they have chosen a technically worse, incompatible "alternative" XML format for Office, patented it, and made it the dfeault.
In reality, Microsoft themselves keeps demonstrating that they know that their product has serious problems and that they fear they'd lose lots of market share in a competitive market because, while there may or may not be good competitors out there right now, once the format is open, there will be good competitors.
Having said all this - the man died in an afternoon nap, right after a big lunch, in his sleep of entirely natural causes.
Cancer and heart disease are "natural causes". And people don't die from sleeping, so something was wrong.
They may hold SOME of the cure for cancer. No one ever had it on either side of my family, for the last 3 generations that I could dig up. Everyone died from 80+ to about 95.
You can bet that scientists are doing extensive family studies looking for genetic markers related to absence of specific diseases, as well as long life, with the goal of eventually creating treatments.
A better question would be "Are there cancer resistant humans and we don't know about it?" [...] Perhaps there is cancer resistant strains of humans and we just don't know about it.
Actually, there are. Some genes make you highly likely to develop certain kinds of cancers, and others appear to confer some protection. I think it's been pretty well established, too, that some people are much more tolerant of pollutants, including smoking, than others.
The fact that this mouse appears to be "resistant to cancer" in general is probably an overgeneralization from too little data. There are so many different cancers with so many causes and pathologies that it's unlikely that there will be a single cure for them all, ever.
It's good that they are thinking in this direction, but I think this is a two-edged sword. In the end, identifying patents is a lot of work; who is going to sit in front of the Wiki every day and weed out one bad patent after another? Maybe companies will do it for their own products, maybe not.
Also, if the site gets used a lot, there are going to be many comments on approvable patents, and many valid comments questioning the validity of a patent application will require quite a bit of work to understand and verify. So, this still means a lot of effort for the USPTO; in fact, it probably means more work to do right than they are willing to invest right now.
If a bad patent isn't caught at that stage for whatever reason, then the people obtaining the patent will have an even stronger case: "look, not only did the patent examiners look at it, the public had a chance to review it, too, and there were no objections back then".
If the geeks of this world get together some kind of organization (informal or formal) to review these patents and ensure that the USPTO at least gets a lot of good comments. Furthermore, the comments should become part of the record of the patent application so that they can be reviewed later by a judge, who might then have more support to decide that a patent never should have been granted in the first place.
That view is frustratingly short-sighted. Microsoft Office is a tool developed for people with no disabilities; accessibility will never be a primary consideration. Using Microsoft Office with a screen reader or a magnifier is at best a crutch.
Much better interaction styles are possible for the disabled. In the past, they haven't been commercially viable because Microsoft Office formats have dominated the market With open document formats, there would finally be new companies entering the market with high quality tools specifically for people with disability.
Let's not even dwell on the fact that the disabled have experienced first hand how frustrating it is to be at the mercy of Microsoft; do you really think that other groups aren't equally frustrated with Microsoft's predominance but lack the lobbying power to get Microsoft to hire a 40 person crew to address their needs? And what happens with the next paradigm shift? GUIs will have transparency, high resolution visualization, and other features, and it will take many years for accessibility tools to catch up--do you want to continue to be at the mercy of a single company to meet your needs in perpetuity?
Adoption of open document formats is a huge win for the disabled, without any downside. You can even continue to use Microsoft Word, since there will be plug-ins. But you may want to work with the OOo people to improve accessibility there. And you will see ODF apps aimed at people with disabilities soon after the format becomes reasonably widely adopted. Please, don't screw this one up, for your own sake and the sake of everybody else.
Re my previous message, if you're doing this as a self-run business, just tell customers you don't get along with to go somewhere else. The problem may be on their end, it may be on your end, but either way, it's a relationship not worth continuing. Say something nice like "I'm sorry, but I have more business than I can handle right now. But I know Smith's Computer Support, and they'll be happy to help you."
If they included its whistling personality and the song they use for the whistling, there is a GOOD chance they can copyright that specific interpretation of the smiley as a cartoon character, much in the way the Church of the Subgenius seems to hold the copyright for 'Bob's pipe-wielding visage, despite how common the image of a clean-cut 50's male with a pipe actually was in those times.
You're confusing copyrights and trademarks. They can't "copyright" the smiley face because they didn't create it. They can trademark it. But if the smiley face actually were under copyright, then they couldn't trademark it because you couldn't reproduce it (so they could never use it).
Legally, WalMart may be able to get away with registering a trademark on the smiley face, if it is really in the public domain. Ethically, that's wrong: the smiley face is a cultural icon that no company ought to be able to claim rights to.
However, one can throw a monkey wrench in their plans simply by re-creating the association between the smiley face and psychotic killers, since those seem to love the symbol. Given stories by WalMart employees, perhaps their choice of trademark isn't so inappropriate after all.
Well, presumably you have a manager, discuss your time allocation with him and ask him how to prioritize your tasks. (If your "demanding end user" is your manager, you have a problem.)
As for personal problems, harsh as it is, you get paid for a certain number of hours of work, and all things being equal, you have to perform them, come rain or come shine, no more and no less. If you're valuable to your employer, they may try to accommodate you and give you more room for a little while, or if it's a good employer, they may have a policy in place. If not, you might take vacation days (maybe just every few days), go part time temporarily, or take an unpaid leave.
Current operating systems have two characteristics that make them unreliable and insecure: They are huge and they have very poor fault isolation
And the reason is simple: they're written in C. And they will continue to be huge and have very poor fault isolation even if they become microkernels, as long as the programming language is still C. Fault isolation needs to be provided at the language level so that every object is isolated from every other, not just a bunch of bigger chunks, and so that you can do recovery without restarting a whole subsystem.
On the other hand, it matters less and less. Kernels may be big and ugly and hard to maintain, but there isn't a lot of functionality that should go into the kernel that isn't already there, and current kernels are pretty stable thanks to the enormous efforts of their maintainers.
So, Tanenbaum has identified most of the problem, but he is prescribing the wrong remedy.
Of course, there are no good, widely used languages that you can currently use. Well, to be specific, C# would be a decent language for a modern kernel, but none of the current implementations are up to the taks. Maybe we'll get a static "gcc#" compiler eventually and that might be suitable for the next generation kernel. Or maybe a simple statically compiled Java subset, similar to embedded Java, with some unavoidable unsafe extensions.
The only software other than browsers and other internet software I know I'll specifically use is Open Office. Perl more than likely, and other programming tools, say maybe Eclipse. I may use Macromedia Studio but I'm not sure right now. I'd also like to find a program for Macs like XML Spy for Windows.
Then the Mac is fine for you. OpenOffice 2.0 is not all that great with X11 (no X11 apps really are), but the NeoOffice port of 2.0 is progressing.
I'm going with Macs instead of PCs simply because I prefer Macs.
Oh, there's no question: Macs are much nicer than PCs.
What I object to is claims that they are a better replacement for a UNIX or Linux machine--they are not. Both Macs and Linux machines each have their advantages and disadvantages in practice, and which to run is really a case-by-case decision.
Actually, let me be clarify: the examples on the second page "involve" fatigue, but the fatigue is not part of the hysteresis effect itself. The dictionary definition (Webster) is pretty good: "n : the lagging of an effect behind its cause; especially the phenomenon in which the magnetic induction of a ferromagnetic material lags behind the changing magnetic field"; it's a lagging, not a degradation. Hysteresis often occurs without degradation (like on your harddisk). and degradation often occurs with hysteresis.
As I was saying: term "hysteresis" is not used to describe permanent fatigue or degradation of a material. The Wikipedia article specifically talks about "immediate history", and the new link you posted likewise gives correct examples of hysteresis, none of which involve fatigue or degradation. Shape memory alloys exhibit hysteresis and they also exhibit fatigue; the two are two distinct effects.
Hope this helps!
No, that's not what "hysteresis" means. Hysteresis means that their behavior depends on their immediate history (meaning, one or two contractions earlier). Long term degradation is called something else, depending on the cause and behavior (e.g., "fatigue").
If you want to know more about it, just go to the next X.org developer's conference.
:)
I know the history of X11 well, having used the X Window System since its X10 days.
unfortunately, you'll also find that the term X11 effectively refers to one shared codebase
If X.org seriously starts treating X11 like a codebase rather than a protocol, that's the end of the X11 window system. With its network transparency already effectively broken by both Gnome and KDE, it would really open the floodgates to mutually incompatible direct-to-display graphics systems.
when someone says "hey, there is a problem with X11", they are almost certainly, without knowing anything about it, referring to a single codebase that has the problem.
Yes, and that's why it's important to correct them because if X11 and X.org become identified, the aspects of X11 that have allowed it to survive several generations of Macintosh and Windows and still be relevant will be lost.
Apple should do something that you consider common-sensical THEREFORE they have a hidden agenda.
No, I'm not saying that Apple "should do" something, I'm saying that they "should be" considered published copyrighted materials because the alternatives don't make any sense (trade secret, etc.).
Now, why am I arguing that Apple has a hidden agenda? It's because they are taking this extraordinary step of treating service manuals like trade secrets.
Apple clearly has a policy that to hassle people who "steal" their IP.
Yeah, and now think about why that policy exist. It's not decided on randomly, you know.
He does not have the discretion to say "Oh, I should give them a pass, that's probably fair use."
He better have, because Apple's legal fees could get pretty high if they pursue copyright infringement cases where there are none.
You've obviously never worked in any private organization bigger than a little league team.
You're obviously prone to incorrect overgeneralizations.
Yeah, you can recompile, if you have the time and patience. You can even use Fink or DarwinPorts, which requires less time and patience, but not much.
In the end, even with lots of time and patience, you still only get a small fraction of the software that comes standard with a Linux desktop distribution, and it ends up working nowhere near as well, among other things, because Apple's X11 implementation isn't very good. And even to the degree that it does work, OS X applications won't interoperate well with X11 applications.
Running UNIX and Linux apps on OS X is a stop-gap measure, it's not something you want to do day-to-day. I've tried, and in the end, I erased all Linux ports from my Mac--I'd prefer many of them to their Mac equivalents, but they just don't work well enough under OS X to use regularly.
The kernel isn't the problem (technically, it's Mach, not BSD, but close enough).
The problem is software installation: Fink and DarwinPorts are slow, require lots of disk space, only cover a fraction of the packages from any standard Linux distribution, and often don't work at all.
When you get software installed, any kind of Linux GUI software tends to work poorly: Apple's X11 server is slow, and integration between X11 and OS X is poor (not even keymaps work properly). Even when people try hard (like the OpenOffice port), integration doesn't work well.
OS X is not a drop-in replacement for a UNIX workstation or a Linux desktop. It's something that will run many UNIX and Linux apps in a pinch, but you'll be happier with OS X apps on OS X, because that's what's supported best.
Now, if you think you don't need all that Linux software, that's fine. However, take it from me: trying to replace all the software you might want to use that comes on SuSE, RedHat, or Ubuntu with OS X equivalents is expensive.
If you're buying an OS X laptop expecting to get a "better" UNIX system, as Apple likes to claim, you'll be disappointed--it just doesn't fulfill that promise. Well, you'll be disappointed unless you didn't want a UNIX system in the first place and just like the sound of it.