I never said anything about standards. The first time they rejected my browser version because it wasn't yet supported, that was the first thing I thought: so long as they're coding to standards, what's the big deal?
But how many browsers are 100% standards-compliant?
Coding to standards can cause unexpected (and potential insecure) things to happen on browsers or environments that are not up to standards.
How do you tell? You test and certify.
And to answer your question: The site www.bankofamerica.com is running Netscape-Enterprise/3.6 SP3 on Solaris. I don't know if that's what their account management stuff runs under, though. I don't think that the issue was "Windows vs. Linux" but "Mainstream vs. any of the Linux browsers he had at his disposal". Maybe he didn't have access to a browser that his bank did support (under Linux). I don't know.
I really can't believe a user experience like this is new to you. The very fact that you're hearing it now will hopefully clue you in to what life is like in the non-optimal real world.
Wide-scale Linux deployments have worked for, primarily, two reasons:
1. The new Linux installations were, in general, not designed to replace a totally-flexible Windows configuration. Generally, these installations are more akin to point-of-sale operations, or for configurations that have a very limited range of use and do not need a huge application base for their users to be productive.
2. Those Linux implementations were well-planned, well-thought-out and well-engineered. Generally a small team went through, selected a list of the appropriate applications, built a custom distribution or post-installation checklist and custom-tailored the OS to their environment. Most large corporations even do this with Windows.
Your experiences with FreeBSD and your non-tech staff are not necessarily representative of everyone else's. Just as you find it difficult to believe the original poster's story of difficulties, I find it difficult to believe a moderate- to large-scale conversion to FreeBSD or Linux as a Windows desktop replacement (for all-purpose tasks) as you're describing would go without a hitch or a noticable loss of productivity.
That doesn't mean I wouldn't consider your comments valuable. Clearly some people are having successes in some configurations and others are having problems in other configurations.
Fire them and replace them with what? If all of the "non-technies" had a hard time with the environment, what makes you think it's going to be easy (or cheap) to drop in replacements that can? Any mention of these things in a job posting will scare off any potential non-techie (but flexible) folks, and will tend to draw technie (and more expensive) people to their place. If all you want is a 100% techie shop, that's certainly a noble goal, but it isn't realistic in the real world.
Banks also have to certify their sites for functionality, privacy and security before they'd be willing to say, "We support this browser." Either they certify the myriad of Linux-compatible solutions at significant additional cost (for what, a 0.5% increase in potential online customer base?), or they do it half-assed and say, "Should work, go for it." There is logic on both sides of the fence here, but it's a business decision to be made by the bank. A bank that refuses to accomodate browser versions it's not able to personally certify as up to the task is arguably one that's safer, where I'd be more comfortable banking online. I have yet to find a bank that would consider supporting non-mainstream (and/or untested) browser versions.
The original poster is right: Linux is not 100% up to the task yet. Don't get pissy with that conclusion, ask what the problem is and fix it so that it isn't a problem anymore.
Every 6 months or so I bring a couple of my Linux systems up to date as far as the X, KDE and Gnome stuff goes, and spend a day or two trying to make it a usable desktop. For the most part, it's quite usable, but it's always lacking a fluidity of interface that other GUI-native operating systems (MacOS, Windows) have nailed. There is also a training overhead involved for people that have been "classically" trained on Windows. Sitting friends down in front of it, even after brief periods of experimentation, they still end up having to ask me how to do simple tasks. The naming of some applications in Linux leaves a bit to be desired.
I will continue using my Linux systems for what they're best at: server tasks. It's all about using the best tool for the task. Linux is not the best tool for all tasks.
Except I'm still kind of confused as to why this is a privacy invasion.
How can company B handle company A's warranties, catalog preferences, refunds, replacements, pending orders, etc., if company B buys and/or merges with company A but company A destroys its own customer lists...?
I don't understand what company A (Egghead) could have or would have done differently in this case that would cease to make this a privacy problem.
It looks like it's just a simple transfer of customer data, kept under the same privacy policies that Egghead had. If you didn't like those privacy policies, why did you give them your information? Companies are bought out and merged all of the time. Do you really expect them to destroy their own customer records every time this happens?
The only reason we're seeing this issue now is because Egghead did the RIGHT THING by allowing their customers to opt out prior to the transfer. This is a very noble and privacy-friendly thing to do. It would be nice if every company did this as part of its data transfers.
Sounds like you need to upgrade or re-configure your web browser to honor your preferred e-mail client.
Or you could just send them an e-mail (clearly you found the address) or call the provided 800 number. There are few things this company could do to make this process easier for you.
If you have a beef with Egghead as a company, that's your business, but they are doing everything they can to do the Right Thing here, and I applaud them for it, even if they've been the subject of misfortune in the past.
Their opt-out process was very quick and painless for me after I received the e-mail notice. I only bothered to opt-out because I had no intention of doing business with them in the near future.
If you had actually read the e-mails they sent out (which would make you actually involved in this topic instead of just posting on Slashdot without all of the facts), you would have read that the arrangement requires Fry's to honor the existing Egghead privacy policies. Your data will not be used in any way counter to the policies that were in place when you signed up with Egghead in the first place.
This is just a straight transfer of data from one company's flag to another's, under the same policies and restrictions.
Stop being melodromatic about giving up all of our rights. I really cannot believe this topic is generating this amount of negative attention. I wish more companies were as open and pro-active about their customers' privacy. There isn't much more that Egghead could have done in this case, and it's silly to expect that they would just destroy their customer lists. How is Fry's to handle things like returns, warranties, catalogs, etc., if they don't have this information?
Maybe you didn't get an e-mail because they, for whatever reason, don't have your e-mail address? If they aren't able to contact you, chances are, the company they sell this data to won't be able to contact you either. What exactly is the problem?
If the new company *does* contact you, without warning, *then* I would be concerned...
If you deploy your software smartly, you will rarely ever have problems like the other doomsayers say. Set up a test environment and trial products before you roll them out and mandate their use. If you experience problems, a support contract helps in getting those problems corrected, all without the user even knowing. When you're ready, deploy.
But this forces everyone to change to a Windows desktop!
What percentage of employees in your company do not have a Windows PC sitting at their desk? Most people can safely say that number is negligible, but in the off-chance you have an office filled with Linux or Solaris users, I guess this could be a factor.
But this forces everyone to use Outlook!
Some might consider this a good thing, but be aware that there are web-enabled versions of Exchange/Outlook that allow you to access your corporate mail from a web page. Secure it and firewall it if you're worried about security, or make it available only to employees dialed into your Intranet.
Doesn't Exchange also offer POP support (maybe by a 3rd party if nothing else)? Is there anything stopping you from using your existing mail clients?
I'm a Unix guy. I work on several Solaris systems every day, code a bit in C, a bit more in Perl. My company has also standardized on NT desktops and Outlook for e-mail. As much as I hate to admit it, Outlook is extremely powerful, and the ability to coordinate appointments and the like makes Outlook very attractive, especially when every employee in the company is guaranteed to be compatible with the system. I don't usually have to worry if so-and-so can read the attachment I'm about to send him because he has the same setup as I do. Homogenous desktop environments is a huge boon to inter-office communication.
Then by using GPL'ed software in the stuff you produce for class, you are preventing them from doing this legally.
Besides, this is all going under the assumption that the university has a legal right to claim ownership of the stuff you produce in class anyway. I don't recall ever signing a contract mentioning that when I was in college. In the absense of such an agreement, the stuff I produce is mine and mine alone, and aside from 'fair use' (and the implicit permissions I'm giving the prof by turning my work in), they have no right to my works.
Stop thinking about GPL'ed code like that. It's a "parasitic license", with the operative word being "license". You can freely add whatever proprietary (and copyrighted) bits of code to a GPL'ed application that you want. The license's sticky point is the fact that you cannot redistribute it without surrendering all of your additions to the GPL.
Thus, a company can control an application based on GPL'ed code with proprietary/copyrighted additions and do whatever they want with it, so long as it stays within the company. They can't sell it nor can they make it available to anyone else without making the whole thing GPL'ed and giving up the source of their proprietary changes.
If it's GPL'ed, IBM would supposedly retain the copyright over the code added/modified by the employee, making the resulting code undistributable under the GPL. Remember: you can modify and add whatever proprietary bits to GPL'ed code that you want, you just can't redistribute it.
I'm sorry but if somebody threatens to DoS me over IRC, and then proceeds to do so, CALL THE POLICE. CALL THE FBI. You know who he is. You know where he's IRCing. Log the information, and TRACK THE ASSHOLE DOWN. If he's IRCing from his own ISP (unlikely, but IRC is full of stupid kids), call the ISP and shut the account down. If he's bouncing from one or two sites, look up the IP address (do a WHOIS against ARIN) and call them up. Solicit their help in tracking him down. It should be obvious where he's connecting from (a 'finger' or 'netstat' should make that apparent, assuming the machine isn't compromised, in which case a network sniffer or 'tcpdump' will let you do the same), and back-track.
I know we all seem to think script kiddies have these l33t ways of hiding their identities, but it all boils down to a few responsive phone calls and you can nail anybody back to their ISP. Any competant ISP will have caller ID records for the incoming call. Granted, they won't give you this information, but they will certainly note it. Let the feds do the rest.
Why do people not even think about taking these steps? If you can't reach an ISP's network center, GO OVER THEIR HEADS. Contact their uplink.
The more we whine and say DoS attacks suck, and the more we DON'T pursue and put these fuckers in jail and slap enough damages on them so their parents lose their house and car, the more powerful and untouchable they feel, and the more bolder they get.
Anyone from any OO camp will instantly be able to recognize that and understand what it's doing. I fail to see what you are trying to bash here.
As far as Perl's global variable issue, this is a necessity brought on by the fact that Perl isn't just built to write large scripts/applications. It's built to handle small one-liners as well. Forcing strict variable declarations (which is highly recommended with any medium to large script, and enforced with the use strict; pragma, would completely solve the problem you're ranting about) would prevent readable one- and two-line-style scripts. Ever seen the "RSA in 3 lines of Perl" type.signatures?
chdir($dir) or die "Couldn't chdir to $dir: $!"
What is so difficult to read or understand about this? Any programmer that has never seen Perl before should be able to understand the above. This is an example of a stock Perl function and stock Perl error handling. The only thing that may not be apparent is the $! variable, but it's pretty easy to see what it is just by looking at context. What is the problem with this?
Finally, if you dislike Perl, don't use it! Why are you even reading a Perl forum? Why are you going in depths of comments and why, for God's sake, are you participating? Do you just like conflict? Are you trying to get people angry with you so you can get angrier back at them? Why?
Re:Mantra = Perl does what ever I want.
on
Perl 6 Showcase
·
· Score: 3
Wow, I don't think I've ever met anybody as anti-Perl as you.. I think the main problem you have with it is the fact that the syntax can be so varied. This allows for very elegant and efficient code, but at the same time, inexperienced programmers can abuse that lack of strict syntax and write something that's very difficult to read.
Find a good Perl programmer, and not somebody that's just learned Perl and likes to tinker with it (there are thousands of these!), and you will find some very readable Perl code. Sounds like you've been bitten by a poor Perl programmer and asked to maintain his code perhaps?
Seriously, a bad programmer in any language is going to write a badly written program. The code will be difficult to read and maintain. In many other languages, though, stricter syntax forces the programmer into a certain style, so you mitigate the amount of damage they can do (a badly written piece of code simply may not compile). Perl is enormously flexible, with syntax and modules to do anything, which means poor/beginner programmers can Get Stuff Done with little knowledge, effort, and sadly, little programming abilities.
Perhaps you should be working to better educate the developers around you (or hire better ones) instead of dissing a language that obviously is not going away and obviously has a very practical and valid use in just about any field.
Re:Mantra = Perl does what ever I want.
on
Perl 6 Showcase
·
· Score: 2
I had a similar experience trying to change my *contact* information. The e-mail address in one of my contact entries had become invalid, and I could not get anything done for a solid 9 months, after phone calls, 3 faxes (at the request of the person I spoke to on the phone, two of which were sent *directly to the tech*), and repeated e-mails.
After 9 months of this crap, I transferred my domain to register.com. All it took was a notarized copy of the form and a photocopy of my driver's license. My bank across the street did this for free. Once I got that to them, the only delay was waiting for Network Solutions to "authorize" the domain transfer (apparently they still have a form of veto power in case you don't pay your bills, whatever). It took like 2 days to get a response (a new record for NSI!), as I recall, and the following day to get the WHOIS servers updated.
I have been INFINITELY impressed with the speed and flexibility of register.com, when compared to NSI. All changes to most any bit of information about your domain are all AUTOMATED and require only that you confirm the change via e-mail. It takes 2 minutes, tops, and the servers are updated by the next day.
I imagine most ANY other registrar will give you comparable service. Fuck NSI.
I would wager most companies that institute any sort of e-mail monitoring policy only go that deep into message contents when an employee is under active investigation. Even the most paranoid of companies typically log only the presence of messages, or individual HTTP requests made, never actual content.
To those that say, "People have always been saying EFnet is dying, but it's still here, and it will be around for a long time to go!" I agree, only insofar as EFnet will not go away.
But isn't an IRC network effectively dead when it ceases to be a reliable means for people to get online and chat? When was the last time you could get onto your EFnet channel of choice and have a conversation with the regulars? I bet if you did the math, EFnet would spend over 50% of its time with at least one major server split or with one or more heavily hit links.
When I sit down and am totally unable to have a conversation with my friends for any more than a few minutes at a time, I consider it time to move on. The only way people are going to be happy again is if they migrate to a more stable network, and nobody is going to do that until EFnet finally kicks the bucket and its existing (stable) servers either join up with a real IRC network or shut down for good.
It's an issue of trust. A rogue IRC server can introduce any command into the IRC network that it wants. If there weren't any other opers watching the network, that server could cause anarchy.
They also require servers with large pipes for a reason: the IRC2 protocol is not very efficient. It's entirely ASCII-based and depends on things like connections, quits and channel messages to be propogated throughout the entire network. Thus, your private server wouldn't necessarily just be seeing traffic it needs to see, it would be seeing ALL traffic across the network.
Ordinarily, this amount of data isn't too bad. An ISDN link could probably handle it. The problem is the connect bursts. When two servers split, as you know, each server on the local side of the split sends out QUIT messages for each client that has now disappeared on the other side. If this is a major hub, this burst in itself is quite large. In addition, when servers reconnect (such as when your private server connects to the network or when a split server reconnects), a much larger connect burst occurs, as each client on the "other" side is introduced to the local side. JOINs (well, SJOINs) have to be sent as well, so that all servers have enough state information about what clients are on what channels that they can provide that information to the local user.
In short, IRC2 needs "HUGE pipes".
Yes, it could be designed better. Yes, there are better IRC network designs on the way, but there's little that can be done to fix IRC2.
Limiting a server to local clients has always been an acceptable and practiced policy among EFnet servers. Generally if a server is capable of being open and handling non-local clients, it should do so, but if an ISP has a sizable population of IRC users, and sufficient hardware to support those users and little more, it makes sense for that ISP to set up its own dedicated IRC server for its customers, and to link that server to EFnet.
AOL and Netcom are prime examples of large providers that have opted to build their own IRC servers for their own clients. Unfortunately (mainly in AOL's case), they didn't feel obligated to police their own servers, and abuse was quite rampant.
In the beginning, there was IRC. IRC was good, people got along, and chatting was what people did.
Then there were some differences of opinion between administrators. It's OK, these things happen. Feelings got hurt, EFnet spawns a child network. Increasingly, this happens more and more, but typically the arguments revolve around the introduction of features to give the user a better chatting environment.
There are always two sides to the argument. There are those that want things like channel ownership, more IRC operator participation in the affairs of mortals and harsher, coordinated controls against abusers of the service. Then there are those that don't want anything to change. They view IRC operators as the keepers of the links, and that those keepers should never meddle in the affairs of the users. Let them sort (battle) out their own problems. EFnet splits. The liberal operators and servers (the ones wanting the change) spawn off a new IRC network, and the conservative/reactionary operators and servers stay behind.
Think of it as evaporative cooling. As EFnet experiences its civil wars, the proportion of "to hell with the users" attitudes rises.
Eventually, this attitude starts biting the opers and admins on the ass. EFnet turns into a war zone, with DoS attacks starting to show up. A few users think they're funny and DoS the opers too.
The ugly dragon rears its head.
Now the attitude becomes "fuck everyone but my fellow opers". IRC wars move from the IRC playfield to the Internet with DDoS attacks taking down servers for the purposes of channel warfare and retaliation against opers and admins. Sometimes the ill feelings are warranted, but mostly the packet kiddies are just trying to make a nuisance of themselves. Networks suffer, ISP customers suffer, ISP's de-link their IRC servers. A free service (IRC) should not--must not--impact the ISP's ability to reliably serve its customers.
Now at this point, EFnet starts getting a shortage of big servers. Naturally there are dozens of ill-experienced, IRC savvy packet kiddies that have "grown up" a bit and want to try their hand at running servers. A few are cautiously linked in, oper abuse (already rampant on EFnet) begins to rise even faster. The line between oper and kiddie twists around a bit, more servers run by "former" (or current) packet kiddies, Internet wars abound, servers are split, packet kiddies continue to attack. Legitimate, well-staffed servers jump ship.
EFnet, in short, goes to hell.
I've always said EFnet is the ghetto of IRC networks. I would wager the vast majority of people that use EFnet to chat nowadays do so only because their friends are there, or they don't know that there are alternatives. If there was a way to reliably migrate a person's group of friends instantaneously to another more mature network, most would do it. I would.
If you have a problem with your community's decision to censor content (not that I'm trying not to even make the assumption that a community would want to do such a thing!), then you need to perhaps be a little more vocal with your community, or at least talk them into giving you the ability to override their decision with respects to your own children. That was what I was trying to get at by mentioning adult v. child library cards.
Remember: It's YOUR community. By keeping all of this as local as possible, we have the maximum amount of granularity in determining what your local library should carry and how that information should be made available to the people that visit the library. The libraries should be listening to the people that they directly serve: your local community.
If you live in a particularly conservative area, be prepared to come across some conservative community attitudes. That's the nature of a community. If you don't like it, try to change some minds, or move to a community that shares your views. By demanding that your local library carry everything you want them to carry and not to make that content unavailable to certain patrons, you are no better than the people walking in there saying X Y and Z should be banned. Local libraries are a community service, and it needs to cater to the community it serves. You are part of that community, but you are not alone.
I am firmly against federal (and even state) requirements regarding filtering software. To date this has always been a local community decision, and that's where it should remain.
We may all be geeks here, and we may share attitudes on "censorware" software in our libraries, but it is not our right to dictate whether or not libraries in another community should adopt these policies any more than it is the government's right to do so. By all means, pay attention to this and if you see some items you'd like to bring up with your local library system, PLEASE DO SO.
I personally would prefer that my library go back to having 'adult' and 'child' library cards, with adult cards having access to more mature topics and perhaps an uncensored (but still quite visible to the librarian's desk) feed to the 'Net. If I wanted my child to have access to this stuff, I'd just have to give my consent to the library so that he would be issued an adult card. The only people with censored access are the kids whose parents don't want them to have access. But still, as logical as this sounds to me, I would never try to force this on other communities. It's up to the local community to decide how they want to run their public libraries, not me, not you, and certainly not Slashdot.
Thank goodness all of those space engineers and guys with PhD's and years of experience designing and builing stuff like this have you around! Think of all of the resources (and perhaps lives!) we would have wasted if they foolishly tried to actually pursue this...
Slashdot Mirror
I never said anything about standards. The first time they rejected my browser version because it wasn't yet supported, that was the first thing I thought: so long as they're coding to standards, what's the big deal?
But how many browsers are 100% standards-compliant?
Coding to standards can cause unexpected (and potential insecure) things to happen on browsers or environments that are not up to standards.
How do you tell? You test and certify.
And to answer your question: The site www.bankofamerica.com is running Netscape-Enterprise/3.6 SP3 on Solaris. I don't know if that's what their account management stuff runs under, though. I don't think that the issue was "Windows vs. Linux" but "Mainstream vs. any of the Linux browsers he had at his disposal". Maybe he didn't have access to a browser that his bank did support (under Linux). I don't know.
I really can't believe a user experience like this is new to you. The very fact that you're hearing it now will hopefully clue you in to what life is like in the non-optimal real world.
Wide-scale Linux deployments have worked for, primarily, two reasons:
1. The new Linux installations were, in general, not designed to replace a totally-flexible Windows configuration. Generally, these installations are more akin to point-of-sale operations, or for configurations that have a very limited range of use and do not need a huge application base for their users to be productive.
2. Those Linux implementations were well-planned, well-thought-out and well-engineered. Generally a small team went through, selected a list of the appropriate applications, built a custom distribution or post-installation checklist and custom-tailored the OS to their environment. Most large corporations even do this with Windows.
Your experiences with FreeBSD and your non-tech staff are not necessarily representative of everyone else's. Just as you find it difficult to believe the original poster's story of difficulties, I find it difficult to believe a moderate- to large-scale conversion to FreeBSD or Linux as a Windows desktop replacement (for all-purpose tasks) as you're describing would go without a hitch or a noticable loss of productivity.
That doesn't mean I wouldn't consider your comments valuable. Clearly some people are having successes in some configurations and others are having problems in other configurations.
Fire them and replace them with what? If all of the "non-technies" had a hard time with the environment, what makes you think it's going to be easy (or cheap) to drop in replacements that can? Any mention of these things in a job posting will scare off any potential non-techie (but flexible) folks, and will tend to draw technie (and more expensive) people to their place. If all you want is a 100% techie shop, that's certainly a noble goal, but it isn't realistic in the real world.
Banks also have to certify their sites for functionality, privacy and security before they'd be willing to say, "We support this browser." Either they certify the myriad of Linux-compatible solutions at significant additional cost (for what, a 0.5% increase in potential online customer base?), or they do it half-assed and say, "Should work, go for it." There is logic on both sides of the fence here, but it's a business decision to be made by the bank. A bank that refuses to accomodate browser versions it's not able to personally certify as up to the task is arguably one that's safer, where I'd be more comfortable banking online. I have yet to find a bank that would consider supporting non-mainstream (and/or untested) browser versions.
The original poster is right: Linux is not 100% up to the task yet. Don't get pissy with that conclusion, ask what the problem is and fix it so that it isn't a problem anymore.
Every 6 months or so I bring a couple of my Linux systems up to date as far as the X, KDE and Gnome stuff goes, and spend a day or two trying to make it a usable desktop. For the most part, it's quite usable, but it's always lacking a fluidity of interface that other GUI-native operating systems (MacOS, Windows) have nailed. There is also a training overhead involved for people that have been "classically" trained on Windows. Sitting friends down in front of it, even after brief periods of experimentation, they still end up having to ask me how to do simple tasks. The naming of some applications in Linux leaves a bit to be desired.
I will continue using my Linux systems for what they're best at: server tasks. It's all about using the best tool for the task. Linux is not the best tool for all tasks.
Agreed!
Except I'm still kind of confused as to why this is a privacy invasion.
How can company B handle company A's warranties, catalog preferences, refunds, replacements, pending orders, etc., if company B buys and/or merges with company A but company A destroys its own customer lists...?
I don't understand what company A (Egghead) could have or would have done differently in this case that would cease to make this a privacy problem.
It looks like it's just a simple transfer of customer data, kept under the same privacy policies that Egghead had. If you didn't like those privacy policies, why did you give them your information? Companies are bought out and merged all of the time. Do you really expect them to destroy their own customer records every time this happens?
The only reason we're seeing this issue now is because Egghead did the RIGHT THING by allowing their customers to opt out prior to the transfer. This is a very noble and privacy-friendly thing to do. It would be nice if every company did this as part of its data transfers.
Sounds like you need to upgrade or re-configure your web browser to honor your preferred e-mail client.
Or you could just send them an e-mail (clearly you found the address) or call the provided 800 number. There are few things this company could do to make this process easier for you.
If you have a beef with Egghead as a company, that's your business, but they are doing everything they can to do the Right Thing here, and I applaud them for it, even if they've been the subject of misfortune in the past.
Their opt-out process was very quick and painless for me after I received the e-mail notice. I only bothered to opt-out because I had no intention of doing business with them in the near future.
If you had actually read the e-mails they sent out (which would make you actually involved in this topic instead of just posting on Slashdot without all of the facts), you would have read that the arrangement requires Fry's to honor the existing Egghead privacy policies. Your data will not be used in any way counter to the policies that were in place when you signed up with Egghead in the first place.
This is just a straight transfer of data from one company's flag to another's, under the same policies and restrictions.
Stop being melodromatic about giving up all of our rights. I really cannot believe this topic is generating this amount of negative attention. I wish more companies were as open and pro-active about their customers' privacy. There isn't much more that Egghead could have done in this case, and it's silly to expect that they would just destroy their customer lists. How is Fry's to handle things like returns, warranties, catalogs, etc., if they don't have this information?
Maybe you didn't get an e-mail because they, for whatever reason, don't have your e-mail address? If they aren't able to contact you, chances are, the company they sell this data to won't be able to contact you either. What exactly is the problem?
If the new company *does* contact you, without warning, *then* I would be concerned...
If you deploy your software smartly, you will rarely ever have problems like the other doomsayers say. Set up a test environment and trial products before you roll them out and mandate their use. If you experience problems, a support contract helps in getting those problems corrected, all without the user even knowing. When you're ready, deploy.
But this forces everyone to change to a Windows desktop!
What percentage of employees in your company do not have a Windows PC sitting at their desk? Most people can safely say that number is negligible, but in the off-chance you have an office filled with Linux or Solaris users, I guess this could be a factor.
But this forces everyone to use Outlook!
Some might consider this a good thing, but be aware that there are web-enabled versions of Exchange/Outlook that allow you to access your corporate mail from a web page. Secure it and firewall it if you're worried about security, or make it available only to employees dialed into your Intranet.
Doesn't Exchange also offer POP support (maybe by a 3rd party if nothing else)? Is there anything stopping you from using your existing mail clients?
I'm a Unix guy. I work on several Solaris systems every day, code a bit in C, a bit more in Perl. My company has also standardized on NT desktops and Outlook for e-mail. As much as I hate to admit it, Outlook is extremely powerful, and the ability to coordinate appointments and the like makes Outlook very attractive, especially when every employee in the company is guaranteed to be compatible with the system. I don't usually have to worry if so-and-so can read the attachment I'm about to send him because he has the same setup as I do. Homogenous desktop environments is a huge boon to inter-office communication.
Oh, and I use 'mutt' at home.
Then by using GPL'ed software in the stuff you produce for class, you are preventing them from doing this legally.
Besides, this is all going under the assumption that the university has a legal right to claim ownership of the stuff you produce in class anyway. I don't recall ever signing a contract mentioning that when I was in college. In the absense of such an agreement, the stuff I produce is mine and mine alone, and aside from 'fair use' (and the implicit permissions I'm giving the prof by turning my work in), they have no right to my works.
Stop thinking about GPL'ed code like that. It's a "parasitic license", with the operative word being "license". You can freely add whatever proprietary (and copyrighted) bits of code to a GPL'ed application that you want. The license's sticky point is the fact that you cannot redistribute it without surrendering all of your additions to the GPL.
Thus, a company can control an application based on GPL'ed code with proprietary/copyrighted additions and do whatever they want with it, so long as it stays within the company. They can't sell it nor can they make it available to anyone else without making the whole thing GPL'ed and giving up the source of their proprietary changes.
If it's GPL'ed, IBM would supposedly retain the copyright over the code added/modified by the employee, making the resulting code undistributable under the GPL. Remember: you can modify and add whatever proprietary bits to GPL'ed code that you want, you just can't redistribute it.
I'm sorry but if somebody threatens to DoS me over IRC, and then proceeds to do so, CALL THE POLICE. CALL THE FBI. You know who he is. You know where he's IRCing. Log the information, and TRACK THE ASSHOLE DOWN. If he's IRCing from his own ISP (unlikely, but IRC is full of stupid kids), call the ISP and shut the account down. If he's bouncing from one or two sites, look up the IP address (do a WHOIS against ARIN) and call them up. Solicit their help in tracking him down. It should be obvious where he's connecting from (a 'finger' or 'netstat' should make that apparent, assuming the machine isn't compromised, in which case a network sniffer or 'tcpdump' will let you do the same), and back-track.
I know we all seem to think script kiddies have these l33t ways of hiding their identities, but it all boils down to a few responsive phone calls and you can nail anybody back to their ISP. Any competant ISP will have caller ID records for the incoming call. Granted, they won't give you this information, but they will certainly note it. Let the feds do the rest.
Why do people not even think about taking these steps? If you can't reach an ISP's network center, GO OVER THEIR HEADS. Contact their uplink.
The more we whine and say DoS attacks suck, and the more we DON'T pursue and put these fuckers in jail and slap enough damages on them so their parents lose their house and car, the more powerful and untouchable they feel, and the more bolder they get.
Perl's function syntax?? What are you smoking?
.signatures?
some_function($argument1, $argument2);
What exactly is so difficult to use or understand about that? Likewise with OO methods:
$some_object->some_method($argument1, $argument2);
Anyone from any OO camp will instantly be able to recognize that and understand what it's doing. I fail to see what you are trying to bash here.
As far as Perl's global variable issue, this is a necessity brought on by the fact that Perl isn't just built to write large scripts/applications. It's built to handle small one-liners as well. Forcing strict variable declarations (which is highly recommended with any medium to large script, and enforced with the use strict; pragma, would completely solve the problem you're ranting about) would prevent readable one- and two-line-style scripts. Ever seen the "RSA in 3 lines of Perl" type
chdir($dir) or die "Couldn't chdir to $dir: $!"
What is so difficult to read or understand about this? Any programmer that has never seen Perl before should be able to understand the above. This is an example of a stock Perl function and stock Perl error handling. The only thing that may not be apparent is the $! variable, but it's pretty easy to see what it is just by looking at context. What is the problem with this?
Finally, if you dislike Perl, don't use it! Why are you even reading a Perl forum? Why are you going in depths of comments and why, for God's sake, are you participating? Do you just like conflict? Are you trying to get people angry with you so you can get angrier back at them? Why?
Wow, I don't think I've ever met anybody as anti-Perl as you.. I think the main problem you have with it is the fact that the syntax can be so varied. This allows for very elegant and efficient code, but at the same time, inexperienced programmers can abuse that lack of strict syntax and write something that's very difficult to read.
Find a good Perl programmer, and not somebody that's just learned Perl and likes to tinker with it (there are thousands of these!), and you will find some very readable Perl code. Sounds like you've been bitten by a poor Perl programmer and asked to maintain his code perhaps?
Seriously, a bad programmer in any language is going to write a badly written program. The code will be difficult to read and maintain. In many other languages, though, stricter syntax forces the programmer into a certain style, so you mitigate the amount of damage they can do (a badly written piece of code simply may not compile). Perl is enormously flexible, with syntax and modules to do anything, which means poor/beginner programmers can Get Stuff Done with little knowledge, effort, and sadly, little programming abilities.
Perhaps you should be working to better educate the developers around you (or hire better ones) instead of dissing a language that obviously is not going away and obviously has a very practical and valid use in just about any field.
no perl;
for ($you) {
$year = 1;
}
I had a similar experience trying to change my *contact* information. The e-mail address in one of my contact entries had become invalid, and I could not get anything done for a solid 9 months, after phone calls, 3 faxes (at the request of the person I spoke to on the phone, two of which were sent *directly to the tech*), and repeated e-mails.
After 9 months of this crap, I transferred my domain to register.com. All it took was a notarized copy of the form and a photocopy of my driver's license. My bank across the street did this for free. Once I got that to them, the only delay was waiting for Network Solutions to "authorize" the domain transfer (apparently they still have a form of veto power in case you don't pay your bills, whatever). It took like 2 days to get a response (a new record for NSI!), as I recall, and the following day to get the WHOIS servers updated.
I have been INFINITELY impressed with the speed and flexibility of register.com, when compared to NSI. All changes to most any bit of information about your domain are all AUTOMATED and require only that you confirm the change via e-mail. It takes 2 minutes, tops, and the servers are updated by the next day.
I imagine most ANY other registrar will give you comparable service. Fuck NSI.
I would wager most companies that institute any sort of e-mail monitoring policy only go that deep into message contents when an employee is under active investigation. Even the most paranoid of companies typically log only the presence of messages, or individual HTTP requests made, never actual content.
To those that say, "People have always been saying EFnet is dying, but it's still here, and it will be around for a long time to go!" I agree, only insofar as EFnet will not go away.
But isn't an IRC network effectively dead when it ceases to be a reliable means for people to get online and chat? When was the last time you could get onto your EFnet channel of choice and have a conversation with the regulars? I bet if you did the math, EFnet would spend over 50% of its time with at least one major server split or with one or more heavily hit links.
When I sit down and am totally unable to have a conversation with my friends for any more than a few minutes at a time, I consider it time to move on. The only way people are going to be happy again is if they migrate to a more stable network, and nobody is going to do that until EFnet finally kicks the bucket and its existing (stable) servers either join up with a real IRC network or shut down for good.
Let EFnet die. It's functionally dead already.
It's an issue of trust. A rogue IRC server can introduce any command into the IRC network that it wants. If there weren't any other opers watching the network, that server could cause anarchy.
They also require servers with large pipes for a reason: the IRC2 protocol is not very efficient. It's entirely ASCII-based and depends on things like connections, quits and channel messages to be propogated throughout the entire network. Thus, your private server wouldn't necessarily just be seeing traffic it needs to see, it would be seeing ALL traffic across the network.
Ordinarily, this amount of data isn't too bad. An ISDN link could probably handle it. The problem is the connect bursts. When two servers split, as you know, each server on the local side of the split sends out QUIT messages for each client that has now disappeared on the other side. If this is a major hub, this burst in itself is quite large. In addition, when servers reconnect (such as when your private server connects to the network or when a split server reconnects), a much larger connect burst occurs, as each client on the "other" side is introduced to the local side. JOINs (well, SJOINs) have to be sent as well, so that all servers have enough state information about what clients are on what channels that they can provide that information to the local user.
In short, IRC2 needs "HUGE pipes".
Yes, it could be designed better. Yes, there are better IRC network designs on the way, but there's little that can be done to fix IRC2.
Limiting a server to local clients has always been an acceptable and practiced policy among EFnet servers. Generally if a server is capable of being open and handling non-local clients, it should do so, but if an ISP has a sizable population of IRC users, and sufficient hardware to support those users and little more, it makes sense for that ISP to set up its own dedicated IRC server for its customers, and to link that server to EFnet.
AOL and Netcom are prime examples of large providers that have opted to build their own IRC servers for their own clients. Unfortunately (mainly in AOL's case), they didn't feel obligated to police their own servers, and abuse was quite rampant.
In the beginning, there was IRC. IRC was good, people got along, and chatting was what people did.
Then there were some differences of opinion between administrators. It's OK, these things happen. Feelings got hurt, EFnet spawns a child network. Increasingly, this happens more and more, but typically the arguments revolve around the introduction of features to give the user a better chatting environment.
There are always two sides to the argument. There are those that want things like channel ownership, more IRC operator participation in the affairs of mortals and harsher, coordinated controls against abusers of the service. Then there are those that don't want anything to change. They view IRC operators as the keepers of the links, and that those keepers should never meddle in the affairs of the users. Let them sort (battle) out their own problems. EFnet splits. The liberal operators and servers (the ones wanting the change) spawn off a new IRC network, and the conservative/reactionary operators and servers stay behind.
Think of it as evaporative cooling. As EFnet experiences its civil wars, the proportion of "to hell with the users" attitudes rises.
Eventually, this attitude starts biting the opers and admins on the ass. EFnet turns into a war zone, with DoS attacks starting to show up. A few users think they're funny and DoS the opers too.
The ugly dragon rears its head.
Now the attitude becomes "fuck everyone but my fellow opers". IRC wars move from the IRC playfield to the Internet with DDoS attacks taking down servers for the purposes of channel warfare and retaliation against opers and admins. Sometimes the ill feelings are warranted, but mostly the packet kiddies are just trying to make a nuisance of themselves. Networks suffer, ISP customers suffer, ISP's de-link their IRC servers. A free service (IRC) should not--must not--impact the ISP's ability to reliably serve its customers.
Now at this point, EFnet starts getting a shortage of big servers. Naturally there are dozens of ill-experienced, IRC savvy packet kiddies that have "grown up" a bit and want to try their hand at running servers. A few are cautiously linked in, oper abuse (already rampant on EFnet) begins to rise even faster. The line between oper and kiddie twists around a bit, more servers run by "former" (or current) packet kiddies, Internet wars abound, servers are split, packet kiddies continue to attack. Legitimate, well-staffed servers jump ship.
EFnet, in short, goes to hell.
I've always said EFnet is the ghetto of IRC networks. I would wager the vast majority of people that use EFnet to chat nowadays do so only because their friends are there, or they don't know that there are alternatives. If there was a way to reliably migrate a person's group of friends instantaneously to another more mature network, most would do it. I would.
If you have a problem with your community's decision to censor content (not that I'm trying not to even make the assumption that a community would want to do such a thing!), then you need to perhaps be a little more vocal with your community, or at least talk them into giving you the ability to override their decision with respects to your own children. That was what I was trying to get at by mentioning adult v. child library cards.
Remember: It's YOUR community. By keeping all of this as local as possible, we have the maximum amount of granularity in determining what your local library should carry and how that information should be made available to the people that visit the library. The libraries should be listening to the people that they directly serve: your local community.
If you live in a particularly conservative area, be prepared to come across some conservative community attitudes. That's the nature of a community. If you don't like it, try to change some minds, or move to a community that shares your views. By demanding that your local library carry everything you want them to carry and not to make that content unavailable to certain patrons, you are no better than the people walking in there saying X Y and Z should be banned. Local libraries are a community service, and it needs to cater to the community it serves. You are part of that community, but you are not alone.
I am firmly against federal (and even state) requirements regarding filtering software. To date this has always been a local community decision, and that's where it should remain.
We may all be geeks here, and we may share attitudes on "censorware" software in our libraries, but it is not our right to dictate whether or not libraries in another community should adopt these policies any more than it is the government's right to do so. By all means, pay attention to this and if you see some items you'd like to bring up with your local library system, PLEASE DO SO.
I personally would prefer that my library go back to having 'adult' and 'child' library cards, with adult cards having access to more mature topics and perhaps an uncensored (but still quite visible to the librarian's desk) feed to the 'Net. If I wanted my child to have access to this stuff, I'd just have to give my consent to the library so that he would be issued an adult card. The only people with censored access are the kids whose parents don't want them to have access. But still, as logical as this sounds to me, I would never try to force this on other communities. It's up to the local community to decide how they want to run their public libraries, not me, not you, and certainly not Slashdot.
Thank goodness all of those space engineers and guys with PhD's and years of experience designing and builing stuff like this have you around! Think of all of the resources (and perhaps lives!) we would have wasted if they foolishly tried to actually pursue this...