What's wrong with running the Linux version of software? You've got to drop Windows-think; we're not playing Microsoft's game here. It's not zero-sum. Linux is not BSD's enemy. To a large extent, a gain for one is a gain for all the free OSes.
Are companies like Yahoo going to move from FreeBSD to Linux just because the latter has more native apps? I doubt it. FreeBSD has a secure niche in the server market, and neither it nor the other BSD's show any signs of resting on their laurels. Let Linux claim the desktop--if it can do so before the whole concept of the desktop PC becomes an anachronism. BSD will still be there, humming away in the infrastructure.
OS/2 comparisons are meaningless. BSD doesn't have the full force of Microsoft seeding FUD about its emulation and actively trying to change ABI's from under it. BSD isn't charging developers a premium to develop for its platform. BSD can't hang ISV's out to dry like IBM did. Review your OS history: Windows emulation didn't kill OS/2--IBM did. It was a textbook case of a mainframe vendor making all the wrong moves for the desktop market despite their superior product.
Here's a thought experiment: if IBM had put the sourecode for OS/2 under the BSDL (before MS managed to squirm the Windows ABI out from under it), don't you think Windows would have been booted to also-ran status by other OS vendors, each building on the OS/2 code base and competing to be the best "better than Windows" OS? Free software has a wholly different dynamic than the commercial software world. It doesn't depend upon the welfare of a single corporate division for its continued existance.
As for this "negative effect of emulation," I fail to see any, unless you take the "Linux Uber Ales" contingent too seriously. Serious Linux folks are embarassed by those guys; I've seen little other than respect for BSD among the linux-kernel group, for instance, just as I see more and more respect for Linux among the BSD core team. (I subscribe to both of their mailing lists.) BSD is growing. Make it easier for those folks entranced by the Linux hoopla to try BSD, and it will grow even faster. Try to divide the BSD and Linux worlds too strongly, and you'll only hurt both. Emulation is an unmitigated Good Thing, since it helps put BSD on an equal footing with the media's darling Penguin without making alternative (read: non-MS) OSes more forbiding for vendors through unnecessary fragmentation.
At the time, Western Electric was the manufacturing arm of the Bell System (i.e. AT&T). So when Bell Labs wanted to distribute Unix, they did it through Western Electric. That's just how things worked in those pre-divestiture days.
Once again, I'm not talking about scripting. Scripting allows you to add new functionality, but it is quite limited as a way of increasing the richness of possible interactions with the desktop itself.
Let me give you a limited example of what I'm talking about, drawn from the world of signal-processing block languages. Suppose I want to represent my earlier example in a graphical way:
fgrep -f file1 file2 > file3
Now, suppose that the fgrep icon had little arrowheads on each side, one pointing in, the other pointing out. And it had a small rectangle along the bottom with the same "look" as the arrowheads. The arrowheads and rectangle represent input, output, and control, respectively.
Now, either by dragging or drawing a line, I connect file1 to the control rectangle. Then I connect file2 to the input arrow, and finally file3 to the output arrow. Finally, I click on the center of the fgrep icon (or hit a key, or otherwise signal GO). I've just used fgrep to apply the string list in file1 to file2 and put the result in file3.
This is pretty clunky as it stands (I'd much prefer typing), but consider how easy it is to extend. For example, draw a circle around some file icons and connect them all up instead of file2. Have the desktop create file3 automagically, to be named or anonymously reprocessed later. Link other processing elements in. And so on.
OK, now think of creating your own processing-block icons from combinations of other blocks, or from scripts, templates, or various tools. Use inheritance and polymorphism to leverage existing blocks. Add other routing elements, represented by new sub-icons (like the arrowheads). Associate other programming semantics (e.g. looping, branching) with other drawing actions and icons.
All this stuff has been done already within applications and simulation environments--literally decades ago. Microsoft has been so oblivious in this area that they took a term of art--Visual Programming and rendered it utterly meaningless with "visual" languages which were anything but. As a result, they've left the world of graphical desktop development at a stage that doesn't tax the cognitive development of a slightly slow 2-year-old.
KDE is shifting towards allowing components to be scripted together, giving pretty much what you asked for.
No, that's not really related. I can do all the scripting I want in TK/TCL already. If the desktop/WM helps in that, so much the better. But I can't even do simple combinations of files and processing like:
fgrep -f file1 file2 > file3
by using just the GUI. This, even though the idea of graphical metaphors for such things has existed for close to 30 years! And it's existed in ways (e.g. Tom's "connect the dots") that are intuitive even to children.
There are a number of applications that include such functionality, from database design tools, CAD systems, and CASE tools, to children's games. Why are desktop designers so focused on becoming a better MS Windows that they ignore just how antiquated the model is they are following? Trying to "fix" things with scripting is simply combining the worst of the textual and graphical worlds. It's a dead end.
It's not just Unix users that are affected by this limited vision, but they are the ones most likely to be familiar with the pipes-and-filters methods that MS WIndows-like desktops are simply incapible of utilizing. So they're more keenly aware of What's Missing.
The fact is, the emerging free-software desktops might look better than MS Windows, be more configurable than MS Windows, and work better than MS Windows, but they don't break any new ground. Drag'n'drop gives no more functionality than the DOS 1.0 command line: feed filename A to application B. Component models make programming easier, but in themselves do nothing to improve desktop functionality. The fact that it is impossible to use the desktop to order a seqeunce of operations on one or more objects--something that should be absolutely basic--shows just how limited the desktop metaphor remains.
I'm sure some folks will say "just use a CLI," and that's certainly what I'd do. But there are natural ways to make a GUI do the same sort of thing, such as what Tom suggested in his question--from drag'n'drop to connect-the-dots. And this would just be the beginning of using hugely intuitive visual metaphors to allow everybody to do the things that only ksh/bash gurus can do now.
It's just a crying shame that the KDE folks are relegating themselves to improving the same tired and limited conceptual framework that MS Windows inhabits.
Free software has craftsmen a-plenty, and good ones. But where are the visionaries?
how many bugs have you noted in redhat that you've reported or fixed.
Only a few. For instance, when the X server on the Alpha would only work at 8 bits, I submitted a bug report. No response. So I wrote again, including the ticket number of the original bug report. Still no response. I downloaded the sources to XFree86, and rebuilt the whole tree. The server misrendered at 16 bits and beyond, so I tinkered with compiler optimizations and got it working correctly. Then I actually sent back a note to RedHat saying what I'd done. I also posted it to the "axp-list@redhat.com" (where by this time several people were complaining of the same problem). Other folks on the list found solutions as well.
Their server still didn't work a depths greater than 8 bits when they made their next release some months later. I've no idea if anyone ever even read my report and subsequent messages beyond noting that they were for Alpha and not Intel. I often get the feeling that they don't even read their own Alpha mailing list "axp-list".
Yet I've been impressed with their Intel distributions for both support and quality. And all the other things they've done for Linux are massively positive. More than any other business entity, they are responsible for Linux's ascendancy. That's why, despite problems like I described above, they get my support.
When I said "potshots" that's pretty much what I meant. The nice thing about the better technical lists, like Linux-kernel, is that partisan comments are passed over quietly, or quickly dismissed. So "discussions" is the wrong word. Anything related to a particular distro gets chased off the list pretty quickly, in any case, as being off-topic.
The "wrong direction" discussions tend to occur on other lists--Redhat-devel-list is one. They tend to be concerned with support or with particular bugs, and how awful it is that RedHat "just didn't care enough to send their very best" or "never responded to my bug report." One of the lists I follow pretty closely (because I have an Alpha) is the "axp-list" (AXP==Alpha). RedHat gets criticized pretty regularly for lack of support and quality in their Alpha releases. A lot of the criticsm is justified, too, IMHO.
But like I said, much of this is normal. Those of us who use RedHat products not only want them to Get It Right, we're at the least inconvenienced when they Get It Wrong. I must not have made that clear--my only complaint was at unsupported FUD, which does occasionally appear on technical lists. But when RedHat does something like ship a distro where the "man" command dumps core immediately (like the 5.1 release for Alpha), bring on the criticism...
...you can search the net and find a million places that endorse redhat (and I'm not talking about companies, but individuals) and talk about how much they do for the free software community, but the only place that I've really seen that *slams* redhat and calls them all of the filthy names that we tag onto companies we don't like is here on slashdot...
It's not just Slashdot. Ever since the IPO I've seen random potshots at RedHat as "The Next MicroSoft" on several technical mailing lists, including Linux-Kernel. Anti-RedHat sentiment isn't that rare among hackers. And though it's often seen as sour grapes, anti-capitalism, or whatever, I think that the dissatisfaction comes from another place. Hackers tend to be perfectionists when it comes to things they care about. I don't mean to over-generalize, here, but IMHO this is one of the reasons why open-source software works so well. Yet RedHat is far from perfect. No sucessful company is--there are far too many necessary compromises between the ideal and bringing a product to market in a timely way. The good is often the enemy of the best, and frequently its conqueror. So disagreement and dissatisfaction is inevitable--even people who are well aware of "the real world" issues will disagree on what compromises are necssary: how important time-to-market is, whether a bug is a major flaw or minor irritant,and so on. So even though I agree 100% that RedHat is, overall, a Good Thing, it's also important that we make ourselves heard when we think they are headed in the wrong direction. What we need to be careful about is not generating our own Linux-flavored FUD in the process. Vague fears and unfounded suspicions are better left unsaid. They won't help Linux or free software any more than they'll help RedHat. Well-founded criticism is fine, FUD is not.
This all boils down to one question: Can you run an httpd on an NT Workstation box using none of the NT Server code implemented by Microsoft that you did not pay to license?
In a word, yes. That is, until Microsoft redefined (both technically and legally) after the fact just what was and wasn't "server code."
I was around when this whole thing happened, working as chief software engineer for a startup (NetCount) doing server-based statistics collection. Having only one server (instead of four) to deal with on NT would have made our lives a lot easier. But just because it would have benefited us didn't make it right. The O'Reilly piece is spot-on. MS changed the rules and cut its competition off at the knees...
have used every monitor/input switching device on the market, and they all show artifacts to some extent.
I went for years with 2 or 3 monitors of various sizes and qualities because of the blurring and other artifacts I saw with switches. Things have changed over the last couple of years. The switches I saw at customers/employers didn't seem suited for much beyond VGA. That's not true, now.
Things have changed, thanks to high-bandwidth VLSI video switching chips. Even my (relatively) cheap LinkSys lets me put up three side-by-side 80x80 Xterms with room left over (at 1600x1200x75Hz). There is a very slight blurring compared to connecting the monitor cable directly to the computer, but I get the same amount of blur just adding the monitor extension cable without the switch. There are no stripes, bands, ghosts, or other artifacts (beyond what I see from the video card itself--I've yet to see perfection in PC-class video cards, and in fact can see plenty of differences between cards through the switch). From what I've seen, other switches of recent design do as well (though pricier ones get you on-screen display and other niceties).
If you are doing production graphics (and you've spent >$3000 on a calibrated monitor and >$500 on a pro-grade video card) you shouldn't be playing around with switches in any case. But otherwise I think you've exaggerated the difference a switch makes. Cables make a much bigger difference, in my experience.
I have a 4-port LinkSys switch I picked up at Fry's 1-1/2 years ago for $180. Even at 1600x1200 blurring is minimal; the trick was to get high-quality video cables (remember that you're doubling the length of cable and number of connectors, so proper impedance and low capacitance are a must). Some of my systems have PS/2-style keyboard and mouse connectors, others have old-style 5-pin DIN/9-pin D-style connectors. It handles both just fine. The only problem I have is that hot-keys don't work. Since it sits right beside my monitor that isn't a problem. Not using hot-keys might explain why I've never had caps-lock/num-lock/scroll-lock problems folks are reporting for the Belkin's. Or maybe it just works. In any case, it's close to the best $180 I've spent.
L.A. is actually where the majority of special-effects producers for the motion picture industry exist. Think about it for a second--where are the studio headquarters located? Where would you expect post-production facilities to be located? Even after location shooting in some cheaper place like Canada or Florida (no slam intende to either place--it's expensive to shoot in LA), the studios like to bring things back to L.A. for post-production. It's a fact of life, however sad that might be for you. There are areas of Culver City, Burbank, and (yes) Hollywood with block after block of such companies, including literally dozens of digital effects houses.
Pixar and ILM are the exceptions (though still on the Left Coast), along with the Video producers in NYC. But if you want to do motion pictures, I'm afraid that L.A. is still the place, much as the above AC may try to deny it.
It's a heck of a lot easier to set up extemporaneous networks, write encryption and steganographic software, and raise general havoc with *nix than with Windows or Macs. Try creating a neighborhood network with serial ports and slash wire using MSWindows or MacOS...
The powers-that-be may live to regret adopting Linux (if indeed they have, and this isn't just ZDNET's overeager newsmongering). It will ultimately prove far more corrosive to entrenched power than Billy's Mandarin-speaking dancing paperclips ever would have been.
Welcome to the real world. Innovators are rarely popularizers. Bowie is no pioneer, I agree 100%. But there's more to him than that.
There is an interesting quote by the 20th Century "classical" composer, Igor Stravinsky:
The merely good composer borrows; the great composer steals.
(Don't shoot me if I'm not word-for-word accurate--the above is at least the general idea.) Bowie is pretty up-front about the fact that he borrows/steals from numerious influences. The question is, does he merely mimic his sources ("borrow") or does he make them his own ("steal"), improving them and weaving them into his music such that they are a seamless part of it?
I think he's done both. Some of his stuff is merely derivative, posed in a sort of trendier-than-thou way. Yet he has the knack of taking genres that have become moribund (e.g., the Psychedelica that underpinned the Ziggy Stardust era) and injecting life into them by combining them with other genres in creative ways.
Your summary of electronic music history understates just how old electronic music technology is by about 20 years. Here is an excellent timeline with a lot of background info (though be warned that inventors are rarely the best practitioners in this realm-- Raymond Scott was a bit of an exception).
But I don't think the fact that Bowie was born long after electronic music was first created is particularly relevant. The point is what what kind of music did he make with it. I frankly prefer his music to much of Kraftwerk's, even though Kraftwerk undeniably preceded him by many years. And that's the bottom line: not how the music is made or even what the musician says--most musicians would be better off if they just shut up, Bowie included. The music itself is what truely matters. -Ed
(1) Creation and adoption of x10 window software (2) PCC, the portable C compiler (3) Berkeley networking
PCC was another product of Edition 7. The VAX C compiler in 32V (and the first VAX-based BSD's) was constructed using PCC.
Berkeley wasn't alone in adding networking to Unix (there were at least half a dozen different protocol stacks for Unix before TCP/IP saw the light of day). But they were contracted to implement the Big One: TCP/IP. A good thing, too, since the NCP stack (NCP was the ARPANET protocol prior to TCP/IP) for Unix was pretty buggy.
X's predecessor was W (developed, I believe, at Stanford). So C isn't the only product of alphabetic succession (its precursor was B-- Ken Thompson's BCPL derivative). I wonder why the Berlin folks haven't named their project "Y"? (Why not?)
Research Unix Edition 7 was released in 1978, and included:
The Bourne Shell, the first shell that was a programming language in its own right.
Environment variables (this was an OS enhancement, not just the shell features supporting it).
UUCP--the Unix/Unix Copy Program. This brought networking, email, and (a bit later) news to the masses. This feature literally changed the world.
File systems larger than 32MB. Unix was no longer a toy.
Lint, along with system sources that actually passed it (no more "register *p" for generic pointers everywhere). C was forever improved by this step, since many people learned to program in it from reading kernel sources (just like Linux programmers do today).
32V, the port to the VAX--this was the ancestor of 3.x and 4.x BSD. (The 2.x BSD's ran on PDP-11's, and for a time were developed in parallel.)
And so on...
This was the version that got Unix started at many Universities. It was also the last version of Research Unix to make it out of Bell Labs into general distribution for research and educational use. One can only wonder what we would have seen had AT&T not decided to squeeze money out of it, locking away further Research Editions.
We've duly noted that Yahoo runs on FreeBSD, and are considering switching.
They're doing no such thing. One of their co-founders (David Filo) said that a company starting out today might consider Linux instead of FreeBSD, since it has more momentum at the moment. But he went on to say that he was quite happy with FreeBSD, in part because of the large amount of onsite experience Yahoo has with it. Doesn't sound like they're changing any time soon.
What are the essential differences between FreeBSD and Linux?
FreeBSD has a somewhat simpler kernel interface, closer to the original Research Unix kernels than Linux. Linux tends to be closer to System V. The virtual memory systems and network stacks are quite different; IMHO the VM system in FreeBSD is better than Linux's (both in terms of capability and performance), and the TCP/IP stack seems to perform better when supporting HTTP service, though this in part depends upon whose benchmarks you believe. FreeBSD has fewer device drivers, though the ones it has tend to be solid (as are many, but hardly all, of Linux's). The Berkeley FFS seems much less prone to damage than Linux's EXT2 FS, though it can be slower in some cases. Recent Linuxes do SMP better than FreeBSD, and Linux threads actually work. Linux supports a lot more hardware platforms (although other porting efforts are underway, FreeBSD really only runs on Intel and Alpha). There are more applications--both free and commercial--for Linux.
(I could go on, but you get the idea.)
There is no clear "superior" OS. A lot of the controvery is over religious issues--the real answer is to choose the system that is best for a particular application.
The Internet has tremendous potential for expanding the world of recorded music. For many of us it already has--I've been exposed to an enourmous variety of interesting music that I'd never have heard listening to the radio or visiting the local music store. But I just can't see this sort of hyped-up second-tier release being any sort of trend.
Just about every musician or band has far more material that they'll ever be able to release on CD (or vinyl, for those with that particular fetish). I'm sure that some of their fans would be quite interested in hearing it, but only the most devoted will be willing to pay a significant amount for it. The average quality of for-the-web music available is already bad--even though there is quite a bit that is as good or better as more traditionally released stuff, there is an order of magnitude more that is dog-howling material. Who wants to sift through all that dreck to find the good stuff?
OK, now think of having to pay for the "privilege" of searching for the good stuff. Why, that's even worse than the usual situation at the music store, where you have to buy a CD with twelve tracks of which you only like three.
I just can't see anyone making money on this sort of thing.
Now, I like good karma just as much as anyone else, but come on, Score 5: Insightful? Jeeze, could you please use your moderator points on something more useful?
Those weren't moderation points. Those were votes.
...to be a better Microsoft. I get the feeling we've been spending too much time focused on "beating Windows--" Microsoft's market today--and not trying to figure out what their market will be three years from now. No matter how well we do--even if we're ten times better than Windows--we'll still be followers, not leaders.
We've got to get better at "the vision thing." The market for PC software is not where the next Big Thing is going to happen. Linus has talked about this, but I've been amazed how little most Linux folks have been listening: embedded, "personalized," application-specific systems are the future.
If you must look at Microsoft for trends, look at Windows CE, not Windows NT (and I don't mean just its use on Palmtops, where it's been pretty anemic). We've got a real chance to upend WinCE if we work at it, but I think a few too many of us are PC- and Web-focused.
So ask yourself, "what have I done to further the cause of pervasive Linux today?" Then shake hands with an EE, and take an OS where it has never gone before.
One of the elements of their system is its "patented cluster technology." I suspect that this is intended to address the need for rapid scalability--the Achilles' heel of many e-commerce systems. There is always a point where it is impossible to scale by simply adding boxes. (For some systems this occurs for any N>1, while most others stop scaling at a "few".) A nice trick if they've managed to solve this one... But a patent? They aren't going to get many takers in the open-source crowd with that kind of strategy. In fact, even if they've produced a wonderful system apart from this clustering technology, and somehow manage to GPL all but that one piece of it, I think most folks here would consider it tainted and stay far away.
BTW, there is also a fair amount of string copying in the benchmark.
Byte-manipulation isn't one of Alpha's strong points, especially if you're compiling with GCC. (One reason why using an Alpha as a web server is probably a waste of money.)
If you want a real idea of memory bandwidth, use a benchmark designed for the purpose, like STREAM. Or, even better, benchmark using the applications and data that are important to you.
In any case, it's irresponsible to post benchmark results without making the benchmark available. Show us the code! I strongly suspect that what you are measuring isn't memory bandwidth at all.
As for where the Internet was born, The Pentagon in Arlington, VA is technically the correct location, while the Implementation began in Cambridge, MA.
The papers which started it all were written at RAND in Santa Monica, CA (though the Pentagon paid for them). As for the birth of the ARPANET, which became the Internet--well, even though BBN (in Cambridge, MA) was contracted by (D)ARPA to build the hardware, the actual "first byte" was transmitted at UCLA, which last time I checked was in Los Angeles, CA.
The most popular Internet site is based in Santa Clara, CA. (AOL claims more visits, but a significant fraction of these aren't Internet-based). The major manufacturers of Internet infrastructure equipment are based in Silicon Valley, also in CA.
If being the center of Net VC and Net Companies doesn't make Silicon Valley the "center of the Internet," what would?
Slashdot Mirror
What's wrong with running the Linux version of software? You've got to drop Windows-think; we're not playing Microsoft's game here. It's not zero-sum. Linux is not BSD's enemy. To a large extent, a gain for one is a gain for all the free OSes.
Are companies like Yahoo going to move from FreeBSD to Linux just because the latter has more native apps? I doubt it. FreeBSD has a secure niche in the server market, and neither it nor the other BSD's show any signs of resting on their laurels. Let Linux claim the desktop--if it can do so before the whole concept of the desktop PC becomes an anachronism. BSD will still be there, humming away in the infrastructure.
OS/2 comparisons are meaningless. BSD doesn't have the full force of Microsoft seeding FUD about its emulation and actively trying to change ABI's from under it. BSD isn't charging developers a premium to develop for its platform. BSD can't hang ISV's out to dry like IBM did. Review your OS history: Windows emulation didn't kill OS/2--IBM did. It was a textbook case of a mainframe vendor making all the wrong moves for the desktop market despite their superior product.
Here's a thought experiment: if IBM had put the sourecode for OS/2 under the BSDL (before MS managed to squirm the Windows ABI out from under it), don't you think Windows would have been booted to also-ran status by other OS vendors, each building on the OS/2 code base and competing to be the best "better than Windows" OS? Free software has a wholly different dynamic than the commercial software world. It doesn't depend upon the welfare of a single corporate division for its continued existance.
As for this "negative effect of emulation," I fail to see any, unless you take the "Linux Uber Ales" contingent too seriously. Serious Linux folks are embarassed by those guys; I've seen little other than respect for BSD among the linux-kernel group, for instance, just as I see more and more respect for Linux among the BSD core team. (I subscribe to both of their mailing lists.) BSD is growing. Make it easier for those folks entranced by the Linux hoopla to try BSD, and it will grow even faster. Try to divide the BSD and Linux worlds too strongly, and you'll only hurt both. Emulation is an unmitigated Good Thing, since it helps put BSD on an equal footing with the media's darling Penguin without making alternative (read: non-MS) OSes more forbiding for vendors through unnecessary fragmentation.
At the time, Western Electric was the manufacturing arm of the Bell System (i.e. AT&T). So when Bell Labs wanted to distribute Unix, they did it through Western Electric. That's just how things worked in those pre-divestiture days.
Once again, I'm not talking about scripting. Scripting allows you to add new functionality, but it is quite limited as a way of increasing the richness of possible interactions with the desktop itself.
Let me give you a limited example of what I'm talking about, drawn from the world of signal-processing block languages. Suppose I want to represent my earlier example in a graphical way:
Now, suppose that the fgrep icon had little arrowheads on each side, one pointing in, the other pointing out. And it had a small rectangle along the bottom with the same "look" as the arrowheads. The arrowheads and rectangle represent input, output, and control, respectively.Now, either by dragging or drawing a line, I connect file1 to the control rectangle. Then I connect file2 to the input arrow, and finally file3 to the output arrow. Finally, I click on the center of the fgrep icon (or hit a key, or otherwise signal GO). I've just used fgrep to apply the string list in file1 to file2 and put the result in file3.
This is pretty clunky as it stands (I'd much prefer typing), but consider how easy it is to extend. For example, draw a circle around some file icons and connect them all up instead of file2. Have the desktop create file3 automagically, to be named or anonymously reprocessed later. Link other processing elements in. And so on.
OK, now think of creating your own processing-block icons from combinations of other blocks, or from scripts, templates, or various tools. Use inheritance and polymorphism to leverage existing blocks. Add other routing elements, represented by new sub-icons (like the arrowheads). Associate other programming semantics (e.g. looping, branching) with other drawing actions and icons.
All this stuff has been done already within applications and simulation environments--literally decades ago. Microsoft has been so oblivious in this area that they took a term of art--Visual Programming and rendered it utterly meaningless with "visual" languages which were anything but. As a result, they've left the world of graphical desktop development at a stage that doesn't tax the cognitive development of a slightly slow 2-year-old.
Why is it so hard for us to improve on this?
No, that's not really related. I can do all the scripting I want in TK/TCL already. If the desktop/WM helps in that, so much the better. But I can't even do simple combinations of files and processing like:
by using just the GUI. This, even though the idea of graphical metaphors for such things has existed for close to 30 years! And it's existed in ways (e.g. Tom's "connect the dots") that are intuitive even to children.There are a number of applications that include such functionality, from database design tools, CAD systems, and CASE tools, to children's games. Why are desktop designers so focused on becoming a better MS Windows that they ignore just how antiquated the model is they are following? Trying to "fix" things with scripting is simply combining the worst of the textual and graphical worlds. It's a dead end.
It's not just Unix users that are affected by this limited vision, but they are the ones most likely to be familiar with the pipes-and-filters methods that MS WIndows-like desktops are simply incapible of utilizing. So they're more keenly aware of What's Missing.
The fact is, the emerging free-software desktops might look better than MS Windows, be more configurable than MS Windows, and work better than MS Windows, but they don't break any new ground. Drag'n'drop gives no more functionality than the DOS 1.0 command line: feed filename A to application B. Component models make programming easier, but in themselves do nothing to improve desktop functionality. The fact that it is impossible to use the desktop to order a seqeunce of operations on one or more objects--something that should be absolutely basic--shows just how limited the desktop metaphor remains.
I'm sure some folks will say "just use a CLI," and that's certainly what I'd do. But there are natural ways to make a GUI do the same sort of thing, such as what Tom suggested in his question--from drag'n'drop to connect-the-dots. And this would just be the beginning of using hugely intuitive visual metaphors to allow everybody to do the things that only ksh/bash gurus can do now.
It's just a crying shame that the KDE folks are relegating themselves to improving the same tired and limited conceptual framework that MS Windows inhabits.
Free software has craftsmen a-plenty, and good ones. But where are the visionaries?
Only a few. For instance, when the X server on the Alpha would only work at 8 bits, I submitted a bug report. No response. So I wrote again, including the ticket number of the original bug report. Still no response. I downloaded the sources to XFree86, and rebuilt the whole tree. The server misrendered at 16 bits and beyond, so I tinkered with compiler optimizations and got it working correctly. Then I actually sent back a note to RedHat saying what I'd done. I also posted it to the "axp-list@redhat.com" (where by this time several people were complaining of the same problem). Other folks on the list found solutions as well.
Their server still didn't work a depths greater than 8 bits when they made their next release some months later. I've no idea if anyone ever even read my report and subsequent messages beyond noting that they were for Alpha and not Intel. I often get the feeling that they don't even read their own Alpha mailing list "axp-list".
Yet I've been impressed with their Intel distributions for both support and quality. And all the other things they've done for Linux are massively positive. More than any other business entity, they are responsible for Linux's ascendancy. That's why, despite problems like I described above, they get my support.
But us Alpha folks don't get no respect.
When I said "potshots" that's pretty much what I meant. The nice thing about the better technical lists, like Linux-kernel, is that partisan comments are passed over quietly, or quickly dismissed. So "discussions" is the wrong word. Anything related to a particular distro gets chased off the list pretty quickly, in any case, as being off-topic.
The "wrong direction" discussions tend to occur on other lists--Redhat-devel-list is one. They tend to be concerned with support or with particular bugs, and how awful it is that RedHat "just didn't care enough to send their very best" or "never responded to my bug report." One of the lists I follow pretty closely (because I have an Alpha) is the "axp-list" (AXP==Alpha). RedHat gets criticized pretty regularly for lack of support and quality in their Alpha releases. A lot of the criticsm is justified, too, IMHO.
But like I said, much of this is normal. Those of us who use RedHat products not only want them to Get It Right, we're at the least inconvenienced when they Get It Wrong. I must not have made that clear--my only complaint was at unsupported FUD, which does occasionally appear on technical lists. But when RedHat does something like ship a distro where the "man" command dumps core immediately (like the 5.1 release for Alpha), bring on the criticism...
In a word, yes. That is, until Microsoft redefined (both technically and legally) after the fact just what was and wasn't "server code."
I was around when this whole thing happened, working as chief software engineer for a startup (NetCount) doing server-based statistics collection. Having only one server (instead of four) to deal with on NT would have made our lives a lot easier. But just because it would have benefited us didn't make it right. The O'Reilly piece is spot-on. MS changed the rules and cut its competition off at the knees...
I went for years with 2 or 3 monitors of various sizes and qualities because of the blurring and other artifacts I saw with switches. Things have changed over the last couple of years. The switches I saw at customers/employers didn't seem suited for much beyond VGA. That's not true, now.
Things have changed, thanks to high-bandwidth VLSI video switching chips. Even my (relatively) cheap LinkSys lets me put up three side-by-side 80x80 Xterms with room left over (at 1600x1200x75Hz). There is a very slight blurring compared to connecting the monitor cable directly to the computer, but I get the same amount of blur just adding the monitor extension cable without the switch. There are no stripes, bands, ghosts, or other artifacts (beyond what I see from the video card itself--I've yet to see perfection in PC-class video cards, and in fact can see plenty of differences between cards through the switch). From what I've seen, other switches of recent design do as well (though pricier ones get you on-screen display and other niceties).
If you are doing production graphics (and you've spent >$3000 on a calibrated monitor and >$500 on a pro-grade video card) you shouldn't be playing around with switches in any case. But otherwise I think you've exaggerated the difference a switch makes. Cables make a much bigger difference, in my experience.
Omigod. That works!
Thank you! Thank you! Thank you!
I have a 4-port LinkSys switch I picked up at Fry's 1-1/2 years ago for $180. Even at 1600x1200 blurring is minimal; the trick was to get high-quality video cables (remember that you're doubling the length of cable and number of connectors, so proper impedance and low capacitance are a must). Some of my systems have PS/2-style keyboard and mouse connectors, others have old-style 5-pin DIN/9-pin D-style connectors. It handles both just fine. The only problem I have is that hot-keys don't work. Since it sits right beside my monitor that isn't a problem. Not using hot-keys might explain why I've never had caps-lock/num-lock/scroll-lock problems folks are reporting for the Belkin's. Or maybe it just works. In any case, it's close to the best $180 I've spent.
L.A. is actually where the majority of special-effects producers for the motion picture industry exist. Think about it for a second--where are the studio headquarters located? Where would you expect post-production facilities to be located? Even after location shooting in some cheaper place like Canada or Florida (no slam intende to either place--it's expensive to shoot in LA), the studios like to bring things back to L.A. for post-production. It's a fact of life, however sad that might be for you. There are areas of Culver City, Burbank, and (yes) Hollywood with block after block of such companies, including literally dozens of digital effects houses.
Pixar and ILM are the exceptions (though still on the Left Coast), along with the Video producers in NYC. But if you want to do motion pictures, I'm afraid that L.A. is still the place, much as the above AC may try to deny it.
It's a heck of a lot easier to set up extemporaneous networks, write encryption and steganographic software, and raise general havoc with *nix than with Windows or Macs. Try creating a neighborhood network with serial ports and slash wire using MSWindows or MacOS...
The powers-that-be may live to regret adopting Linux (if indeed they have, and this isn't just ZDNET's overeager newsmongering). It will ultimately prove far more corrosive to entrenched power than Billy's Mandarin-speaking dancing paperclips ever would have been.
What? He stole a quotation about stealing?
Holy Cow! It's a recursive aphorism!
Welcome to the real world. Innovators are rarely popularizers. Bowie is no pioneer, I agree 100%. But there's more to him than that.
There is an interesting quote by the 20th Century "classical" composer, Igor Stravinsky:
(Don't shoot me if I'm not word-for-word accurate--the above is at least the general idea.) Bowie is pretty up-front about the fact that he borrows/steals from numerious influences. The question is, does he merely mimic his sources ("borrow") or does he make them his own ("steal"), improving them and weaving them into his music such that they are a seamless part of it?I think he's done both. Some of his stuff is merely derivative, posed in a sort of trendier-than-thou way. Yet he has the knack of taking genres that have become moribund (e.g., the Psychedelica that underpinned the Ziggy Stardust era) and injecting life into them by combining them with other genres in creative ways.
Your summary of electronic music history understates just how old electronic music technology is by about 20 years. Here is an excellent timeline with a lot of background info (though be warned that inventors are rarely the best practitioners in this realm-- Raymond Scott was a bit of an exception).
But I don't think the fact that Bowie was born long after electronic music was first created is particularly relevant. The point is what what kind of music did he make with it. I frankly prefer his music to much of Kraftwerk's, even though Kraftwerk undeniably preceded him by many years. And that's the bottom line: not how the music is made or even what the musician says--most musicians would be better off if they just shut up, Bowie included. The music itself is what truely matters. -EdPCC was another product of Edition 7. The VAX C compiler in 32V (and the first VAX-based BSD's) was constructed using PCC.
Berkeley wasn't alone in adding networking to Unix (there were at least half a dozen different protocol stacks for Unix before TCP/IP saw the light of day). But they were contracted to implement the Big One: TCP/IP. A good thing, too, since the NCP stack (NCP was the ARPANET protocol prior to TCP/IP) for Unix was pretty buggy.
X's predecessor was W (developed, I believe, at Stanford). So C isn't the only product of alphabetic succession (its precursor was B-- Ken Thompson's BCPL derivative). I wonder why the Berlin folks haven't named their project "Y"? (Why not?)
Research Unix Edition 7 was released in 1978, and included:
- The Bourne Shell, the first shell that was a programming language in its own right.
- Environment variables (this was an OS enhancement, not just the shell features supporting it).
- UUCP--the Unix/Unix Copy Program. This brought networking, email, and (a bit later) news to the masses. This feature literally changed the world.
- File systems larger than 32MB. Unix was no longer a toy.
- Lint, along with system sources that actually passed it (no more "register *p" for generic pointers everywhere). C was forever improved by this step, since many people learned to program in it from reading kernel sources (just like Linux programmers do today).
- 32V, the port to the VAX--this was the ancestor of 3.x and 4.x BSD. (The 2.x BSD's ran on PDP-11's, and for a time were developed in parallel.)
- And so on...
This was the version that got Unix started at many Universities. It was also the last version of Research Unix to make it out of Bell Labs into general distribution for research and educational use. One can only wonder what we would have seen had AT&T not decided to squeeze money out of it, locking away further Research Editions.They're doing no such thing. One of their co-founders (David Filo) said that a company starting out today might consider Linux instead of FreeBSD, since it has more momentum at the moment. But he went on to say that he was quite happy with FreeBSD, in part because of the large amount of onsite experience Yahoo has with it. Doesn't sound like they're changing any time soon.
FreeBSD has a somewhat simpler kernel interface, closer to the original Research Unix kernels than Linux. Linux tends to be closer to System V. The virtual memory systems and network stacks are quite different; IMHO the VM system in FreeBSD is better than Linux's (both in terms of capability and performance), and the TCP/IP stack seems to perform better when supporting HTTP service, though this in part depends upon whose benchmarks you believe. FreeBSD has fewer device drivers, though the ones it has tend to be solid (as are many, but hardly all, of Linux's). The Berkeley FFS seems much less prone to damage than Linux's EXT2 FS, though it can be slower in some cases. Recent Linuxes do SMP better than FreeBSD, and Linux threads actually work. Linux supports a lot more hardware platforms (although other porting efforts are underway, FreeBSD really only runs on Intel and Alpha). There are more applications--both free and commercial--for Linux.
(I could go on, but you get the idea.)
There is no clear "superior" OS. A lot of the controvery is over religious issues--the real answer is to choose the system that is best for a particular application.
The Internet has tremendous potential for expanding the world of recorded music. For many of us it already has--I've been exposed to an enourmous variety of interesting music that I'd never have heard listening to the radio or visiting the local music store. But I just can't see this sort of hyped-up second-tier release being any sort of trend.
Just about every musician or band has far more material that they'll ever be able to release on CD (or vinyl, for those with that particular fetish). I'm sure that some of their fans would be quite interested in hearing it, but only the most devoted will be willing to pay a significant amount for it. The average quality of for-the-web music available is already bad--even though there is quite a bit that is as good or better as more traditionally released stuff, there is an order of magnitude more that is dog-howling material. Who wants to sift through all that dreck to find the good stuff?
OK, now think of having to pay for the "privilege" of searching for the good stuff. Why, that's even worse than the usual situation at the music store, where you have to buy a CD with twelve tracks of which you only like three.
I just can't see anyone making money on this sort of thing.
Those weren't moderation points. Those were votes.
...to be a better Microsoft. I get the feeling we've been spending too much time focused on "beating Windows--" Microsoft's market today--and not trying to figure out what their market will be three years from now. No matter how well we do--even if we're ten times better than Windows--we'll still be followers, not leaders.
We've got to get better at "the vision thing." The market for PC software is not where the next Big Thing is going to happen. Linus has talked about this, but I've been amazed how little most Linux folks have been listening: embedded, "personalized," application-specific systems are the future.
If you must look at Microsoft for trends, look at Windows CE, not Windows NT (and I don't mean just its use on Palmtops, where it's been pretty anemic). We've got a real chance to upend WinCE if we work at it, but I think a few too many of us are PC- and Web-focused.
So ask yourself, "what have I done to further the cause of pervasive Linux today?" Then shake hands with an EE, and take an OS where it has never gone before.
One of the elements of their system is its "patented cluster technology." I suspect that this is intended to address the need for rapid scalability--the Achilles' heel of many e-commerce systems. There is always a point where it is impossible to scale by simply adding boxes. (For some systems this occurs for any N>1, while most others stop scaling at a "few".) A nice trick if they've managed to solve this one... But a patent? They aren't going to get many takers in the open-source crowd with that kind of strategy. In fact, even if they've produced a wonderful system apart from this clustering technology, and somehow manage to GPL all but that one piece of it, I think most folks here would consider it tainted and stay far away.
Just what were they thinking?
Byte-manipulation isn't one of Alpha's strong points, especially if you're compiling with GCC. (One reason why using an Alpha as a web server is probably a waste of money.)
If you want a real idea of memory bandwidth, use a benchmark designed for the purpose, like STREAM. Or, even better, benchmark using the applications and data that are important to you.
In any case, it's irresponsible to post benchmark results without making the benchmark available. Show us the code! I strongly suspect that what you are measuring isn't memory bandwidth at all.
The papers which started it all were written at RAND in Santa Monica, CA (though the Pentagon paid for them). As for the birth of the ARPANET, which became the Internet--well, even though BBN (in Cambridge, MA) was contracted by (D)ARPA to build the hardware, the actual "first byte" was transmitted at UCLA, which last time I checked was in Los Angeles, CA.
The most popular Internet site is based in Santa Clara, CA. (AOL claims more visits, but a significant fraction of these aren't Internet-based). The major manufacturers of Internet infrastructure equipment are based in Silicon Valley, also in CA.
If being the center of Net VC and Net Companies doesn't make Silicon Valley the "center of the Internet," what would?