It wasn't a bad idea, really -- you had the right motivation. It's just... I couldn't stand the idea of doing anything nice for the people who are behind this thing. It would be physically painful to me.;)
Except for one thing. You live in the EU (I'm guessing Great Britain, because you listed monetary amounts in british pounds), but the original poster and I live in the United States. So, your observations about how things work in Britain have no bearing on how things work here. It may very well be that patents are managed more effectively in Britain and the EU than in the United States (my gut feeling is that they are). But, remember -- over on THIS side of the pond, the patent and IP situation is completely, hopelessly out of control. It's been a joke for so long that it's starting to be considered a cliche.
Seriously. An American complaining about an inane patent system is probably complaining about HIS, not YOURS. From the sound of it, things aren't quite as bad over there.
The solution to your concerns is to make sure that the ONLY people permitted to develop for the kernel are pre-vetted to ensure they have no conflicts of interest; for example, kernel development could be shared by teams at Red Hat, IBM, SUSE, etc. Restrict the set of people who can code for the kernel, institute mandatory background checks and tests for conflicts of interest, and the problem goes away.
Everyone would be *permitted* to suggest kernel patches, but these patches would have to be completely recoded from scratch, only using the algorithm provided rather than any actual code. And, the contributions of each kernel developer would be extensively tracked in some way.
Actually, that looks like they're just passing along the system-generated message (java.lang.NullPointerException) with a note about the location in the code where the error took place (the routine that creates a transform handler). The programmer would probably be able to make perfect sense out of it. Remember, error codes aren't for users, they're for developers.
But, wouldn't it bother you to reward the assholes who are behind this? Why should they succeed and get their buyout? Let them dry up and blow away, as they should. I hope they lose money hand over fist, and that IBM buries their company deep and dark, Joe Pesci style.
So, did your cruel and wretched retaliation against this poor hopeful employee make you feel powerful and important? Do you feel like a big man, because you mercilessly stripped some poor unemployed guy of his internet connection? And, over what? His harmless sending of a resume in hopes of working with you? Do you feel like more of a man, now that you've shown yourself to be a beast?
You've done more than beat on the downtrodden; you have made yourself into the type of person who beats on the downtrodden and has the gall to brag about it on Slashdot. As such, you are insignificant to me. You simply don't exist.
Come work for a company on the cutting edge! Here at S**, we don't make products; we sue over them! As a newly hired HR Drone, every day will be exciting, whether you're arguing with the teamsters over whether lead plates constitute heavy loads, dodging a falling pallet of resumes as it crashes down into accounting (freeing up positions and jump-starting our economy), or using your brawn to muscle those resumes onto our industrial scanner for permanant storage! Ambitious, energetic applicants may find themselves managing our lead smelting operation -- why pay money for a gym sauna, when you can be promoted into one!
Requirements:
Must be able to lift 60 pounds; must be able to operate industrial equipment; must be able to use a computer and scanner. High pain threshhold desireable. Salary DOE. EOE. Unlucky workers DOA.
Ah, but the real question is, would Bob's replacement look up at the hole in the ceiling, and down at the big red dent in the floor, and decide he *really* wanted to go back to school instead?
I don't think it actually *costs* a company much to do something like this. The staff that would be doing it are generally on salary, so they would either be doing this or playing solitaire. The real thing the companies are kvetching about is that they have to actually *work* on resumes they would rather just delete. It's a minor irritation for the HR flacks, that's all. As for me, I couldn't care less that Susie HRDrone has to spend twenty minutes copying resumes instead of looking at her french nails. They ought to quit complaining; at least they're working!;)
But, in all fairness, you're right about one thing: the government is filled with useless, stupid bureaucracy. I get pretty fed up with it sometimes, myself.
Re:Not just from its libraries
on
Hijacking .NET
·
· Score: 1
I agree with you that C# is a pretty cool language, and probably a "step forward" as you say, but the fact that only part of the language has been okayed by ECMA still bothers me somewhat. They should have standardized the libraries, too, with any new stuff they want to build going into add-on libraries. This doesn't mean I wouldn't use C#, of course. It's a nice language. I'm just saying I understand the point of view of people who would rather it were "free".
Java has some of the same problems, although the fact that there are more than one vendor supplying development kits makes Java a little "safer" (you've got Sun's JDK, Blackdown, and IBM, plus GCJ is in progress, etc). Plus, according to the Java license, once you've got a JDK, you can basically use it forever unless you violate it (by trying to "pollute" java, for instance). Client software doesn't understand java? Give them a JRE along with your app. See? It's a little "safer" in a sense, in that you can just say, "Ok, I'm going to stick with JDK 1.4, I've got the JDK and the JRE, and that's it". Even if Sun were to be sold, and the new owner were to try and kill off Java, it wouldn't work. I kinda like that.
With Microsoft, you might not be able to get away with that, because Windows Update changes all sorts of things, including the.Net framework, which could theoretically alter your programming environments one day. Also, their new EULAS indemnify them from any damages their updates might cause. So if they change everything and break all your old C# software, you end up having to either use an unpatched O/S with your old C# setup, or you have to bite the bullet and go along with their changes. This makes me a little nervous.
Still; I don't know if that's enough for me to give up on C#. It IS a cool language...
It's not that I wouldn't use it, exactly... It's just that the libraries are proprietary and thus kind of an unknown factor that could be a problem down the road. But I agree with you 100% on the free/standard implementation point; if Microsoft were to submit the libraries to ECMA, for instance, or even totally free up all the libraries for use, C# would be a whole lot more desirable.
So, employers -- who have been canning people right and left, and who post ridiculous job descriptions so that they can justify outsourcing positions instead of hiring for them -- are now experiencing a crisis in which the masses of unemployed and desperate people are sending them resumes that, by law, they must track and store? How amusing. I noticed that they're trying to call unsolicited resumes "spam", as though an unemployed and desperate worker is somehow committing a sin in attempting to find work. How compassionate HR managers are! How touching is their depth of feeling for their fellow man.
Of course, what is *really* funny is, these idiots are so technically inept that they consider dealing with a few thousand resumes *difficult*. Perhaps if they hadn't fired all the tech staff, someone in the office would be able to do the following:
1. Set up a shared directory on one of the office PCs, mapping that as a network drive for everyone else.
2. Inform people that whenever a resume comes in, they should save it to the shared drive in a subfolder named after the "applicant", along with attachments.
3. Have someone periodically dump the shared drive to a CD-Rom (say, when the shared folder hits 500MB?). Write the date on the CD label, and store it somewhere convenient. Then, clean out the shared folder.
4. Stop worrying and let all the HR suits go back to playing solitaire and tormenting "applicants".
Oh, but you'll say, "they get and track paper resumes, too -- what now, shared-folder-boy?"
Easy enough. On the same PC where you're storing the emailed resumes, hook up a fifty dollar scanner. When a resume comes in, have one of the interns scan it and save it in the shared directory and subdirectory named after the person. The additional space being used just increases the rate at which you're burning CDs.
Wanna go back and find someone's resume? Fetch the CD for the approximate time span in which the resume was sent and look the person up. This should take maybe ten minutes (including walking down to the file closet and digging up the CD).
Unless you're IBM or something, this should be more than sufficient. Companies like IBM have enough staff to create something a little more comprehensive.
Of course, most companies DID fire all the tech staff, so they're probably shit out of luck. Maybe if they give the homeless webmaster who sits in front of their building a doughnut or something, he'll put something together for them. Who knows? Or he might just spit in their eye, kick them in the shins, steal the doughnut, and walk away, muttering about "PR Flacks"...
An A/C said: "So you using the.NET platform but he's making you use VB instead of C#. Sucks to be you."
Tell me about it. Here's something funny: the reasoning for this decision was as follows:
1. We have lots of VB6 guys around, and most of them are pure-VB guys. So they learned programming by learning VB, and only know the "VB way" to do things (can you say, ".Net disaster in the making"?).
2. If we move to C#, all the VB programmers will find this intimidating. Plus, we won't be able to find anyone to take over a project if a programmer leaves, is fired, or gets hit by a bus. (the fact that the VB6 guys won't be able to take over a VB.Net project either, because it's totally different from VB6, well, that isn't being acknowledged).
3. VB.Net is, according to several people in my organization, "just like C# anyway, except for the syntax" so my boss doesn't see any reason to choose C#.
I think the whole thing centers around some kind of weirdo psychological, subconscious name recognition thing. They've got the "VB" mantra going in their heads. There's no escape.
Sigh... At least I can code in Java at home. That keeps me sane.
The base language C# is, but not the libraries you'd use to build actual software. Those are still entirely proprietary, so if you want to actually *do* things, you'll need to use a proprietary tool (a library). This implies some degree of dependence on the vendor that supplies that tool, which is what a lot of people don't like about proprietary languages.
However, there is one nice thing about C#; since it's been accepted as a standard, the language itself won't be likely to change very often. So, really, you are just getting new libraries when you add functionality to it -- which is a very cool thing.
But I'd like to see an open-source, public implementation of the library. That would really be a nice thing.
Re:Not just from its libraries
on
Hijacking .NET
·
· Score: 1
Well, that's true, and I'll admit that C# seems to have taken all of the good things that were in Java while trying to avoid some of the bad. But if you want to actually *do* something with it, you'll need the libraries. And, the libraries are proprietary, which means that you could become dependent on them only to find out one day that they're no longer available (taken off the market, replaced by something else you don't like, etc). Private companies are fickle. They may or may not continue to support a product.
I'm not saying that'll happen here. And, of course, someone might come out with an open version of the libraries, which turns out to be just as useful as the proprietary version. That would be great. And, probably, C# will be just fine. I'm just saying I understand the point of view of people who like more freedom with their software. I think their main concern is securing their access to a tool indefinitely.
I think you can make a case that the relative freedom of C++ *does* make it more useful in a certain sense, i.e. the sense that it's yours forever and no one can take it away from you, so if you build that skill, it never has to become obsolete... I really do see how attractive that is, especially with all the corporate nefariousness going around. Plus, they're coming out with some pretty cool libraries for C++, all available on Sourceforge. I don't know if I'd say they're as good as the huge libraries you get with Java, but still. They're there, they're free, forever. That's pretty significant I think.
Yes, but the problem with C# is that the usefulness of C# comes from its libraries, which haven't been opened up as an ECMA standard. And, I'd bet they're protected in a variety of IP-related ways by Microsoft. So it's not like anyone who wants to can just roll his own full-featured C#. Even Borland, which came out with their own C# IDE recently, uses the Microsoft compiler behind the scenes (and if even Borland doesn't try to roll their own, do you think very many others will?). So C# isn't the open standard you might think it is -- it is definitely proprietary.
I don't think you should be modded down. It's an interesting point. Open source types do sometimes tend to "overlook" the shortcomings of C++ (and their other favorite languages like Perl, Python, Ruby, etc) because it's a political thing for them, and you end up getting into these big propaganda wars. You could say they're "drinking the kool-aid", just like all the frothing, rabid managers back in the dot-com days used to.
But I think most open-sourcers are a little more sedate than that; they like C++ because C++ is completely free and nonproprietary (gcc is GPL, and C++ has been an ANSI standard for way over a decade, hasn't it?). So, in a sense, it's a language that no one can ever take away from you, and which has been more or less frozen in its current state (new functionality is generally handled with additional libraries) for years. C# and Java, on the other hand, are proprietary languages, so it is theoretically possible for the companies that own those technologies to change them on a whim, or even kill them off. I sympathize with this view somewhat, but I don't fully agree with it.
Is the "freeness" of a tool enough to support its use? Should we choose our tools based on how free they are, or on how useful they are to us? How do you pick a compiler, really? It's interesting.
I like Java, personally. It has pretty nice features and a rich API. I lust after C# somewhat, but my boss won't let me use it (he likes VB.Net -- pity me).
Thanks! I've acquired the card, now I have to get it working. I'm having similar problems with this one, specifically, when the kernel tries to access the card, it times out. The card lights up, and it's doing something (probably trying to get DHCP data) but I can't access the network yet. I'm going to try and figure it out tonight. Getting it working will be worth the effort, I think.
I think I've found something useful. I've been checking all of the common outlets to try and find a steady source of the PCMCIA ethernet cards that are listed in the compatability list, and it's been pretty slim pickings... My best luck was with Linksys, because their EC2T, PCMPC100, PCM100, and PCMLM56 cards were all available at CompUSA and supported -- most by mail order, though. Only the PCM100 is available in-store, in an upgraded version called the PCM100-CU. I'm going to give that one a whack tonight; it claims to support Linux out of the box, so there's no risk whatsoever in purchasing it to try out FreeBSD. Cost: 39.99. Not bad, eh?
I also noticed that Intel bought Xircom, but luckily, they're still going to be manufacturing three of those cards: The Xircom 10/100 Network PC Card Adapter, the Xircom CreditCard Ethernet 10/100, and the Xircom CreditCard Ethernet 10/100 + modem (apparently only the ethernet part is "known" to work).
So, that's not bad, right? At least there's a supply of a set of cards that can be used. So, wish me luck; I'm going to head over to CompUSA and try and score a card tonight (while I also pick up "Enter the Matrix" of course! Priorities are a FreeBSD test and gaming; dinner, sleep and personal hygeine can wait in the queue).;)
Slashdot Mirror
All your IP are belong to us!!!
Thanks! I've added you to my friends list too. :)
It wasn't a bad idea, really -- you had the right motivation. It's just... I couldn't stand the idea of doing anything nice for the people who are behind this thing. It would be physically painful to me. ;)
Except for one thing. You live in the EU (I'm guessing Great Britain, because you listed monetary amounts in british pounds), but the original poster and I live in the United States. So, your observations about how things work in Britain have no bearing on how things work here. It may very well be that patents are managed more effectively in Britain and the EU than in the United States (my gut feeling is that they are). But, remember -- over on THIS side of the pond, the patent and IP situation is completely, hopelessly out of control. It's been a joke for so long that it's starting to be considered a cliche.
Seriously. An American complaining about an inane patent system is probably complaining about HIS, not YOURS. From the sound of it, things aren't quite as bad over there.
The solution to your concerns is to make sure that the ONLY people permitted to develop for the kernel are pre-vetted to ensure they have no conflicts of interest; for example, kernel development could be shared by teams at Red Hat, IBM, SUSE, etc. Restrict the set of people who can code for the kernel, institute mandatory background checks and tests for conflicts of interest, and the problem goes away.
Everyone would be *permitted* to suggest kernel patches, but these patches would have to be completely recoded from scratch, only using the algorithm provided rather than any actual code. And, the contributions of each kernel developer would be extensively tracked in some way.
Maybe being paranoid is the only safe approach.
Actually, that looks like they're just passing along the system-generated message (java.lang.NullPointerException) with a note about the location in the code where the error took place (the routine that creates a transform handler). The programmer would probably be able to make perfect sense out of it. Remember, error codes aren't for users, they're for developers.
But, wouldn't it bother you to reward the assholes who are behind this? Why should they succeed and get their buyout? Let them dry up and blow away, as they should. I hope they lose money hand over fist, and that IBM buries their company deep and dark, Joe Pesci style.
So, did your cruel and wretched retaliation against this poor hopeful employee make you feel powerful and important? Do you feel like a big man, because you mercilessly stripped some poor unemployed guy of his internet connection? And, over what? His harmless sending of a resume in hopes of working with you? Do you feel like more of a man, now that you've shown yourself to be a beast?
You've done more than beat on the downtrodden; you have made yourself into the type of person who beats on the downtrodden and has the gall to brag about it on Slashdot. As such, you are insignificant to me. You simply don't exist.
Wanted: HR Drone.
Come work for a company on the cutting edge! Here at S**, we don't make products; we sue over them! As a newly hired HR Drone, every day will be exciting, whether you're arguing with the teamsters over whether lead plates constitute heavy loads, dodging a falling pallet of resumes as it crashes down into accounting (freeing up positions and jump-starting our economy), or using your brawn to muscle those resumes onto our industrial scanner for permanant storage! Ambitious, energetic applicants may find themselves managing our lead smelting operation -- why pay money for a gym sauna, when you can be promoted into one!
Requirements:
Must be able to lift 60 pounds; must be able to operate industrial equipment; must be able to use a computer and scanner. High pain threshhold desireable. Salary DOE. EOE. Unlucky workers DOA.
Ah, but the real question is, would Bob's replacement look up at the hole in the ceiling, and down at the big red dent in the floor, and decide he *really* wanted to go back to school instead?
I don't think it actually *costs* a company much to do something like this. The staff that would be doing it are generally on salary, so they would either be doing this or playing solitaire. The real thing the companies are kvetching about is that they have to actually *work* on resumes they would rather just delete. It's a minor irritation for the HR flacks, that's all. As for me, I couldn't care less that Susie HRDrone has to spend twenty minutes copying resumes instead of looking at her french nails. They ought to quit complaining; at least they're working! ;)
But, in all fairness, you're right about one thing: the government is filled with useless, stupid bureaucracy. I get pretty fed up with it sometimes, myself.
I agree with you that C# is a pretty cool language, and probably a "step forward" as you say, but the fact that only part of the language has been okayed by ECMA still bothers me somewhat. They should have standardized the libraries, too, with any new stuff they want to build going into add-on libraries. This doesn't mean I wouldn't use C#, of course. It's a nice language. I'm just saying I understand the point of view of people who would rather it were "free".
.Net framework, which could theoretically alter your programming environments one day. Also, their new EULAS indemnify them from any damages their updates might cause. So if they change everything and break all your old C# software, you end up having to either use an unpatched O/S with your old C# setup, or you have to bite the bullet and go along with their changes. This makes me a little nervous.
Java has some of the same problems, although the fact that there are more than one vendor supplying development kits makes Java a little "safer" (you've got Sun's JDK, Blackdown, and IBM, plus GCJ is in progress, etc). Plus, according to the Java license, once you've got a JDK, you can basically use it forever unless you violate it (by trying to "pollute" java, for instance). Client software doesn't understand java? Give them a JRE along with your app. See? It's a little "safer" in a sense, in that you can just say, "Ok, I'm going to stick with JDK 1.4, I've got the JDK and the JRE, and that's it". Even if Sun were to be sold, and the new owner were to try and kill off Java, it wouldn't work. I kinda like that.
With Microsoft, you might not be able to get away with that, because Windows Update changes all sorts of things, including the
Still; I don't know if that's enough for me to give up on C#. It IS a cool language...
It's not that I wouldn't use it, exactly... It's just that the libraries are proprietary and thus kind of an unknown factor that could be a problem down the road. But I agree with you 100% on the free/standard implementation point; if Microsoft were to submit the libraries to ECMA, for instance, or even totally free up all the libraries for use, C# would be a whole lot more desirable.
Amusing thought: what if people decided to send the resumes in, written in permamant marker on clay shingles? Or better, engraved on lead plates?
"Um, Sir? We just got a shipment of 973 new lead-plate resumes. Some are several pages long, mostly system administration experience."
"Crap. What next? Put them in the file cabinet."
"We did, sir, but they fell through the floor and killed Bob in Accounting."
"Damn! Send someone down there with a come-along and move them down to the basement with the others..."
So, employers -- who have been canning people right and left, and who post ridiculous job descriptions so that they can justify outsourcing positions instead of hiring for them -- are now experiencing a crisis in which the masses of unemployed and desperate people are sending them resumes that, by law, they must track and store? How amusing. I noticed that they're trying to call unsolicited resumes "spam", as though an unemployed and desperate worker is somehow committing a sin in attempting to find work. How compassionate HR managers are! How touching is their depth of feeling for their fellow man.
Of course, what is *really* funny is, these idiots are so technically inept that they consider dealing with a few thousand resumes *difficult*. Perhaps if they hadn't fired all the tech staff, someone in the office would be able to do the following:
1. Set up a shared directory on one of the office PCs, mapping that as a network drive for everyone else.
2. Inform people that whenever a resume comes in, they should save it to the shared drive in a subfolder named after the "applicant", along with attachments.
3. Have someone periodically dump the shared drive to a CD-Rom (say, when the shared folder hits 500MB?). Write the date on the CD label, and store it somewhere convenient. Then, clean out the shared folder.
4. Stop worrying and let all the HR suits go back to playing solitaire and tormenting "applicants".
Oh, but you'll say, "they get and track paper resumes, too -- what now, shared-folder-boy?"
Easy enough. On the same PC where you're storing the emailed resumes, hook up a fifty dollar scanner. When a resume comes in, have one of the interns scan it and save it in the shared directory and subdirectory named after the person. The additional space being used just increases the rate at which you're burning CDs.
Wanna go back and find someone's resume? Fetch the CD for the approximate time span in which the resume was sent and look the person up. This should take maybe ten minutes (including walking down to the file closet and digging up the CD).
Unless you're IBM or something, this should be more than sufficient. Companies like IBM have enough staff to create something a little more comprehensive.
Of course, most companies DID fire all the tech staff, so they're probably shit out of luck. Maybe if they give the homeless webmaster who sits in front of their building a doughnut or something, he'll put something together for them. Who knows? Or he might just spit in their eye, kick them in the shins, steal the doughnut, and walk away, muttering about "PR Flacks"...
An A/C said: "So you using the .NET platform but he's making you use VB instead of C#. Sucks to be you."
Tell me about it. Here's something funny: the reasoning for this decision was as follows:
1. We have lots of VB6 guys around, and most of them are pure-VB guys. So they learned programming by learning VB, and only know the "VB way" to do things (can you say, ".Net disaster in the making"?).
2. If we move to C#, all the VB programmers will find this intimidating. Plus, we won't be able to find anyone to take over a project if a programmer leaves, is fired, or gets hit by a bus. (the fact that the VB6 guys won't be able to take over a VB.Net project either, because it's totally different from VB6, well, that isn't being acknowledged).
3. VB.Net is, according to several people in my organization, "just like C# anyway, except for the syntax" so my boss doesn't see any reason to choose C#.
I think the whole thing centers around some kind of weirdo psychological, subconscious name recognition thing. They've got the "VB" mantra going in their heads. There's no escape.
Sigh... At least I can code in Java at home. That keeps me sane.
The base language C# is, but not the libraries you'd use to build actual software. Those are still entirely proprietary, so if you want to actually *do* things, you'll need to use a proprietary tool (a library). This implies some degree of dependence on the vendor that supplies that tool, which is what a lot of people don't like about proprietary languages.
However, there is one nice thing about C#; since it's been accepted as a standard, the language itself won't be likely to change very often. So, really, you are just getting new libraries when you add functionality to it -- which is a very cool thing.
But I'd like to see an open-source, public implementation of the library. That would really be a nice thing.
Well, that's true, and I'll admit that C# seems to have taken all of the good things that were in Java while trying to avoid some of the bad. But if you want to actually *do* something with it, you'll need the libraries. And, the libraries are proprietary, which means that you could become dependent on them only to find out one day that they're no longer available (taken off the market, replaced by something else you don't like, etc). Private companies are fickle. They may or may not continue to support a product.
I'm not saying that'll happen here. And, of course, someone might come out with an open version of the libraries, which turns out to be just as useful as the proprietary version. That would be great. And, probably, C# will be just fine. I'm just saying I understand the point of view of people who like more freedom with their software. I think their main concern is securing their access to a tool indefinitely.
I think you can make a case that the relative freedom of C++ *does* make it more useful in a certain sense, i.e. the sense that it's yours forever and no one can take it away from you, so if you build that skill, it never has to become obsolete... I really do see how attractive that is, especially with all the corporate nefariousness going around. Plus, they're coming out with some pretty cool libraries for C++, all available on Sourceforge. I don't know if I'd say they're as good as the huge libraries you get with Java, but still. They're there, they're free, forever. That's pretty significant I think.
You might be right; I like your point of view.
Yes, but the problem with C# is that the usefulness of C# comes from its libraries, which haven't been opened up as an ECMA standard. And, I'd bet they're protected in a variety of IP-related ways by Microsoft. So it's not like anyone who wants to can just roll his own full-featured C#. Even Borland, which came out with their own C# IDE recently, uses the Microsoft compiler behind the scenes (and if even Borland doesn't try to roll their own, do you think very many others will?). So C# isn't the open standard you might think it is -- it is definitely proprietary.
That's it? I thought it was longer; maybe it was in the works for a while. I seem to remember people talking about it from way back.
I don't think you should be modded down. It's an interesting point. Open source types do sometimes tend to "overlook" the shortcomings of C++ (and their other favorite languages like Perl, Python, Ruby, etc) because it's a political thing for them, and you end up getting into these big propaganda wars. You could say they're "drinking the kool-aid", just like all the frothing, rabid managers back in the dot-com days used to.
But I think most open-sourcers are a little more sedate than that; they like C++ because C++ is completely free and nonproprietary (gcc is GPL, and C++ has been an ANSI standard for way over a decade, hasn't it?). So, in a sense, it's a language that no one can ever take away from you, and which has been more or less frozen in its current state (new functionality is generally handled with additional libraries) for years. C# and Java, on the other hand, are proprietary languages, so it is theoretically possible for the companies that own those technologies to change them on a whim, or even kill them off. I sympathize with this view somewhat, but I don't fully agree with it.
Is the "freeness" of a tool enough to support its use? Should we choose our tools based on how free they are, or on how useful they are to us? How do you pick a compiler, really? It's interesting.
I like Java, personally. It has pretty nice features and a rich API. I lust after C# somewhat, but my boss won't let me use it (he likes VB.Net -- pity me).
SN74S181 ill-advisedly said, "Really, whoevevers been giving you flaming lessons sucks, boy."
Um... See, that would be YOU -- you're the one flaming me, and receiving my more polite replies.
So, it seems you suck... I'm not gay, personally, but I wouldn't dream of judging your alternative lifestyle. Out of morbid curiosity, do you swallow?
Give it up, old man. You're pathetic.
Thanks! I've acquired the card, now I have to get it working. I'm having similar problems with this one, specifically, when the kernel tries to access the card, it times out. The card lights up, and it's doing something (probably trying to get DHCP data) but I can't access the network yet. I'm going to try and figure it out tonight. Getting it working will be worth the effort, I think.
Thanks again!
Phil
Hey, Zulux:
;)
I think I've found something useful. I've been checking all of the common outlets to try and find a steady source of the PCMCIA ethernet cards that are listed in the compatability list, and it's been pretty slim pickings... My best luck was with Linksys, because their EC2T, PCMPC100, PCM100, and PCMLM56 cards were all available at CompUSA and supported -- most by mail order, though. Only the PCM100 is available in-store, in an upgraded version called the PCM100-CU. I'm going to give that one a whack tonight; it claims to support Linux out of the box, so there's no risk whatsoever in purchasing it to try out FreeBSD. Cost: 39.99. Not bad, eh?
I also noticed that Intel bought Xircom, but luckily, they're still going to be manufacturing three of those cards: The Xircom 10/100 Network PC Card Adapter, the Xircom CreditCard Ethernet 10/100, and the Xircom CreditCard Ethernet 10/100 + modem (apparently only the ethernet part is "known" to work).
So, that's not bad, right? At least there's a supply of a set of cards that can be used. So, wish me luck; I'm going to head over to CompUSA and try and score a card tonight (while I also pick up "Enter the Matrix" of course! Priorities are a FreeBSD test and gaming; dinner, sleep and personal hygeine can wait in the queue).