Still, ARP spoofing is a real problem, and 128-bit WEP means you have to be determined to crack the MAC layer, i.e. not just wardriving
It will have to do until 802.11x is widely available. And considering how much more it costs to do AES in CBC mode at 11 Mbps than it does to do an RC4 stream cipher, there might still be some use for 128-bit WEP even after that.
If all you're trying to do is prevent random drive-by ARP spoofs on your home WLAN, 128-bit WEP should be more than adequate. If you're trying to protect the locations of your atomic weapon systems, please use a stronger cryptosystem.
there are only opportunities to crawl on your lips over the blasted, ruined landscape of human misery that the greases the wheels of mindless commerce in an economic system designed by a dark conspiracy of secret overlords to ensure their perpetual control over the very fabric of society.
your happiness is a commodity that enjoyed a brief spike in market value during a period of economic instability caused by the introduction of new information technology. now that the Internet is well integrated into the system, stability has returned to the market and we can all return to our regularly scheduled slavery, ennui and occasional soma holiday.
We *ALL* expect something in return for the work we do, whether the source code we write is copy-lefted, open-sourced, or locked up tighter than your mama's asterisk. Anybody who tries to make the Congressman believe otherwise is trying to sell something for more than it's worth.
Why do we publish the source code where anyone can read > compile > install > use > modify it for their own purposes without having to pay us for the "right" to do it?
BECAUSE NONE OF US HAVE ANY MONEY!
We write it and give it away, because we know the sorts of people that we would be asking to pay us for it.
They don't have any more money than we do.
Sure, some of us are poorer than others, but almost none of us have positive net worth we can count in the millions of dollars. So we publish it under weird open source licenses and expect other forms of compensation:
+ Fee for service. "You want it to do what else?"
+ Publicity. "I wrote that. If you want more, I'm available for special jobs."
+ Barter. "I can make it do that, but you have to fix this other problem for me."
It's not big business. It's small business. And it's about the only way that a small entrepreneur can start a software business without having to give away the whole store to a venture capital firm. If you want to sell shrink-wrapped software, the cost of sale is way too high to start. You have to get into the market with open source.
You say it like that, and the Congressman will understand.
I, for one, am waiting for peoples to realize that 802.1x *is* the International Standard Cookie Monster protocol. Every time your authorization to access the network expires you'll be prompted for your identification.
Unless, of course, you aren't-- in which case, what's the point of deploying 802.1x?
See RFC 2917 for an "informational" RFC that seems (to me, at least) to be a superior technology. I'll quote the abstract inline:
This memo presents an approach for building core Virtual Private
Network (VPN) services in a service provider's MPLS backbone. This
approach uses Multiprotocol Label Switching (MPLS) running in the
backbone to provide premium services in addition to best effort
services. The central vision is for the service provider to provide a
virtual router service to their customers. The keystones of this
architecture are ease of configuration, user security, network
security, dynamic neighbor discovery, scaling and the use of existing
routing protocols as they exist today without any modifications.
The carrier operates the physical equipment that implements the virtual routers. The customers retain control of the virtual router as long as they keep paying their bills. VPN routes don't waft into the core like they do in RFC 2547, and the virtual routers are perfectly free to encrypt traffic over the LSP if the customer is willing to pay for it being done that way.
Can someone please explain why this 'request for comments' has attracted so little interest?
You can buy a Macintosh instead. They come straight from the factory with a pretty good quality Unix pre-installed. And it's getting better all the time.
Okay, you might have to fuss a little: the Titanium and the iBook only have one button trackpads, and you *might* have a little trouble adjusting to a GUI that doesn't actively *HATE* you like GNOME and KDE do... "What does the little spider do?" "It bites you if you touch it, that's what."
> What I found interesting was that their attorney is one Archibald Cox. Now if that's the
> Watergate Special Prosecutor, then they're not exactly skimping on the legal firepower,
> are they?
It's actually Archibold Cox, Jr.-- his *father* was the special prosecutor.
I met the man once. He's a very shrewd character, and Magnequench is only one of his ongoing projects.
The effort fragmented, and the working group rewrote its charter to limit its purpose to defining requirements. Their RFC's about the Common Profile for Instant Messaging (CPIM) have been published, and they should be closing down soon. The IETF instant messaging effort is now mainly split into two camps with subtly different aims.
The SIMPLE working group is adapting the Session Initiation Protocol (SIP) to serve the traditional purpose of instant messaging.
The APEX working group is developing a BEEP profile to serve as a general-purpose, low-latency, Internet-scale application messaging and presence protocol.
Both are good ideas, and neither one is enough by itself. The SIMPLE group is likely to get something up and workable quickly, but it won't be all things to all people. The APEX group, on the other hand, may take longer, but it is doing some remarkably good work and there is already a fair amount of BEEP implementation code published under a BSD license at sourceforge. See the new BEEP Home Page for the juiciest news.
The IETF is in the process of proposing not one but two standard protocols for "instant messaging" applications. (Why two? It's a long story, and it isn't over.) I recommend reviewing the charters of the APEX and SIMPLE working groups, as well as the appropriate drafts.
RFC 2778 and RFC 2779 are good background information too.
It seems to me that the direction the Jabber project should take is to consider both of these protocols to be "transports" and, er-- assimilate them. Yeah... that's the ticket.
...the anonymous coward said as if there's no point in saying what you mean and meaning what you say.
i'm serious here. it's a matter of architecture. if your architecture is that the human interface software is a "client" of the game world "service" then your protocol will necessarily place too much authority in the software distributed among the players.
if your architecture is peer-to-peer with a central game resource manager, an independent rule execution agent, and a network of player interaction agents, your architecture will be much more robust.
you can call that "a client/server architecture" if you like, and you can even dismiss my arguments as quibbling over 'semantics', but you don't make good architectures into good designs and implementations by deliberately making poor descriptions of them.
while we're "redefining" our way around hard problems, permit me to stand on my soapbox and rant about two other fundamental problems for large-scale multiplayer network games that rarely receive the attention they require:
1) the core protocol *is* the game. the rules of the real game the players must abide are documented in the core protocol specification. if you think there is strength in any game design that depends on the obscurity of the real rules of the game from *all* of the players, you should think again.
2) all multiplayer games are peer-to-peer, not client/server. the human interaction software cannot be bundled with transaction controllers in a multiplayer game. either the protocol must be simultaneously completely secure *and* fully distributed, or there must be an independent transaction processing system that all the players trust. unless that system is completely stateless, i.e. is not the authoritative repository of any game state, then you shouldn't call it a server: it's simply one of the peers in the peer-to-peer protocol.
so yeah, you can GPL the human interface implementation if you want. you should probably go through the extra effort of publishing the protocol specification in clear language, and making copies freely available. you can even GPL the game transaction processing system if you're feeling jaunty.
if you do this and you still want to make money, there is exactly one way left to do it: sell the service of operating the game. design the game for a network effect, and you may be able to survive the wave of competing implementations.
Before there was the Web. Discussions like this primarily took place on Usenet. Usenet is like water. It's free, and as long as someone who loves it is continuing to run it, it will continue to move messages.
On the other hand, Usenet is practically irrelevant now. It's been polluted by spam and other forms of abuse. Of all the open source projects I can think of, none more so than Linux seems to be as susceptible to the problem that rendered Usenet irrelevant: the Tragedy of the Commons.
So long as Usenet could be managed by The Cabal, its facility as a medium was maintainable. When it grew to the point that the Cabal was overwhelmed by abuse, Usenet's obsolescence began. Its obsoletion arrived in the form of the Web.
That said, there is no reason to believe that Mac OS X is any more likely to attract Linux desktop users away than any other Unix OS, e.g. Solaris, HP-UX, Irix, A/IX, etc. Nor is there any reason to suspect that a confederacy of major Linux distribution service providers could not scale to manage the levels of demand that Microsoft currently services.
Linux advocates needn't ph33r the Mac. They need to ph33r themselves.
I used LinuxPPC 2000 (and two earlier revisions from 1999) on my Powerbook G3. I needed to develop software for a variety of Unix platforms, and Linux was the only option that allowed me not to have to invest in x86 hardware.
At no time did I ever even THINK about installing LinuxPPC over Mac OS 9 on my wife's iMac. She is not an IT professional and she uses her computer for schoolwork, i.e. writing papers, drawing diagrams and using Internet applications.
Let me be clear about this: I asked her to evaluate the idea by using my Powerbook running Linux, and she ultimately rejected Linux for all the traditional reasons. Mac OS 9 really doesn't suck as much as Slashdot would like to believe.
That being said, Mac OS X is a whole different subject. I switched my Powerbook in November and never went back. My wife has tried it, and her reaction was decidedly more positive.
It's still too early to run the Public Beta on her iMac, because some of the ancillary applications won't run (e.g. the DVD player). Still, I can PLAN her transition from Mac OS 9 to Mac OS X. That was simply not in the cards with Linux.
It is this experience which tells me that for Linux (as a desktop OS) to survive on PowerPC, someone other than Apple will have to start selling PPC hardware-- hardware that will NOT run Mac OS, without doubt.
So tell me-- just WHO is lining up right now to build PowerPC workstations that will run Linux, Darwin and NetBSD, but NOT Mac OS? Because without that happening, PPC-Linux has about as much future as ARM-Linux.
I am exactly one of these people. I develop software that runs on Solaris and I use the Macintosh to run office productivity tools.
Here are 3 applications that require an X Window Server to use, and for which there are no useful alternatives:
1. XEmacs
No, I don't want XEmacs running on my Macintosh
and displaying there too. I want the copy of
XEmacs that runs on my team's shared Solaris
development host to display on my Macintosh.
And no, I don't consider running 'emacs' in a
telnet window to be a useful alternative.
2. Admintool
Yes, I want to administer that Solaris host in
the telco closet from the comfort and relative
safety of my Macintosh. No, I don't
consider telnet to be a useful alternative
here either.
3. Perfmeter
Nothing like having a nice little running
graph of the resource load on your favorite
headless server horses. This is a cheap and
dirty tool and there is no substitute. Gotta
have an X Window server for it to display.
Oh wait, you probably think I'm crazy because I want to use a Macintosh for writing documents and I don't want a whole other stupid computer on my desk just so I can run an X Window server on it.
Surely there's only a handful of people like me. Guess what? The reason not so many people are running X Window servers on their Mac OS 9 boxes and using them to operate software on Unix servers is that you have to get purchase order signed to buy the Tenon X Window server.
Sure, I guess I could toss out the Macintosh and switch entirely over to Windows NT or Windows 2000 where I can easily get an X Window server to run, but then I'd have to give up my Macintosh.
Fortunately, with this XFree86 news I have TWO OPTIONS for getting X Window clients to display on my Macintosh. And that allows me to continue using all the really good Macintosh software without having to buy a whole other computer to run an X Window server.
Actually, the Carbon framework has support for multiprocessing. There are actually two API's available to Carbon applications: the really old one that almost no one used under Mac OS 9, and a newer one which hasn't been widely adopted yet.
Unless an MP framework is used under Carbon (either OS 9 or OS X), each application executes in only one single preemtively scheduled thread at a time. Under OS X however, each Carbon application gets its own process space and execution thread(s).
The Cocoa framework makes liberal use of preemptive thread scheduling, so it should scream on a dual or quad G4 box. And the POSIX thread support for the BSD layer is pretty good too (though not as full-featured as in Solaris fer instance).
Classic is basically "Son of MAE," the Macintosh OS emulator for Unix from long ago days of yore when the elves still walked middle earth and the world was young. It's basically OS 9 running as a process under Unix. On an SMP box, the Classic environment will probably only see modest performance gains.
Where a dual G4 is going to show up as an obvious performance improvement is in the SMP-capable kernel in OS X. With dual CPU's, one CPU can be handling network interface events, while the other is handling SCSI traffic, and so on.
This will make life hellacious for device driver writers. Concurrency bugs are nasty critters and they can be particularly pernicious when they're loaded into your kernel. Ask anyone whose ever written a device driver of any complexity for the Solaris OS.
When the Telecom Act of 1996 was the subject of debate in Congress, I remember there were quite a few people like me who were pig-biting pissed-off that Congress was even considering handing over the keys to the store to these behemoth corporations.
The Telecom Act, if you ask anybody who was really paying attention in 1996, was never designed to open up competition in the local loop. That was just the spam to serve the constituents back home in flyover country. It was clearly designed, with obvious intent, to hand over monopoly control of key parts of the American telecommunications infrastructure to a tiny handful of huge, collusive corporations.
"Where has all the competition gone?" Jeez. I'll have what he's having.
try to remember what motivated apple to open-sourc
on
No Love For Darwin?
·
· Score: 2
If you're developing software for Mac OS X, it's a lot easier to get stuff done if you can read the Darwin source. It's also a bonus for Apple that more eyes on the source means that deep bugs are dug out and fixed faster.
If your criteria for judging the success of Darwin is the number of publicly-traded companies selling packages containing plastic discs with Darwin code printed on them, then you're going to be REALLY missing the point.
As a regular voter in U.S. elections, I want to know how each of the candidates for President intends to execute changes in the way the Department of Defense develops and maintains readiness to defend against physical, network and semantic information attacks by enemies, both foreign and domestic.
The War College has been churning out papers on this very subject for years, yet the Congress continues to allocate funds like we're preparing to do a D-day style invasion off the cold chaulks in the next "Last Great War".
I'm beginning to believe that only the President has the power to Stop The Madness. What will you do about the problem?
Sure, you can teach yourself to code by sitting in
front of a computer and hammering on a compiler
until you figure out how to do it right. You don't
need to go to college for that.
To learn the art of engineering (I'm not talking
about the skills you need to be an engineer, but
the art of engineering-- why it's done this way or
that way, and how tell when another new way is
better), you need a teacher with experience.
Universities often do a pretty decent job of
matching students with teachers and constructing
courses of study.
If the kids today want to skip college and go right
into coding, I guess there are employers who will
be happy to hire them. I just hope it turns out
that those employers still need engineers too.
Re:Since the site's slashdotted already...
on
Gnutella Vs. SPAM
·
· Score: 2
ShareZilla is network abuse and Gnutella itself isn't? That's rich. (I'm one of those annoying gits who think that tcp/80 ought to be used for http and if you're running something other than http over that port, then you're abusing the network. Gnutella shouldn't let users bind below tcp/1024. It's that simple.)
About ShareZilla-- I'm laughing my sorry ass off. All those boneheads who were hyping Gnutella when it first arrived on the scene should have listened to us oldtimers who were telling you that, as an application protocol, it sucks rocks. You're getting what you asked for.
ShareZilla is only the beginning. I'm waiting for the real fun to begin when the blackhats start swinging their malevolent gaze around to it. If you want to prevent network abuse you have to design the network to resist tampering by abusers.
The Gnutella network is a child's toy. (And Jason, if you're reading this, you should read this and give me a call. I may have a hobby project for you.)
The mistake 3DO made was not in licensing the hardware design, but in trying to license out both the hardware design and the license to publish software that would run on the hardware.
The hardware manufacturers had no incentive to sell the hardware as a "loss leader" because they got no cut from the software licensing business. The software developers had no incentive to develop software for the platform because the retail price of the hardware was so damned high.
This is what you call an indefensible market position. There was no profit for anyone to use the 3DO hardware and software licenses. No one was buying anything.
The 3DO Company didn't start developing titles for the system until the writing was already on the wall. For awhile, there was the potential of them pulling out of the spiral-- they had mostly fixed their business model, and they had a second generation hardware design that might have been able to hold up against the Playstation 2 and the Dreamcast and various PC gaming solutions, but they never managed to complete a deal that put boxes on store shelves.
So, et voila, The 3DO Company is Electronic Arts The Sequel.
On the other hand, the protocol suffers from a number of scalability flaws, and the "open source community" appears entirely uninterested in fixing it. Instead, all the effort appears to be channeled into developing ports and clones that are interoperable with the Nullsoft implementation-- an implementation that is proprietary and considered by AOL to be a trade secret.
If the effort to develop an open protocol for a searchable distributed file storage and transfer system were to launched by-- say-- an IETF working group, then I would be inclined to agree with the idea that it is an "open source community project."
Until then, I don't see it as anything even remotely resembling a free software project.
Using the word "routed" to describe the way GNUtella forwards search requests is... shall we say... cheritable. Some of us think 'routing' is what happens when you are running a protocol that runs a real routing algorithm, e.g. Bellman-Ford or Dijkstra. (Do the Nullsoft people even know how real routing algorithms work, or did they all learn to code by watching Star Trek: the Next Generation?)
And while we're on the subject, I think "peasant-to-peasant" might be a more colorful and accurate way to describe the way GNUtella agents actually interwork... considering the way they trash the commons.
Slashdot Mirror
Yeah, I feel your pain...
Still, ARP spoofing is a real problem, and 128-bit WEP means you have to be determined to crack the MAC layer, i.e. not just wardriving
It will have to do until 802.11x is widely available. And considering how much more it costs to do AES in CBC mode at 11 Mbps than it does to do an RC4 stream cipher, there might still be some use for 128-bit WEP even after that.
If all you're trying to do is prevent random drive-by ARP spoofs on your home WLAN, 128-bit WEP should be more than adequate. If you're trying to protect the locations of your atomic weapon systems, please use a stronger cryptosystem.
there are only opportunities to crawl on your lips over the blasted, ruined landscape of human misery that the greases the wheels of mindless commerce in an economic system designed by a dark conspiracy of secret overlords to ensure their perpetual control over the very fabric of society.
your happiness is a commodity that enjoyed a brief spike in market value during a period of economic instability caused by the introduction of new information technology. now that the Internet is well integrated into the system, stability has returned to the market and we can all return to our regularly scheduled slavery, ennui and occasional soma holiday.
thank you for your time. no go the fsck away.
...nobody rides for free.
We *ALL* expect something in return for the work we do, whether the source code we write is copy-lefted, open-sourced, or locked up tighter than your mama's asterisk. Anybody who tries to make the Congressman believe otherwise is trying to sell something for more than it's worth.
Why do we publish the source code where anyone can read > compile > install > use > modify it for their own purposes without having to pay us for the "right" to do it?
BECAUSE NONE OF US HAVE ANY MONEY!
We write it and give it away, because we know the sorts of people that we would be asking to pay us for it.
They don't have any more money than we do.
Sure, some of us are poorer than others, but almost none of us have positive net worth we can count in the millions of dollars. So we publish it under weird open source licenses and expect other forms of compensation:
+ Fee for service. "You want it to do what else?"
+ Publicity. "I wrote that. If you want more, I'm available for special jobs."
+ Barter. "I can make it do that, but you have to fix this other problem for me."
It's not big business. It's small business. And it's about the only way that a small entrepreneur can start a software business without having to give away the whole store to a venture capital firm. If you want to sell shrink-wrapped software, the cost of sale is way too high to start. You have to get into the market with open source.
You say it like that, and the Congressman will understand.
--j h woodyatt
Indeed. This is quite correct.
I, for one, am waiting for peoples to realize that 802.1x *is* the International Standard Cookie Monster protocol. Every time your authorization to access the network expires you'll be prompted for your identification.
Unless, of course, you aren't-- in which case, what's the point of deploying 802.1x?
See RFC 2917 for an "informational" RFC that seems (to me, at least) to be a superior technology. I'll quote the abstract inline:
The carrier operates the physical equipment that implements the virtual routers. The customers retain control of the virtual router as long as they keep paying their bills. VPN routes don't waft into the core like they do in RFC 2547, and the virtual routers are perfectly free to encrypt traffic over the LSP if the customer is willing to pay for it being done that way.
Can someone please explain why this 'request for comments' has attracted so little interest?
You can buy a Macintosh instead. They come straight from the factory with a pretty good quality Unix pre-installed. And it's getting better all the time.
Okay, you might have to fuss a little: the Titanium and the iBook only have one button trackpads, and you *might* have a little trouble adjusting to a GUI that doesn't actively *HATE* you like GNOME and KDE do... "What does the little spider do?" "It bites you if you touch it, that's what."
> What I found interesting was that their attorney is one Archibald Cox. Now if that's the
> Watergate Special Prosecutor, then they're not exactly skimping on the legal firepower,
> are they?
It's actually Archibold Cox, Jr.-- his *father* was the special prosecutor.
I met the man once. He's a very shrewd character, and Magnequench is only one of his ongoing projects.
See my earlier post in this thread.
The effort fragmented, and the working group rewrote its charter to limit its purpose to defining requirements. Their RFC's about the Common Profile for Instant Messaging (CPIM) have been published, and they should be closing down soon. The IETF instant messaging effort is now mainly split into two camps with subtly different aims.
The SIMPLE working group is adapting the Session Initiation Protocol (SIP) to serve the traditional purpose of instant messaging.
The APEX working group is developing a BEEP profile to serve as a general-purpose, low-latency, Internet-scale application messaging and presence protocol.
Both are good ideas, and neither one is enough by itself. The SIMPLE group is likely to get something up and workable quickly, but it won't be all things to all people. The APEX group, on the other hand, may take longer, but it is doing some remarkably good work and there is already a fair amount of BEEP implementation code published under a BSD license at sourceforge. See the new BEEP Home Page for the juiciest news.
The IETF is in the process of proposing not one but two standard protocols for "instant messaging" applications. (Why two? It's a long story, and it isn't over.) I recommend reviewing the charters of the APEX and SIMPLE working groups, as well as the appropriate drafts.
RFC 2778 and RFC 2779 are good background information too.
It seems to me that the direction the Jabber project should take is to consider both of these protocols to be "transports" and, er-- assimilate them. Yeah... that's the ticket.
...the anonymous coward said as if there's no point in saying what you mean and meaning what you say.
i'm serious here. it's a matter of architecture. if your architecture is that the human interface software is a "client" of the game world "service" then your protocol will necessarily place too much authority in the software distributed among the players.
if your architecture is peer-to-peer with a central game resource manager, an independent rule execution agent, and a network of player interaction agents, your architecture will be much more robust.
you can call that "a client/server architecture" if you like, and you can even dismiss my arguments as quibbling over 'semantics', but you don't make good architectures into good designs and implementations by deliberately making poor descriptions of them.
while we're "redefining" our way around hard problems, permit me to stand on my soapbox and rant about two other fundamental problems for large-scale multiplayer network games that rarely receive the attention they require:
1) the core protocol *is* the game. the rules of the real game the players must abide are documented in the core protocol specification. if you think there is strength in any game design that depends on the obscurity of the real rules of the game from *all* of the players, you should think again.
2) all multiplayer games are peer-to-peer, not client/server. the human interaction software cannot be bundled with transaction controllers in a multiplayer game. either the protocol must be simultaneously completely secure *and* fully distributed, or there must be an independent transaction processing system that all the players trust. unless that system is completely stateless, i.e. is not the authoritative repository of any game state, then you shouldn't call it a server: it's simply one of the peers in the peer-to-peer protocol.
so yeah, you can GPL the human interface implementation if you want. you should probably go through the extra effort of publishing the protocol specification in clear language, and making copies freely available. you can even GPL the game transaction processing system if you're feeling jaunty.
if you do this and you still want to make money, there is exactly one way left to do it: sell the service of operating the game. design the game for a network effect, and you may be able to survive the wave of competing implementations.
The working group charter is here, and there is additional information about protocol candidates available here.
The open source community needs to get with the program, read the RFC's and the Internet Drafts, and start coding.
Before it's too late.
Consider this analogy: Usenet.
Before there was the Web. Discussions like this primarily took place on Usenet. Usenet is like water. It's free, and as long as someone who loves it is continuing to run it, it will continue to move messages.
On the other hand, Usenet is practically irrelevant now. It's been polluted by spam and other forms of abuse. Of all the open source projects I can think of, none more so than Linux seems to be as susceptible to the problem that rendered Usenet irrelevant: the Tragedy of the Commons.
So long as Usenet could be managed by The Cabal, its facility as a medium was maintainable. When it grew to the point that the Cabal was overwhelmed by abuse, Usenet's obsolescence began. Its obsoletion arrived in the form of the Web.
That said, there is no reason to believe that Mac OS X is any more likely to attract Linux desktop users away than any other Unix OS, e.g. Solaris, HP-UX, Irix, A/IX, etc. Nor is there any reason to suspect that a confederacy of major Linux distribution service providers could not scale to manage the levels of demand that Microsoft currently services.
Linux advocates needn't ph33r the Mac. They need to ph33r themselves.
I have a very simple reason for saying this.
I used LinuxPPC 2000 (and two earlier revisions from 1999) on my Powerbook G3. I needed to develop software for a variety of Unix platforms, and Linux was the only option that allowed me not to have to invest in x86 hardware.
At no time did I ever even THINK about installing LinuxPPC over Mac OS 9 on my wife's iMac. She is not an IT professional and she uses her computer for schoolwork, i.e. writing papers, drawing diagrams and using Internet applications.
Let me be clear about this: I asked her to evaluate the idea by using my Powerbook running Linux, and she ultimately rejected Linux for all the traditional reasons. Mac OS 9 really doesn't suck as much as Slashdot would like to believe.
That being said, Mac OS X is a whole different subject. I switched my Powerbook in November and never went back. My wife has tried it, and her reaction was decidedly more positive.
It's still too early to run the Public Beta on her iMac, because some of the ancillary applications won't run (e.g. the DVD player). Still, I can PLAN her transition from Mac OS 9 to Mac OS X. That was simply not in the cards with Linux.
It is this experience which tells me that for Linux (as a desktop OS) to survive on PowerPC, someone other than Apple will have to start selling PPC hardware-- hardware that will NOT run Mac OS, without doubt.
So tell me-- just WHO is lining up right now to build PowerPC workstations that will run Linux, Darwin and NetBSD, but NOT Mac OS? Because without that happening, PPC-Linux has about as much future as ARM-Linux.
I am exactly one of these people. I develop software that runs on Solaris and I use the Macintosh to run office productivity tools.
Here are 3 applications that require an X Window Server to use, and for which there are no useful alternatives:
1. XEmacs
No, I don't want XEmacs running on my Macintosh
and displaying there too. I want the copy of
XEmacs that runs on my team's shared Solaris
development host to display on my Macintosh.
And no, I don't consider running 'emacs' in a
telnet window to be a useful alternative.
2. Admintool
Yes, I want to administer that Solaris host in
the telco closet from the comfort and relative
safety of my Macintosh. No, I don't
consider telnet to be a useful alternative
here either.
3. Perfmeter
Nothing like having a nice little running
graph of the resource load on your favorite
headless server horses. This is a cheap and
dirty tool and there is no substitute. Gotta
have an X Window server for it to display.
Oh wait, you probably think I'm crazy because I want to use a Macintosh for writing documents and I don't want a whole other stupid computer on my desk just so I can run an X Window server on it.
Surely there's only a handful of people like me. Guess what? The reason not so many people are running X Window servers on their Mac OS 9 boxes and using them to operate software on Unix servers is that you have to get purchase order signed to buy the Tenon X Window server.
Sure, I guess I could toss out the Macintosh and switch entirely over to Windows NT or Windows 2000 where I can easily get an X Window server to run, but then I'd have to give up my Macintosh.
Fortunately, with this XFree86 news I have TWO OPTIONS for getting X Window clients to display on my Macintosh. And that allows me to continue using all the really good Macintosh software without having to buy a whole other computer to run an X Window server.
Why is this such a bad idea?
Actually, the Carbon framework has support for multiprocessing. There are actually two API's available to Carbon applications: the really old one that almost no one used under Mac OS 9, and a newer one which hasn't been widely adopted yet.
Unless an MP framework is used under Carbon (either OS 9 or OS X), each application executes in only one single preemtively scheduled thread at a time. Under OS X however, each Carbon application gets its own process space and execution thread(s).
The Cocoa framework makes liberal use of preemptive thread scheduling, so it should scream on a dual or quad G4 box. And the POSIX thread support for the BSD layer is pretty good too (though not as full-featured as in Solaris fer instance).
Classic is basically "Son of MAE," the Macintosh OS emulator for Unix from long ago days of yore when the elves still walked middle earth and the world was young. It's basically OS 9 running as a process under Unix. On an SMP box, the Classic environment will probably only see modest performance gains.
Where a dual G4 is going to show up as an obvious performance improvement is in the SMP-capable kernel in OS X. With dual CPU's, one CPU can be handling network interface events, while the other is handling SCSI traffic, and so on.
This will make life hellacious for device driver writers. Concurrency bugs are nasty critters and they can be particularly pernicious when they're loaded into your kernel. Ask anyone whose ever written a device driver of any complexity for the Solaris OS.
Glassman is clearly high on paint thinner.
When the Telecom Act of 1996 was the subject of debate in Congress, I remember there were quite a few people like me who were pig-biting pissed-off that Congress was even considering handing over the keys to the store to these behemoth corporations.
The Telecom Act, if you ask anybody who was really paying attention in 1996, was never designed to open up competition in the local loop. That was just the spam to serve the constituents back home in flyover country. It was clearly designed, with obvious intent, to hand over monopoly control of key parts of the American telecommunications infrastructure to a tiny handful of huge, collusive corporations.
"Where has all the competition gone?" Jeez. I'll have what he's having.
If you're developing software for Mac OS X, it's a lot easier to get stuff done if you can read the Darwin source. It's also a bonus for Apple that more eyes on the source means that deep bugs are dug out and fixed faster.
If your criteria for judging the success of Darwin is the number of publicly-traded companies selling packages containing plastic discs with Darwin code printed on them, then you're going to be REALLY missing the point.
As a regular voter in U.S. elections, I want to know how each of the candidates for President intends to execute changes in the way the Department of Defense develops and maintains readiness to defend against physical, network and semantic information attacks by enemies, both foreign and domestic.
The War College has been churning out papers on this very subject for years, yet the Congress continues to allocate funds like we're preparing to do a D-day style invasion off the cold chaulks in the next "Last Great War".
I'm beginning to believe that only the President has the power to Stop The Madness. What will you do about the problem?
Sure, you can teach yourself to code by sitting in
front of a computer and hammering on a compiler
until you figure out how to do it right. You don't
need to go to college for that.
To learn the art of engineering (I'm not talking
about the skills you need to be an engineer, but
the art of engineering-- why it's done this way or
that way, and how tell when another new way is
better), you need a teacher with experience.
Universities often do a pretty decent job of
matching students with teachers and constructing
courses of study.
If the kids today want to skip college and go right
into coding, I guess there are employers who will
be happy to hire them. I just hope it turns out
that those employers still need engineers too.
ShareZilla is network abuse and Gnutella itself isn't? That's rich. (I'm one of those annoying gits who think that tcp/80 ought to be used for http and if you're running something other than http over that port, then you're abusing the network. Gnutella shouldn't let users bind below tcp/1024. It's that simple.)
About ShareZilla-- I'm laughing my sorry ass off. All those boneheads who were hyping Gnutella when it first arrived on the scene should have listened to us oldtimers who were telling you that, as an application protocol, it sucks rocks. You're getting what you asked for.
ShareZilla is only the beginning. I'm waiting for the real fun to begin when the blackhats start swinging their malevolent gaze around to it. If you want to prevent network abuse you have to design the network to resist tampering by abusers.
The Gnutella network is a child's toy. (And Jason, if you're reading this, you should read this and give me a call. I may have a hobby project for you.)
Umm... talk to someone who was there.
The mistake 3DO made was not in licensing the hardware design, but in trying to license out both the hardware design and the license to publish software that would run on the hardware.
The hardware manufacturers had no incentive to sell the hardware as a "loss leader" because they got no cut from the software licensing business. The software developers had no incentive to develop software for the platform because the retail price of the hardware was so damned high.
This is what you call an indefensible market position. There was no profit for anyone to use the 3DO hardware and software licenses. No one was buying anything.
The 3DO Company didn't start developing titles for the system until the writing was already on the wall. For awhile, there was the potential of them pulling out of the spiral-- they had mostly fixed their business model, and they had a second generation hardware design that might have been able to hold up against the Playstation 2 and the Dreamcast and various PC gaming solutions, but they never managed to complete a deal that put boxes on store shelves.
So, et voila, The 3DO Company is Electronic Arts The Sequel.
...and Apple makes what hardware that would run the IA32 version of Darwin 1.0?
On the other hand, the protocol suffers from a number of scalability flaws, and the "open source community" appears entirely uninterested in fixing it. Instead, all the effort appears to be channeled into developing ports and clones that are interoperable with the Nullsoft implementation-- an implementation that is proprietary and considered by AOL to be a trade secret.
If the effort to develop an open protocol for a searchable distributed file storage and transfer system were to launched by-- say-- an IETF working group, then I would be inclined to agree with the idea that it is an "open source community project."
Until then, I don't see it as anything even remotely resembling a free software project.
Using the word "routed" to describe the way GNUtella forwards search requests is... shall we say... cheritable. Some of us think 'routing' is what happens when you are running a protocol that runs a real routing algorithm, e.g. Bellman-Ford or Dijkstra. (Do the Nullsoft people even know how real routing algorithms work, or did they all learn to code by watching Star Trek: the Next Generation?)
And while we're on the subject, I think "peasant-to-peasant" might be a more colorful and accurate way to describe the way GNUtella agents actually interwork... considering the way they trash the commons.