Of course, we're going to have the usual back and forth about how this isn't really breaking the speed of light, it's just the group velocity, etc. For those unfamiliar with the issue, the following links might help:
The thing that really seems interesting about this is that they're doing this with cheap equipment, which will make experimenting with this a lot easier.
Can anyone explain how this would be used to increase subluminal transmission of electrical signals, as mentioned in the article? This whole group velocity thing has always seemed like a bit of an illusion to me, and none of the explanations I've seen has really clarified how it's anything more than that.
I sympathize with your perspective, but I don't think it's as simple as you suggest. There are a whole host of factors that converge to make IP attractive to a wide audience.
One important factor is that many people saying "use IP" are really saying "use a standard, packet-switched protocol". There are some good reasons for doing this, too. But it just so happens that in today's world, only one protocol fits that bill. To demonstrate the impact of this issue, from your comment, I can't tell whether you think packet-switching in general is being overused, or just IP. The two have become virtually synonymous.
Technically, it's not that difficult to support replaceable network and transport layer protocols. Novell did it, a long time ago. That would allow more diversity in the choice of protocol. But the problem is standardization - everyone would have to agree on the infrastructure to support that. To summarize wildly, it was easier just to agree on a single network and transport layer protocol suite, than on a standard for making those protocols pluggable.
Having agreed on the standard, we're now stuck with a situation in which it tends to make sense to do anything that needs packet-switching, using IP. Even if it doesn't seem to always make technical sense, it often makes economic sense, because you can reuse existing technology, expertise, and infrastructure. Networks effects can be wonderful, but they're also tyrannical.
Any decent evidence. It does not have to be mathematical. That would be nice, but probably not possible at this stage.
Well, there are mathematical theories of objects, probably the most well-known of which is put forth by Abadi and Cardelli in A Theory of Objects. Read the prologue for an overview.
However, as that prologue points out, procedural and especially functional languages have much better formal underpinnings than do object languages. The functional languages in particular, examples being Scheme, Haskell, and ML, evolved from mathematical theories like lambda calculus and type theory, which makes them much more rigorous than less formally founded languages, and therefore, by some measures, "better".
The existence of mathematical theories of objects primarily serve to demonstrate the ways in which OO languages deviate from those theories. This is not surprising, since OOP was developed on a mostly ad-hoc basis. No single definition of what OOP is exists, and different languages implement OO in different ways.
To provide "decent evidence OOP is objectively better", you would first need to clearly define what you mean by OOP. You would also, as my original post asked, have to answer the question "better than what", or more specifically, "better than what, for what purpose". For example, it's easy enough to make an objective case that many object languages are more expressive, in general, than most purely procedural languages. By "expressive" I mean capable of expressing the same program both more concisely and understandably. It's also easy to make the case that in many situations - such as implementing algorithms involving functions on relatively simple data structures - that a purely procedural language is no less expressive than an OO language. So, as with Deep Thought's answer of 42, a lot depends on the definition of the question.
My own take on this, which is based on having researched, developed and sold a commercial OO language product back in the early '90s, is that OO contains some very good and important ideas, but that they're rather arbitrarily lumped together as though they all inherently belong together, although they don't necessarily. Part of this lumping often involves conflating otherwise unrelated ideas, which can lead to design strategies that aren't as clearly decomposed as they might otherwise be. Language limits thought, and the limitations of OO languages tend to limit the thought of those who treat a particular OO language or design methodology as The One True Way to design systems. It's a variation on the old "everything looks like a nail" syndrome.
One of the better ideas which OO adopts - but did not invent - is that of subtype polymorphism, which aside from its useful properties from a type theory perspective, is a big enabler of reusability in real-world code. However, OO languages regularly confuse types with implementations of those types, i.e. they don't set up a sufficiently clear or enforceable distinction between interface and implementation. With class inheritance in particular, these boundaries are blurred to the point of causing confusion in the minds of many OO advocates.
Given the arbitrary and varying collection of features that usually consitute OO, I would answer your question of "I wonder if other civilizations use OO?" by saying that other civilizations with sufficiently advanced programming languages would almost certainly use many of the concepts inherent in OO, but that they may be organized in different ways, and an OO "purist" (a rather outdated notion, with what we know about languages today) would possibly not be inclined to call those languages OO. For example, neither Haskell nor ML are OO languages, but both incorporate many features that would be considered part of OO by most OO practitioners. OCaml explicitly incorporates OO, but it is necessarily a little different than in most other OO languages, because OCaml is a functional language.
To summarize, OOP arose to address certain problems in the organization and reusability of code, and in doing so adopted some important ideas, such as subtype polymorphism. It's certainly possible to demonstrate that a language with subtype polymorphism is more expressive than one without, so an OO language would beat out, say, BASIC, FORTRAN, or C in this respect. In that sense, OO languages tend to represent a step forward from what went before, but it was something of an ad-hoc step.
I have no doubt that future languages will take what's been learned about OO's various features into account, but will integrate them in a more rigorous and well-factored way. This can already be seen happening in languages like Java, which is the first mainstream OO language to introduce an explicit notion of an "interface", thus correcting a limitation in many prior OO languages. These baby-step improvements in mainstream languages are about the best we can expect, since it takes a long time to communicate academic knowledge about programming languages into the commercial world, and a similarly long time for the academic world to sift out the actually useful (or simply un-ignorable) innovations from the commercial world.
That all said, I think it's dangerous to dismiss OO as being hype or whatever. That's why I asked "better than what". If you were trying defend pure C against OO, for example, then I think you have something yet to learn, not about OO necessarily, but about programming languages in general; but once again, it depends on the exact question.
Sorry for the essay; brevity and conciseness takes more effort.
These slashdotisms are really TV-generationisms, btw. A generation that's grown up learning to spell not by reading, but by listening to TV and guessing.
Comparing two CPUs running at X MHz, to a single CPU running at 2X MHz:
Most of the time, people aren't running huge number-crunching applications that max out the CPU for long periods of time. In such applications, assuming the application itself dos not take advantage of two CPUs (not many do), a single CPU running at 2X MHz would be twice as fast as a dual CPU running at X MHz.
However, a much more common situatuion is to max out the CPU for short periods - you're doing something for which you expect a response very soon. When this happens on a single CPU machine, the machine effectively becomes unusable - it has no CPU left over to do anything else. Sure, your OS is supposed to take care of timeslicing multiple tasks in a well-behaved way, and for the most part, it does, but nevertheless, when there's a task trying to use 100% of your CPU, you're going to know about it in terms of the responsiveness of your machine.
Unless, of course, you have two CPUs. Now, when some CPU-hogging task maxes out CPU #1, all that happens is your OS runs other tasks on CPU #2 - you effectively have a hardwired throttle that prevents any single app from slowing your machine to a crawl. Suddenly, the fact that most apps don't exploit dual CPUs is a positive advantage - it means your machine almost always has capacity to spare.
As a result, the dual CPU running at X MHz, other things being equal, will seem faster and more responsive overall than the single CPU running at 2X MHz. With most usage patterns, it is.
Besides, in the exceptional cases where you're using long-running intensive number-crunching apps, it's often possible to find a version which supports dual CPUs, thus eliminating any advantage which the single-CPU machine might have.
An analogy I've used for non-techies is to engines: think of a single-cylinder engine compared to a two-cylinder engine, each with the same overall capacity. Assuming you know anything about engines, which would you rather have in your car? It's not a perfect analogy technically, but it does communicate the flavor of the difference that dual CPUs makes.
The only solution that'll work in the real world, today, is to write worms that infect vulnerable machines and fix them.
In fact, Microsoft has already pre-infected their own new OS, Windows XP. Maybe those draconian EULAs (you hereby agree that "M$ 0wnz j00") aren't such a dumb idea after all...
Not that I like it, but the fact is that MS is targeting the sort of people we're worrying about, giving them what it thinks they need, whether they ask for it or want it, or not. We hate this because we're tech-savvy and want to control our machines, but for the average user, having someone else "0wn" their machine is probably, ultimately, a necessity. The question is just who's going to do the owning - virus writers and crackers, or Microsoft/Symantec etc.
Why do you think the aliens haven't contacted us yet? They were quite encouraged when they noticed we had begun communicating on a global
network. The enthusiasm faded once they began checking in on our most popular sites. (Although to the aliens' credit, they did steal the idea for Google from us.)
BTW, re your sig: "OOP is objectively better" than what? Happily, there's some objective, mathematical, prooflike evidence that functional programming is better, so I guess that debate is toast.;)
I don't think it's a "Mrs.", although I'm not up on my politically correct honorifics as applied to lesbians. That's not a slur - Ms. Rosen is a lesbian who, with her partner Elizabeth Birch, Director of the Human Rights Campaign ("working for lesbian, gay, bisexual and transgender equal rights"), adopted twins in 1999.
As a historical note, Novell has been in the OS business since way back. Back around 1985, Novell sold its own custom hardware - the Novell 68B file server used a Motorola 68000 processor and ran a Novell OS called S-Net. I think, but I'm not sure, that might have been before the name NetWare was used.
The 68000 file servers were needed in the days when PCs weren't quite powerful enough to serve large networks.
The selfish, spoiled Americans are the ones who immediately look to someone else to fix the problem and make it go away. In effect, they say "don't bother me with the details, I just want to carry on living as though the outside world doesn't exist". It is these people that result inevitably in the kind of government America now has: instituting senseless paranoid measures in order to make people *feel* safer, while at the same time trampling the values which America is supposed to represent, and not in fact succeeding in increasing security.
Think through what it is you're really scared of, and how these various measures actually address that. I suspect they'd do better to encourage every American to learn a martial art, than some of the nonsense that's been enacted.
Really, this has everything to do with courage. You've allowed yourself to be scared, and you're delegating responsibility for that, and for fixing it, to everyone but yourself. You're the only one who can fix it. I'm saddened that the terrorists have succeeded so well, when all it would take to beat them is to realize that all you have to do is think for yourself.
Safety and security will only come from each individual being more aware and involved in the world around them, not in hiding and hoping that by giving up your civil liberties to a big brother government, that they'll take care of everything for you. Don't criticize the people you accuse of whining: they're doing more for America's freedom and values - including freedom from fear - than any of the quivering masses.
I once read a story about "Freedom: I Won't", the idea that everyone has the basic right to say "I won't" when requested to do something by another, and that answer must be accepted.
...
The GPL violates my Freedom: I Won't: it tries to dictate to me.
That doesn't follow. You're saying that the GPL violates your freedom to steal someone else's code. Well yes, it does, in the same way that the law violates your freedom to murder people and steal their stuff. I'm glad the GPL exists, to protect us from people such as you.
Actually, "frog" is/was a British slur which Americans inherited. Afaik, there's no specifically American slur term for the French, other than e.g. "damn frenchies" (usually applied to people with Quebec license plates...)
The worst outage I've ever seen amongst my clients, on any OS, was when the Code Red virus infected entire networks, often including servers. It turns out that "keeping up with patches" with Microsoft is a recursive process, and servers can easily "regress" to an unpatched state. In more than one case I saw, servers had been fully patched, but later after some new software was installed, a service pack had to be reapplied, but this was done without reapplying all the security patches. Voila, a secure server regresses to insecure. Now, you can argue that "competent Windows administrators" would not do this, but in real life, all sorts of things happen which make perfection unrealistic. Part of a good security system is having multiple layers of security, so that if there's a lapse or break at one level, other levels prevent disaster. One of those levels is the level or reliability of the OS itself - and "reliability" is something that Windows has had great difficulty achieving.
Another example of ongoing Windows instability was the IIS 4 server on NT 4, which leaked memory something horrible when ASP was used, resulting in busy sites needing to restart services and/or reboot servers every few hours in order to keep websites running. For some time, Microsoft ran a private mailing list ("ASPPrivate", iirc) for users experiencing this problem - mostly large website customers. I'm not sure when this was fixed, if ever - I think that Win2K and IIS5 came out before the problem was ever fixed on IIS4, and Microsoft's strategy for addressing customer concerns was simply to stall for many months and then tell customers to upgrade their OS.
Anyone who tries to hold up Microsoft OSes as comparable to Linux, or any Unix variant, in terms of stability and reliability, probably has no experience of *nix, stability, or reliability.
Another issue, perhaps not as major, is uptime. Windows still requires reboots if you look at it funny - even 2000 and XP. At sites I deal with that have a mixed server population, I regularly see *nix servers with uptimes in the hundreds of days, where the Win servers are lucky to have a couple of months of uptime.
You're right in general, but in this case, what he's presumably trying to avoid are the software patent problems that have arisen in the U.S. I think it's fair to have come to the conclusion that "software patents as implemented in the U.S. are a bad idea", and therefore be looking for cogent arguments against them.
A separate question would be whether the general concept of software patents can be made to work, and what system might achieve that, but presumably designing a new kind of software patent system is not what's being asked for here.
I would say that when Grandma Newbie decides to try her hand at building and hosting her website, she would be much better off with WebSTAR than almost anything else. It's not a server that is easy to malign.
I don't have too much of a problem with this in general, although are you telling Grandma she can't have Mac OS X?
But another reason for my first response was that the original topic was the hacking of NBC - which ought to have more sophisticated IT resources than Grandma Newbie. My response assumed that the issue is not really how secure a server is "out of the box", since an organization like NBC ought to at least have enough knowledge to perform the most basic standard hardening steps. Even a Windows server can be made quite secure with very little effort - but it does take a bit of a priori knowledge. Actually, the biggest problem with Windows servers seems to be how easily they can be made insecure again - e.g. by reinstalling a service pack.
Ironically, it's quite likely that the weak point in the NBC incident was something other than a web server, anyway.
Re the degrading over time, I've been able to leave Motion running for a long weekend, without crashing, but by the end of that time it was completely missing motion that normally would definitely have triggered it. I can't swear that time degradation was the problem, but regular restarting does fix it.
In all, it's good software, really neat technology, but kinda picky and unstable.
Isn't that the definition of small open source projects?;) I've been meaning to take a look at the Motion source, out of curiosity, but so many projects, so little time...
I never knew how bad most BNC connectors were until I used them for video. It's really a miracle that 10Base2 networks ever worked at all. The slightest movement sends noise down the line.
{Shudder} - I'm having flashbacks to cabling offices with 10Base2, how flaky it could be, and people crawling all over looking for the cause of network degradation... Aha! It was the coil of cable over in the corner of Bob's office, acting as an antenna!
I found that Motion seems, over time, to get less good at actually detecting motion. I've been assuming its averaging of prior frames gets messed up. I have it restarting every four hours for that reason.
The Axis cam is nice in that it avoids capture cards, you can use CAT5 to the camera, and the camera has its own web server. The downside is that the camera is more expensive (I paid about $280).
We have IP webcams at work too, big fucking deal - Axis webcams only cost about $300 and they have a built-in webserver running Linux!
The Axis cams are cool - I use one at home, along with Motion software for motion detection, so I get mpegs of the activity in front of the cam, which can be accessed over the net when I'm away from home.
I love Jedit. It's written in Java. Therefore it is possible to write great, usable, lovable software in java.
This is tangential to the points of mine which you originally responded to, and to the argument I've been making. I was talking about consumer software. Perhaps you're saying that by extension from your experience, that in future, more consumer software will use Java/Swing, and that JEdit is proof that it is possible, even if it hasn't happened yet. However, I'm talking about what's real now, not what might be possible in future. In fact, the way I started this whole thread was by pointing out that Java's lack of success with GUI client software historically was of Sun and Netscape's own making, not due to Microsoft.
If somebody rewrote jedit in C or Delphi I might switch but I doubt it because It is probably not possible to write such an application in a static language.
Of course it's possible. All you need is a decent component model, many of which are available - e.g. Bonobo, XPCOM, COM, CCM, VCL.
I agree that Java has benefits in terms of portability. But there's also been a cost, historically, which persists in various ways today, for developing portable user interfaces. Such interfaces tend not to be 100% competitive with native interfaces, except in cases where the native interface itself is poor. Developers tend to be willing to make compromises in this area, as a trade off against other benefits. Consumers don't have the same requirements - most don't use multiple OSes, for example. Given competing GUI apps implemented in Java vs. some other language, there's a good chance today that the Java app won't be picked, for the reasons I'm talking about.
The situation has improved dramatically over the past few years, and continues to improve. Nevertheless, there are still issues today, and the fact that you love JEdit and Java in general doesn't change that. You're not representative of the consumer market.
Hemos didn't stand a chance: there were two links in the first sentence, one for a cool product he already knew about (available from Thinkgeek), and another link to its brand-new successor. The rest of the text could have been a treatise on the wonderful privacy features of Window XP, and it would have gotten through unedited.
The "Oooh shiny!" phenomenon (aka ADD) strikes again...
Are you saying that programmers are not consumers? If so that's a silly distinction to make.
In the right hand column of the table on this page, it lists some of the common characteristics of "consumer software". These corresponds to a commonly accepted definition. I'm saying I don't see many Swing apps that fit this category. Certainly, JBuilder and Zend do not.
If you don't understand why JBuilder is not a good example, you're not trying very hard. JBuilder is written for Java programmers, who actively benefit from having an IDE written in Java.
Your point seems to be that java/swing is not suitable to GUI development becasue somebody did not write an application you like.
I'm saying that when compared to Windows GUIs, I see deficiencies, and I'm suggesting that the lack of market acceptance is in part due to those deficiencies.
You allude to deficiencies yourself: "If somebody else re-wrote it in C or Delphi or whatever I would maybe switch." Why would you switch, if Swing is really so competitive?
All those plug ins are possible because java is a dynamic and reflective language.
I'm not disputing that. I'm saying that Swing leaves something to be desired as a system for ordinary programmers to produce high-quality user interfaces, and that the market bears this assertion out.
I use JEdit every day and it's my favorite text editor.
So in other words you're saying that because you like it, there can't be anything wrong with Swing? While at the same time suggesting that you might switch if someone converted JEdit to something other than Java. Why don't you get back to me when you've worked out your inner conflict...;oP
http://scienceworld.wolfram.com/physics/Superlumin al.html
http://www.weburbia.com/physics/FTL.html
http://physicsweb.org/article/world/13/9/3
The thing that really seems interesting about this is that they're doing this with cheap equipment, which will make experimenting with this a lot easier.
Can anyone explain how this would be used to increase subluminal transmission of electrical signals, as mentioned in the article? This whole group velocity thing has always seemed like a bit of an illusion to me, and none of the explanations I've seen has really clarified how it's anything more than that.
One important factor is that many people saying "use IP" are really saying "use a standard, packet-switched protocol". There are some good reasons for doing this, too. But it just so happens that in today's world, only one protocol fits that bill. To demonstrate the impact of this issue, from your comment, I can't tell whether you think packet-switching in general is being overused, or just IP. The two have become virtually synonymous.
Technically, it's not that difficult to support replaceable network and transport layer protocols. Novell did it, a long time ago. That would allow more diversity in the choice of protocol. But the problem is standardization - everyone would have to agree on the infrastructure to support that. To summarize wildly, it was easier just to agree on a single network and transport layer protocol suite, than on a standard for making those protocols pluggable.
Having agreed on the standard, we're now stuck with a situation in which it tends to make sense to do anything that needs packet-switching, using IP. Even if it doesn't seem to always make technical sense, it often makes economic sense, because you can reuse existing technology, expertise, and infrastructure. Networks effects can be wonderful, but they're also tyrannical.
Well, there are mathematical theories of objects, probably the most well-known of which is put forth by Abadi and Cardelli in A Theory of Objects. Read the prologue for an overview.
However, as that prologue points out, procedural and especially functional languages have much better formal underpinnings than do object languages. The functional languages in particular, examples being Scheme, Haskell, and ML, evolved from mathematical theories like lambda calculus and type theory, which makes them much more rigorous than less formally founded languages, and therefore, by some measures, "better".
The existence of mathematical theories of objects primarily serve to demonstrate the ways in which OO languages deviate from those theories. This is not surprising, since OOP was developed on a mostly ad-hoc basis. No single definition of what OOP is exists, and different languages implement OO in different ways.
To provide "decent evidence OOP is objectively better", you would first need to clearly define what you mean by OOP. You would also, as my original post asked, have to answer the question "better than what", or more specifically, "better than what, for what purpose". For example, it's easy enough to make an objective case that many object languages are more expressive, in general, than most purely procedural languages. By "expressive" I mean capable of expressing the same program both more concisely and understandably. It's also easy to make the case that in many situations - such as implementing algorithms involving functions on relatively simple data structures - that a purely procedural language is no less expressive than an OO language. So, as with Deep Thought's answer of 42, a lot depends on the definition of the question.
My own take on this, which is based on having researched, developed and sold a commercial OO language product back in the early '90s, is that OO contains some very good and important ideas, but that they're rather arbitrarily lumped together as though they all inherently belong together, although they don't necessarily. Part of this lumping often involves conflating otherwise unrelated ideas, which can lead to design strategies that aren't as clearly decomposed as they might otherwise be. Language limits thought, and the limitations of OO languages tend to limit the thought of those who treat a particular OO language or design methodology as The One True Way to design systems. It's a variation on the old "everything looks like a nail" syndrome.
One of the better ideas which OO adopts - but did not invent - is that of subtype polymorphism, which aside from its useful properties from a type theory perspective, is a big enabler of reusability in real-world code. However, OO languages regularly confuse types with implementations of those types, i.e. they don't set up a sufficiently clear or enforceable distinction between interface and implementation. With class inheritance in particular, these boundaries are blurred to the point of causing confusion in the minds of many OO advocates.
Given the arbitrary and varying collection of features that usually consitute OO, I would answer your question of "I wonder if other civilizations use OO?" by saying that other civilizations with sufficiently advanced programming languages would almost certainly use many of the concepts inherent in OO, but that they may be organized in different ways, and an OO "purist" (a rather outdated notion, with what we know about languages today) would possibly not be inclined to call those languages OO. For example, neither Haskell nor ML are OO languages, but both incorporate many features that would be considered part of OO by most OO practitioners. OCaml explicitly incorporates OO, but it is necessarily a little different than in most other OO languages, because OCaml is a functional language.
To summarize, OOP arose to address certain problems in the organization and reusability of code, and in doing so adopted some important ideas, such as subtype polymorphism. It's certainly possible to demonstrate that a language with subtype polymorphism is more expressive than one without, so an OO language would beat out, say, BASIC, FORTRAN, or C in this respect. In that sense, OO languages tend to represent a step forward from what went before, but it was something of an ad-hoc step.
I have no doubt that future languages will take what's been learned about OO's various features into account, but will integrate them in a more rigorous and well-factored way. This can already be seen happening in languages like Java, which is the first mainstream OO language to introduce an explicit notion of an "interface", thus correcting a limitation in many prior OO languages. These baby-step improvements in mainstream languages are about the best we can expect, since it takes a long time to communicate academic knowledge about programming languages into the commercial world, and a similarly long time for the academic world to sift out the actually useful (or simply un-ignorable) innovations from the commercial world.
That all said, I think it's dangerous to dismiss OO as being hype or whatever. That's why I asked "better than what". If you were trying defend pure C against OO, for example, then I think you have something yet to learn, not about OO necessarily, but about programming languages in general; but once again, it depends on the exact question.
Sorry for the essay; brevity and conciseness takes more effort.
These slashdotisms are really TV-generationisms, btw. A generation that's grown up learning to spell not by reading, but by listening to TV and guessing.
Most of the time, people aren't running huge number-crunching applications that max out the CPU for long periods of time. In such applications, assuming the application itself dos not take advantage of two CPUs (not many do), a single CPU running at 2X MHz would be twice as fast as a dual CPU running at X MHz.
However, a much more common situatuion is to max out the CPU for short periods - you're doing something for which you expect a response very soon. When this happens on a single CPU machine, the machine effectively becomes unusable - it has no CPU left over to do anything else. Sure, your OS is supposed to take care of timeslicing multiple tasks in a well-behaved way, and for the most part, it does, but nevertheless, when there's a task trying to use 100% of your CPU, you're going to know about it in terms of the responsiveness of your machine.
Unless, of course, you have two CPUs. Now, when some CPU-hogging task maxes out CPU #1, all that happens is your OS runs other tasks on CPU #2 - you effectively have a hardwired throttle that prevents any single app from slowing your machine to a crawl. Suddenly, the fact that most apps don't exploit dual CPUs is a positive advantage - it means your machine almost always has capacity to spare.
As a result, the dual CPU running at X MHz, other things being equal, will seem faster and more responsive overall than the single CPU running at 2X MHz. With most usage patterns, it is.
Besides, in the exceptional cases where you're using long-running intensive number-crunching apps, it's often possible to find a version which supports dual CPUs, thus eliminating any advantage which the single-CPU machine might have.
An analogy I've used for non-techies is to engines: think of a single-cylinder engine compared to a two-cylinder engine, each with the same overall capacity. Assuming you know anything about engines, which would you rather have in your car? It's not a perfect analogy technically, but it does communicate the flavor of the difference that dual CPUs makes.
In fact, Microsoft has already pre-infected their own new OS, Windows XP. Maybe those draconian EULAs (you hereby agree that "M$ 0wnz j00") aren't such a dumb idea after all...
Not that I like it, but the fact is that MS is targeting the sort of people we're worrying about, giving them what it thinks they need, whether they ask for it or want it, or not. We hate this because we're tech-savvy and want to control our machines, but for the average user, having someone else "0wn" their machine is probably, ultimately, a necessity. The question is just who's going to do the owning - virus writers and crackers, or Microsoft/Symantec etc.
BTW, re your sig: "OOP is objectively better" than what? Happily, there's some objective, mathematical, prooflike evidence that functional programming is better, so I guess that debate is toast. ;)
I don't think it's a "Mrs.", although I'm not up on my politically correct honorifics as applied to lesbians. That's not a slur - Ms. Rosen is a lesbian who, with her partner Elizabeth Birch, Director of the Human Rights Campaign ("working for lesbian, gay, bisexual and transgender equal rights"), adopted twins in 1999.
The 68000 file servers were needed in the days when PCs weren't quite powerful enough to serve large networks.
Think through what it is you're really scared of, and how these various measures actually address that. I suspect they'd do better to encourage every American to learn a martial art, than some of the nonsense that's been enacted.
Really, this has everything to do with courage. You've allowed yourself to be scared, and you're delegating responsibility for that, and for fixing it, to everyone but yourself. You're the only one who can fix it. I'm saddened that the terrorists have succeeded so well, when all it would take to beat them is to realize that all you have to do is think for yourself.
Safety and security will only come from each individual being more aware and involved in the world around them, not in hiding and hoping that by giving up your civil liberties to a big brother government, that they'll take care of everything for you. Don't criticize the people you accuse of whining: they're doing more for America's freedom and values - including freedom from fear - than any of the quivering masses.
Sorry you've been scared so much, but as a solution, I highly recommend trying to grow a spine!
That doesn't follow. You're saying that the GPL violates your freedom to steal someone else's code. Well yes, it does, in the same way that the law violates your freedom to murder people and steal their stuff. I'm glad the GPL exists, to protect us from people such as you.
The smallest site I heard of this problem happening with was getting over 300,000 hits/day.
Actually, "frog" is/was a British slur which Americans inherited. Afaik, there's no specifically American slur term for the French, other than e.g. "damn frenchies" (usually applied to people with Quebec license plates...)
Another example of ongoing Windows instability was the IIS 4 server on NT 4, which leaked memory something horrible when ASP was used, resulting in busy sites needing to restart services and/or reboot servers every few hours in order to keep websites running. For some time, Microsoft ran a private mailing list ("ASPPrivate", iirc) for users experiencing this problem - mostly large website customers. I'm not sure when this was fixed, if ever - I think that Win2K and IIS5 came out before the problem was ever fixed on IIS4, and Microsoft's strategy for addressing customer concerns was simply to stall for many months and then tell customers to upgrade their OS.
Anyone who tries to hold up Microsoft OSes as comparable to Linux, or any Unix variant, in terms of stability and reliability, probably has no experience of *nix, stability, or reliability.
Another issue, perhaps not as major, is uptime. Windows still requires reboots if you look at it funny - even 2000 and XP. At sites I deal with that have a mixed server population, I regularly see *nix servers with uptimes in the hundreds of days, where the Win servers are lucky to have a couple of months of uptime.
A separate question would be whether the general concept of software patents can be made to work, and what system might achieve that, but presumably designing a new kind of software patent system is not what's being asked for here.
I don't have too much of a problem with this in general, although are you telling Grandma she can't have Mac OS X?
But another reason for my first response was that the original topic was the hacking of NBC - which ought to have more sophisticated IT resources than Grandma Newbie. My response assumed that the issue is not really how secure a server is "out of the box", since an organization like NBC ought to at least have enough knowledge to perform the most basic standard hardening steps. Even a Windows server can be made quite secure with very little effort - but it does take a bit of a priori knowledge. Actually, the biggest problem with Windows servers seems to be how easily they can be made insecure again - e.g. by reinstalling a service pack.
Ironically, it's quite likely that the weak point in the NBC incident was something other than a web server, anyway.
In all, it's good software, really neat technology, but kinda picky and unstable.
Isn't that the definition of small open source projects? ;) I've been meaning to take a look at the Motion source, out of curiosity, but so many projects, so little time...
I never knew how bad most BNC connectors were until I used them for video. It's really a miracle that 10Base2 networks ever worked at all. The slightest movement sends noise down the line.
{Shudder} - I'm having flashbacks to cabling offices with 10Base2, how flaky it could be, and people crawling all over looking for the cause of network degradation... Aha! It was the coil of cable over in the corner of Bob's office, acting as an antenna!
The Axis cam is nice in that it avoids capture cards, you can use CAT5 to the camera, and the camera has its own web server. The downside is that the camera is more expensive (I paid about $280).
The Axis cams are cool - I use one at home, along with Motion software for motion detection, so I get mpegs of the activity in front of the cam, which can be accessed over the net when I'm away from home.
I guess that makes me a gadget guru... ;o)
This is tangential to the points of mine which you originally responded to, and to the argument I've been making. I was talking about consumer software. Perhaps you're saying that by extension from your experience, that in future, more consumer software will use Java/Swing, and that JEdit is proof that it is possible, even if it hasn't happened yet. However, I'm talking about what's real now, not what might be possible in future. In fact, the way I started this whole thread was by pointing out that Java's lack of success with GUI client software historically was of Sun and Netscape's own making, not due to Microsoft.
If somebody rewrote jedit in C or Delphi I might switch but I doubt it because It is probably not possible to write such an application in a static language.
Of course it's possible. All you need is a decent component model, many of which are available - e.g. Bonobo, XPCOM, COM, CCM, VCL.
I agree that Java has benefits in terms of portability. But there's also been a cost, historically, which persists in various ways today, for developing portable user interfaces. Such interfaces tend not to be 100% competitive with native interfaces, except in cases where the native interface itself is poor. Developers tend to be willing to make compromises in this area, as a trade off against other benefits. Consumers don't have the same requirements - most don't use multiple OSes, for example. Given competing GUI apps implemented in Java vs. some other language, there's a good chance today that the Java app won't be picked, for the reasons I'm talking about.
The situation has improved dramatically over the past few years, and continues to improve. Nevertheless, there are still issues today, and the fact that you love JEdit and Java in general doesn't change that. You're not representative of the consumer market.
The "Oooh shiny!" phenomenon (aka ADD) strikes again...
...only $19.95! Not available in stores!
Canonical example of karma whoring!
In the right hand column of the table on this page, it lists some of the common characteristics of "consumer software". These corresponds to a commonly accepted definition. I'm saying I don't see many Swing apps that fit this category. Certainly, JBuilder and Zend do not.
If you don't understand why JBuilder is not a good example, you're not trying very hard. JBuilder is written for Java programmers, who actively benefit from having an IDE written in Java.
Your point seems to be that java/swing is not suitable to GUI development becasue somebody did not write an application you like.
I'm saying that when compared to Windows GUIs, I see deficiencies, and I'm suggesting that the lack of market acceptance is in part due to those deficiencies.
You allude to deficiencies yourself: "If somebody else re-wrote it in C or Delphi or whatever I would maybe switch." Why would you switch, if Swing is really so competitive?
All those plug ins are possible because java is a dynamic and reflective language.
I'm not disputing that. I'm saying that Swing leaves something to be desired as a system for ordinary programmers to produce high-quality user interfaces, and that the market bears this assertion out.
I use JEdit every day and it's my favorite text editor.
So in other words you're saying that because you like it, there can't be anything wrong with Swing? While at the same time suggesting that you might switch if someone converted JEdit to something other than Java. Why don't you get back to me when you've worked out your inner conflict... ;oP