You missed the point of my post. I do not want or need a software gesture manager in roughly the same way that a car driver does not want or need a horse shoe.
My keyboard / mouse IS a gesture surface and it beats the socks off of anything in software. I never have to lift my hands off the keyboard, and I can chord common modifiers like shift and control without having to strain to reach an out of the way key.
I am typing this on a fully gesture-based keyboard. The TouchStream from Fingerworks is essentially two large touchpads, and it is super-configurable. It includes gesture support for mousing, keyboard chording, and many application-specific gestures such asl emacs, vi, Photoshop, and many other bindings for a wide variety of systems (it's just a USB keyboard and mouse to the OS).
Thus no one can control gesture interaction but me.
I think this is a much better way to get applications to support gesturing than "upgrading the whole Internet"
As a sysadmin that has been dealing with security issues in financial and other corporate settings for well over a decade, I can tell you that the fear-factor on kiddies with their viruses starts to fade over time. However, what I've noticed happening is that people are coming to accept these relatively benign viruses, root-kits, etc as a fact of life, and they seem to be forgetting that where kiddie-hack-of-the-week can succede there WILL ALWAYS BE a small, but worrisome number of clueful people exploiting the opening.
Most often those people are insiders, so you have the added worry that things like firewalls are useless (do you sniff email for viruses on internal mail? do you have unpatched servers that only intenal users have access to?), and they may be able to convince others that you think you can trust to look the other way.
Security is one of those ugly balancing acts. Ultimately, it's a losing game because once a determined cracker with a clue sets their sights on you, you're done for. No amount of security is sufficient... really (yes, even a gasketted vault with armed guards CAN be cracked). The key is risk-vs-reward and always trying to make sure that some poor clueless bastard out there is an easier target than you.
1. The end user requirements for email are just getting figured out. Let's not forget that a huge fraction of the world doesn't use email on a regular basis yet.
2. The first and foremost requirement of email has always been interoperability. Countless good systems died because they could not interoperate or did so poorly. Everything else is driven by that (even MS' crappy email products).
3. You're making some assumptions about the job of the client (MUA) vs the server (MTA) that are not really very valid, to wit: 1) The MUA often has nothing to do with the delivery of the message, nor the receipt of same 2) there are often more than two MTAs involved in the transmission of a message, so "receipt" gets fuzzy 3) the safeguards you suggest mostly do exist, and you can turn them on in your MTA, but no bets on who else will talk to you
4. OSS solved these technical problems long ago... the social and organizational problems will require a few more years to settle out.
5. OSS brought you the Internet, global naming; electronic mail; the World Wide Web and its associated protocols; universally accessible, millitary-grade encryption; commodity equipment-ready multi-user, multi-tasking operating systems; and any number of other things that "end-users" had no clue they needed before they were made available. OSS is not about providing you with what you think you want, it's about providing everyone with what someone, somewhere wanted bad enough to build and share.
I'd love to "subsidize bulk email" in this way. In fact, I'm all for spammers getting permanent accounts with unique keys for FREE!
Why? Because I want to be able to build a reputation system, and as long as IP and the fiction of "from address" are the only things that I can use to build such reputation, it's worthless.
Imagine this going on inside your mail server:
Hmm, so you want to send me mail, eh? Who are you? Oh, you're Joe Blow, USPS ID #4817437458183 Hmm, you don't have much in the way of rep... I'm passing you off to the agressive spam-filters and replying with a warning bounce (to the registered "from" address for that key, which it's illegal to misrepresent). Next... who are you? Oh, you're Amy Goodfriend. You've been known by the reputation system for 10 years, and have never sent spam. Delivering your mail now Amy, thanks. Next... who are you? Oh, you're Bill Spamalot. You've been known by the reputation system for 10 years, and have sent 80% spam in that time./dev/null, thank you for playing.
THAT is why I want *anyone* to build an identity system, and as long as that anyone is large enough and can build enough of a ground-swell of usage, it will work. All I need is the ability to map your key ID back to some basic info like email address and [pseudo]name, and the rest of the system can be built the way grey lists area already being built around IP addresses. The government need not get involved, though it's welcome to build its own lists. Personally, I don't think they should. That seems to me like a good place for the government to stop giving out information, and let private citizens do the rest.
The key things about such a system to me are:
1. It doesn't invent its own protocols (use the RFCs) 2. Its usable by anyone with an Internet connection and a server (don't try to lock end-users out of running thier own mail servers by rule or by price). 3. There is no requirement that people use it or not use plain old SMTP.
If those requirements are met, I'm good with it, as it adds orders of magnitude of spam protection CAPABILITY without interfering with access to mail, business, privacy or civil rights.
1. (given) SMTP+TLS+key management Internet standards 2. Draft a new RFC that establishes an identity system for email using (above) 3. USPS provides servers for (above) at a micro-payment fee
No one is forced to use this system, and it doesn't cost much (some basic fee to register and maintain your identity, and some much smaller fee to validate one, or perhaps a flat fee to have a "validation service"). However, what it does is creates a new "class" of email that you have to be identified to use and which costs you a small amount of money. You can now reliably do things like:
* Only accept mail from known parties and/or * File complaints against abusers and/or * Tier the classes of serivce, charging more for business-class communications (further hurting ROI for spam) and/or * Pay a little extra for delivery status tracking (did the recipient validate the sender?) and/or * Pay a little extra for key escrow of encrypted data (the channel would most likely be encrypted anyway) and/or * Maintain external grey-lists of trust relationships and/or reputation, based on sender identities.
Make no mistake. This is where we MUST go eventually, and I'm just as happy to have a U.S. government organization do it as the E.U. or a private company, as long as no one tries to tear down good old free-for-all clear-text, unauthenticated, SMTP (why tear that down, when those who don't like it can simply not accept it?)
Researching something just for the sake of research, on the other hand, is nothing but gambling on the tax-payers money
First off, if you're doing it just for the sake of research, you're not gambling, you're spending.
If, on the other hand, you are doing a broad base of basic research in order to build the foundation on which your next generation of applied science will be built, you cannot say with confidence, "we will look into this phenomenon and it will yield these results." What you can say is, "we will investigate phenomena and theories which tie into our current applied science priorities and that will broaden our understanding of those areas." Even if you never get a "eureka" out of that research, it will provide the background for future work in the field.
That's not a hunch, gamble or guess. It's simple fact: basic research is one of the tools you need under your belt in order to do good applied science, and good applied science is required in order to build the next generation of technologies.
If you want to go Ludite, you can argue that we don't WANT OR NEED the next generation of technologies, but to argue that you should not do basic research because any single project cannot be said to produce a reward is just plain silly, you don't do research for technological rewards, creating a broader and deeper body of knowledge is the reward, and it WILL be taken advantage of by many researchers, scientists and technologists for centuries to come.
Your concerns are well placed (yeah, you misread a bit, but I'm not the nit-picker others are). However, you missed the biggest worry of all.
Guess what the DoE's primary job is...
Power? Nope. Um... "energy something"? Nope.
The DoE's biggest job is maintaining the U.S. nuclear stockpile. They're the ones who contract with companies like G.E. to build nukes.
So, with that bit of info in your head, go back and look at this and ask yourself: "what OTHER purpose could building an oganism be put to that the DoE might have an interest in, and which would make it a justified expense?"
Let's not make this a license squable. That's about as far from dignified as we could possibly get. We all release our code in order to get it out where people can use and benefit from it. If SCO uses/modifies my code (and they have) I'm just as happy as if Bill Gates or Mother Theresa do (well ok, if a dead, saint-in-waiting used my code, I'd be pretty pumped). The goal is to get people into the mindset of having CONTROL over their own interaction with computers, and not the other way around.
Usage = win, regardless of which OSS/FS license you care to select.
The greatest test of our resolve to make software a building block and a tool usable, distributable and modifiable by all... is to give it to those who do not understand the value of the gift that they are being given.
If SCO uses our code, we win. If SCO benefits from our code we win. If SCO modifies our code, we win. If we deny SCO our code, we lose.
To quote Babylon 5: "If we deny the other, we deny ourselves." -Citizen G'Kar, "Point of No Return"
start up a GNOME app without GNOME running (Evolution for example) and wait 25 seconds
Gnome is a highly modular system, and you pay a price for that modularity and for the power and flexibility of its components.
However, you've casually selected as an example one of the largest programs on any Linux system, GNOME or not. Evolution is a calendaring system, massively functional mail client (which in turn requires many non-GNOME libraries such as imap, ssl, LDAP, etc), contact manager, task manager and general component system for building your own productivity suite.
Try starting up a gnome-terminal or gaim, and I think you'll see somewhat faster initial startup time. If you want something as powerful and usable as Evolution, you're going to have to load those shared libraries and wait for it to do its own initialization. Applications these days generally expect to be running for long periods of time and so many tradeoffs are made in favor of spending extra time at startup in order to improve the experience later.
In other words, choice is good, as long as you like all of the choices.
I've been using Gnome since it first became stable enough to run a terminal, and I've never looked back.
HOWEVER, I run some apps that are KDE-only as well. I've never seen a problem in doing this.
OOo is, IMHO, the klunkiest, least usable of the desktop applications for UNIX/POSIX systems that I've seen (well, ok if you want to compare to ghostview that's another level of unusability). I use Gnumeric when I need to read or write a spreadsheet and ditto AbiWord for reading office docs (I never write such documents, as any docs that I write are better written in a neutral format like HTML or POD).
I find that Galeon+Evolution+XChat+gnome-terminal+Gaim yeilds a very usable environment, and I hear from folks that use KDE that they have similarly good choices. So, unless you can point to some specific examples of problem integration issues, I'm not sure what it is that you're running into.
For those of you who don't know what Moore's Law is (and especially for those of you who THINK you know what it is), allow me to quote from the Intel Web site:
In his original paper, Moore observed an exponential growth in the number of transistors per integrated circuit and predicted that this trend would continue
Many people have made the observation that Moore's Law is probably a limited phenomenon, and while other increases may continue to fuel increased processing power, Moore's Law does not actually have anything directly to do with processing power.
If that's truly the goal, SCO has already lost. Linux market share continues to increase, and while there have been studies to show that management of some large firms find the case to be a turn-off for Linux, it turns out that middle and upper management rarely is the driving force behind Linux adoption. By the time the matter crosses that level of management's desk, it's usualy of the form, "we're running some test servers on Linux, and they're costing us half the TCO. We'd like to continue as a pilot project."
FUD doesn't work so well in that case, since the counter-argument is tangible.
Seriously, there will probably be an apt/rpm repository maintained for updates by someone like freshrpms, but again it's not guaranteed. If you want guarantees go with RHE.
You should check out apt for RPM. I suspect that that's the way support for Fedora will be done (with sites like freshrpms acting as a clearinghouse for the updates).
The reason that RH has to do this is that the demands on (primarily) security fixes make maintaining an OS distribution the size of Red Hat prohibative. Maintaining two (or more like 10 in Red Hat's case) was just plain not workable.
I understand why they did this, but I hope they're going to put SOMETHING on store shelves in a box, even if it's just "unsupported Fedora" or "trial RHE". They need to do something to keep Red Hat in the eye of the average geek consumer.
Welcome to the world of posting obfuscated code as retort.... I'll point out that almost all of the obfuscation in your posting is possible in almost any language (strings that are reversed or encoded, one-characterfunction names, clever combinations of variable and operator naming, etc).
I'll refrain from posting the results of the obfuscated [language here] programming contest as counter-point, though my favorite is the C program that is formatted into the greek letter pi (the whole program text is ASCII art)... the thing that I loved was that pi was repeated through the program in terms of the word "pi" and the number in varying degrees of precision... and in the end all the program did was approximate "e";-)
As for your implicit critique of Perl's syntax (I'd love to hear a critique of Perl grammar some day, but most people who would love to do so are not capable of doing so): Perl syntax is baroque, but just as with the Baroque Period, too many people allow their aesthetic desire for simplicity to bind them to the power of the complex systems they interact with.
Learn Perl; learn to think in Perl; right around the time you start to dream in Perl (about 2 years for me) you'll begin to be frustrated with how painful the language is on a completely different level. Then try to use another high-level language, and you'll find that those things you find frustrating in Perl NOW aren't frustrating at all in any language other than LISP... because those things are so difficult in most languages, that they never bothered you before.
Perl 6 is working on solving problems in programming that most programmers won't appreciate (dynamic code generation without self-modification; grammar construction as a core language feature; etc). I expect it to get a luke warm reception from the general programmer population, but I'll be paying close attention to those few who "get it"....
You get rated 'Insightful' for stating what OpenSource zealots hope.
No, you get rated insightful for noting what MS has done in the past, and extrapolating the future of their next products based on that.
What if this shell actually knocks the socks off *sh?
That would be nice.
Keep in mind that this isn't a contest. MS has some very nice features burried in their software, and that's great. If MS Windows is ever a better platform choice than the free operating systems out there, I say great!
Woefully, it will still not be the platform I use. Why? Because I require the ability to fix bugs, apply patches on my own timetable (sometimes so fast that my vendor doesn't even know about them yet), and generally control my systems behavior.
Windows does not give me that.
What if Longhorn does indeed provide more security, not only in default settings, but more inherently in the OpenSource?
Security is not a "thing", it's a process. You don't ship your OS in a box with a "NOW WITH 20% MORE SECURITY" sticker and get more security. Longhorn's security will be poor as long as Microsoft continues to deprioritize it in favor of market share. I see no evidence that that has changed since the days of NT4.
Do you think the average developer/manager at MS is dumber than your average OS participant?
No, of course not. The problem is that the average MS employee is working on what a mid-level manager decided he would be working on, based on a company directive from on high that is motivated mostly by marketting. The reason Open Source software tends to be so much more USEFUL, even when it lacks many seemingly obvious features, is the fact that it's created, maintained and refined by those who need it the most. Shells don't seem all that well designed to developers and manageres... and that's because they're not for developers and managers. They're primarily use by sysadmins. A developer spends most of their time in an editor and/or using a rule-based system like make. The shell is just a tool for odd jobs, and many IDEs and feature-laden editors like emacs and vim pretty much suplant the need to use the shell 90% of the time. Sysadmins do not have that luxury.
Look at the MS shell. It is clearly being designed by developers for developers. The ability to manage excel data from the shell is not something that targets the needs of anyone who will have to use this shell routinely. Why is it there? That sort of thing scares me right off the bat, and tells me that this is not a sysadmin tool. Developers under Windows already have very nice tools in their IDEs to script all sorts of interaction with every part of the system that they need. Managers and desktop workers will never want/need a shell.
So ask yourself, which will be more useful: cygwin's bash port to Windows or msh? I can ssh into my Windows box and do admin today, and it requires no msh at all. Why do I need this beast?
But really - if "we" are to compete, we will have to steal the ideas that "work" from MS camp, just as they're "stealing" "our" ideas that WORK.
No, you don't have to steal anything. First off, let's disabuse ourselves of the notion that anything in a shell is new. Shells have existed for decades that do everything msh is (so far) claiming to do. Most of them died a quick death for lack of use.
Next, the most valuable thing that MS has done in the last few years is to put pressure on other OSes to use features that were long available. For example, MS had a journaling fileysystem. Journaling was not new, it was just kind of hard to get right, and all of the implementations out there were fairly speical purpose or closed source. When MS demonstrated that an end-user OS could indeed benefit from having such a feature, dozens of porojects sprang up to take this long-implemented wheel and re-invent it for open source oses.
This sort of "test environment in the large" is very valuable, and MS has alway
There have been bash extensions in the past to do user-level filesystem stuff, actually. It was abandoned as one of those "really cool sounding hacks that no one would ever actually use."
Something to understand here is that SCO's lawyers are not behaving eratically or in an unusual way, given their position.
That is, wen you enter a legal dispute, your first tactic is usually going to be to attack the very foundation of your opponent's position. It doesn't matter if your claims are reasonable (though they should be as reasonable as possible), you just want to take the shot.
Then, idealy, you prepare several fallback positions of increasing weight. There's an emotional trick here and a logical reason for this. The emotional trick is that you set the bar by making the hyperbolic claim. When you claim that the GPL is unconstitutional, you're not attacking the GPL directly so much as you're attempting to start the conversation with a debate over the validity of the GPL so that your next points: the enforcability of the GPL will be recieved better.
The logical reason to do this, however, is obvious to anyone who worries about network security. The first thing you do is always the easiest, no matter how likely it is to stop an attacker, to NOT do the easy things, you would be remiss. After you block all incoming IPX traffic, you still have to deal with the TCP threats, and while it's unlikely that you'll be getting IPX-based attacks from your T1 provider, you should still block it.
That's what SCO has done here. They're not really taking the position that the GPL is obviously unconstitutional, so much as they are making that claim because it's where you start... then you can move on to the arguments that are more likely to work for you.
Whenever I hear someone talk about how "insane" SCO is acting, I have to shake my head. It's not insane for a dying company to make grandious copyright claims against the rest of the industry. It is in fact, a very wise, if desperate, tactic. Get used to it, now that Linux is seen as an ecconmic reality, SCO's wild pot-shots will only be the first of many. The open source community's headache here will be the fact that most businesses don't handle all of those pot-shots in the public eye....
I do not like liars, there appears to me to be a lack of good ethics in business and government
I don't like liars either, but that's rather off-topic since no one involved in this was lying.
These days when I hear/see a democratic politician blame a republican politician
Again, off-topic.
[businesses and their executives want] to blame and point the fingers for failures at everyone, except themselves.
And in this case, that would be correct. The business that outsourced their records did not know that the records were being moved overseas, and could not reasonably have expected to know that. There *is* a culprit here, and that culprit is the company that outsourced overseas. The problem is that many other businesses are doing the same, and the government really does not have the resources to investigate this and enforce the law.
The culprit behind that culprit is decades of omni-partisan cutbacks in the areas of privacy and safety enforcement in the federal government. THAT is what should be addressed in the large, and actually has been over the last 5 years or so... it's a slow process, and cases like this will certainly help to keep it going.
What you describe is a poorly run company, and given that 9/10 new business fail you are certainly right that there are many of them.
However, you cannot generalize that to "most", since new businesses are not, in fact, "most" businesses.
What the average Slashdotter gets confused by (and I don't know if you're in this category or not) is that many well-run companies make choices that are in the company's best interests, but may not make sense technically, or in the greater scheme of the services that that company is precieved to provide.
Thus my question, which you chopped off most of: did the original poster think that the cost/benefit analysis had not been performed, didn't agree with the results, or didn't agree with the condition under which the results would point to the action taken? Keep in mind that one company has been burned in terms of PR, and will possibly be sued, while many, many others have saved costs with no perceptable down-side doing the same thing. In terms of cost-benefit matricies this would weigh in favor of the decision that was made, not against.
I suspect that s/he was in fact unhappy that the market conditions lead to a situation where taking the chance that your company would be the one to get burned with respect to someone else's personal medical information was an acceptable risk. I would tend to agree, but I'm agreeing with a straw-man since the orignal poster was far too incoherent to make that point.
Why, exactly, did this meaningless ramble get modded up?
Prescience: Frequently is observing the obvious that will happen while others dream-on obliviously to reality. Examples: Would be the US Congress and Bush Cabinet.
In hindsight, of course, any event can match this outlook. You can look at the stock market crash of 1929 and say that it was "obvious".
By the same token you can look at the fuel shortage that gripped the world in the 1990s and flung us into world-wide depression and ruin and say that it was equally obvious. It was so obvious, in fact, that dozens of respected voices in econmics had predicted it. Of course, it didn't happen, but it was "obvious" that it would.
In hindsight we ignore the failed predictions and remember the successful ones and say that the future is obvious.
And what, pray, was that wild stab at current US administration intended to demonstrate? They are an example of what? In what respect? With what examples to back up that postulate?! I'm no fan of the existing administration (and by that I mean all three branches of the US government), but taking a backhanded, tangential swing at it isn't really doing anyone any good.
If you contract out your core business data or processes/applications, then expect to suffer many consequences beyond your control. Yep, it is USA government and business SOP
So, you're pointing out that there is risk involved in outsourcing... ok... do you think that that risk is not something that companies take into account in their cost/benefit analysis? Are you saying the analysis is flawed or the conditions which balance the equation in favor of the benefit to outsourcing are flawed? Or are you making the mistake of assuming that because one company is suffering because of this situation that this outsourcing was not a net win to the industries involved?
Also, if USA law applies in India, China,... wherever outside the USA, then it must be a USA possession or colony
That's beyond inchoherent. No part of India or China is a possession or colony of the US. Please, just stop the random phrase generator before it posts again!
Can someone with mod points please spend them on the parent? "Overrated" is a useful option in this case.
You're blurring two very different things, here, and while your core point is correct, it does need some clarification.
You can buy a license for Linux. There is, in fact, nothing wrong with buying or providing a license. SCO's problem is that they are a licensee of Linux under the GPL, and under the terms of that license they have certain obligations and one of those is not to sue their licensees or their sub-licensees for the technology contained in that software.
SCO's counter to this is fairly weak, but let me state it anyway: they claim that they did not know that Linux contained this code, and they distributed their own version of Linux, essentially just as much in the dark as Red Hat. Only (again according to SCO) IBM had any clue what rampant duplication of SCO proprietary technology was being hidden away in the Linux source.
The reason this is weak is several-fold: 1) SCO has continued to distribute the 2.4.13 kenerl from their FTP site under the GPL even up to this date. 2) the interaction between the GPL and SCOs claims is not that clear-cut, though I would tend to side with them on this one point, I don't think the outcome is certain 3) SCO helped in the development of some of the IBM technology in question, so they dang well DID know it was in there.
Ok, now on to you as a user.
If you use Linux, the GPL says you can keep using Linux even if the code is found to be proprietary and the GPL goes into its "failsafe mode".
Now, SCO will say that you cannot continue to use it, and they can press that case if they want, but that's their assertion independant of the GPL. The GPL does not stop you from using the software just because the GPL was nullified by the discovery of a conflict between it and other terms.
However, Red Hat (for example) cannot ship an encumbered version of Linux (they can use it, they just can't ship it). So, they would have to remove the encumbering code, which is why they and everyone else have asked SCO to outline the problem code. At this point, I can't see a court siding with SCO, as they have failed over and over and over to give distributors of Linux the information that they need to AVOID infringement. If SCO said, lines 200-20000 of fubar.c are ours, then the community would move to validate that claim and, if it was valid, remove the offending code ASAP. SCO doesn't want that, clearly, or they would have made it happen (as has happened with their claim over the SGI malloc, even though their claim to that code is tenuous at best).
So, when you say "they won't be able to get any updated versions anway, not from SCO, not from RedHat, not from anybody," that's not so. You will, in fact, get an update pretty damn soon after such a chunk of code is revealed (should it exist at all), and that update will be unencumberd. If that means re-writing 90% of linux, then it will take a bit, but even SCO's wildest claims have made it clear that only a few (albeit large) subsystems are affected.
What Red Hat's obligation to SCO will be (if any) is not your concern. That's a business arrangement between Red Hat and SCO.
Slashdot Mirror
You missed the point of my post. I do not want or need a software gesture manager in roughly the same way that a car driver does not want or need a horse shoe.
My keyboard / mouse IS a gesture surface and it beats the socks off of anything in software. I never have to lift my hands off the keyboard, and I can chord common modifiers like shift and control without having to strain to reach an out of the way key.
I am typing this on a fully gesture-based keyboard. The TouchStream from Fingerworks is essentially two large touchpads, and it is super-configurable. It includes gesture support for mousing, keyboard chording, and many application-specific gestures such asl emacs, vi, Photoshop, and many other bindings for a wide variety of systems (it's just a USB keyboard and mouse to the OS).
Thus no one can control gesture interaction but me.
I think this is a much better way to get applications to support gesturing than "upgrading the whole Internet"
As a sysadmin that has been dealing with security issues in financial and other corporate settings for well over a decade, I can tell you that the fear-factor on kiddies with their viruses starts to fade over time. However, what I've noticed happening is that people are coming to accept these relatively benign viruses, root-kits, etc as a fact of life, and they seem to be forgetting that where kiddie-hack-of-the-week can succede there WILL ALWAYS BE a small, but worrisome number of clueful people exploiting the opening.
Most often those people are insiders, so you have the added worry that things like firewalls are useless (do you sniff email for viruses on internal mail? do you have unpatched servers that only intenal users have access to?), and they may be able to convince others that you think you can trust to look the other way.
Security is one of those ugly balancing acts. Ultimately, it's a losing game because once a determined cracker with a clue sets their sights on you, you're done for. No amount of security is sufficient... really (yes, even a gasketted vault with armed guards CAN be cracked). The key is risk-vs-reward and always trying to make sure that some poor clueless bastard out there is an easier target than you.
1. The end user requirements for email are just getting figured out. Let's not forget that a huge fraction of the world doesn't use email on a regular basis yet.
2. The first and foremost requirement of email has always been interoperability. Countless good systems died because they could not interoperate or did so poorly. Everything else is driven by that (even MS' crappy email products).
3. You're making some assumptions about the job of the client (MUA) vs the server (MTA) that are not really very valid, to wit: 1) The MUA often has nothing to do with the delivery of the message, nor the receipt of same 2) there are often more than two MTAs involved in the transmission of a message, so "receipt" gets fuzzy 3) the safeguards you suggest mostly do exist, and you can turn them on in your MTA, but no bets on who else will talk to you
4. OSS solved these technical problems long ago... the social and organizational problems will require a few more years to settle out.
5. OSS brought you the Internet, global naming; electronic mail; the World Wide Web and its associated protocols; universally accessible, millitary-grade encryption; commodity equipment-ready multi-user, multi-tasking operating systems; and any number of other things that "end-users" had no clue they needed before they were made available. OSS is not about providing you with what you think you want, it's about providing everyone with what someone, somewhere wanted bad enough to build and share.
I'd love to "subsidize bulk email" in this way. In fact, I'm all for spammers getting permanent accounts with unique keys for FREE!
/dev/null, thank you for playing.
Why? Because I want to be able to build a reputation system, and as long as IP and the fiction of "from address" are the only things that I can use to build such reputation, it's worthless.
Imagine this going on inside your mail server:
Hmm, so you want to send me mail, eh?
Who are you?
Oh, you're Joe Blow, USPS ID #4817437458183
Hmm, you don't have much in the way of rep... I'm passing you off to the agressive spam-filters and replying with a warning bounce (to the registered "from" address for that key, which it's illegal to misrepresent).
Next... who are you?
Oh, you're Amy Goodfriend. You've been known by the reputation system for 10 years, and have never sent spam.
Delivering your mail now Amy, thanks.
Next... who are you?
Oh, you're Bill Spamalot. You've been known by the reputation system for 10 years, and have sent 80% spam in that time.
THAT is why I want *anyone* to build an identity system, and as long as that anyone is large enough and can build enough of a ground-swell of usage, it will work. All I need is the ability to map your key ID back to some basic info like email address and [pseudo]name, and the rest of the system can be built the way grey lists area already being built around IP addresses. The government need not get involved, though it's welcome to build its own lists. Personally, I don't think they should. That seems to me like a good place for the government to stop giving out information, and let private citizens do the rest.
The key things about such a system to me are:
1. It doesn't invent its own protocols (use the RFCs)
2. Its usable by anyone with an Internet connection and a server (don't try to lock end-users out of running thier own mail servers by rule or by price).
3. There is no requirement that people use it or not use plain old SMTP.
If those requirements are met, I'm good with it, as it adds orders of magnitude of spam protection CAPABILITY without interfering with access to mail, business, privacy or civil rights.
How I would implement a tax on "spam-free email":
1. (given) SMTP+TLS+key management Internet standards
2. Draft a new RFC that establishes an identity system for email using (above)
3. USPS provides servers for (above) at a micro-payment fee
No one is forced to use this system, and it doesn't cost much (some basic fee to register and maintain your identity, and some much smaller fee to validate one, or perhaps a flat fee to have a "validation service"). However, what it does is creates a new "class" of email that you have to be identified to use and which costs you a small amount of money. You can now reliably do things like:
* Only accept mail from known parties and/or
* File complaints against abusers and/or
* Tier the classes of serivce, charging more for business-class communications (further hurting ROI for spam) and/or
* Pay a little extra for delivery status tracking (did the recipient validate the sender?) and/or
* Pay a little extra for key escrow of encrypted data (the channel would most likely be encrypted anyway) and/or
* Maintain external grey-lists of trust relationships and/or reputation, based on sender identities.
Make no mistake. This is where we MUST go eventually, and I'm just as happy to have a U.S. government organization do it as the E.U. or a private company, as long as no one tries to tear down good old free-for-all clear-text, unauthenticated, SMTP (why tear that down, when those who don't like it can simply not accept it?)
Researching something just for the sake of research, on the other hand, is nothing but gambling on the tax-payers money
First off, if you're doing it just for the sake of research, you're not gambling, you're spending.
If, on the other hand, you are doing a broad base of basic research in order to build the foundation on which your next generation of applied science will be built, you cannot say with confidence, "we will look into this phenomenon and it will yield these results." What you can say is, "we will investigate phenomena and theories which tie into our current applied science priorities and that will broaden our understanding of those areas." Even if you never get a "eureka" out of that research, it will provide the background for future work in the field.
That's not a hunch, gamble or guess. It's simple fact: basic research is one of the tools you need under your belt in order to do good applied science, and good applied science is required in order to build the next generation of technologies.
If you want to go Ludite, you can argue that we don't WANT OR NEED the next generation of technologies, but to argue that you should not do basic research because any single project cannot be said to produce a reward is just plain silly, you don't do research for technological rewards, creating a broader and deeper body of knowledge is the reward, and it WILL be taken advantage of by many researchers, scientists and technologists for centuries to come.
Your concerns are well placed (yeah, you misread a bit, but I'm not the nit-picker others are). However, you missed the biggest worry of all.
Guess what the DoE's primary job is...
Power? Nope. Um... "energy something"? Nope.
The DoE's biggest job is maintaining the U.S. nuclear stockpile. They're the ones who contract with companies like G.E. to build nukes.
So, with that bit of info in your head, go back and look at this and ask yourself: "what OTHER purpose could building an oganism be put to that the DoE might have an interest in, and which would make it a justified expense?"
Yeah, I'm worried too.
Let's not make this a license squable. That's about as far from dignified as we could possibly get. We all release our code in order to get it out where people can use and benefit from it. If SCO uses/modifies my code (and they have) I'm just as happy as if Bill Gates or Mother Theresa do (well ok, if a dead, saint-in-waiting used my code, I'd be pretty pumped). The goal is to get people into the mindset of having CONTROL over their own interaction with computers, and not the other way around.
Usage = win, regardless of which OSS/FS license you care to select.
The greatest test of our resolve to make software a building block and a tool usable, distributable and modifiable by all... is to give it to those who do not understand the value of the gift that they are being given.
If SCO uses our code, we win. If SCO benefits from our code we win. If SCO modifies our code, we win. If we deny SCO our code, we lose.
To quote Babylon 5: "If we deny the other, we deny ourselves." -Citizen G'Kar, "Point of No Return"
start up a GNOME app without GNOME running (Evolution for example) and wait 25 seconds
Gnome is a highly modular system, and you pay a price for that modularity and for the power and flexibility of its components.
However, you've casually selected as an example one of the largest programs on any Linux system, GNOME or not. Evolution is a calendaring system, massively functional mail client (which in turn requires many non-GNOME libraries such as imap, ssl, LDAP, etc), contact manager, task manager and general component system for building your own productivity suite.
Try starting up a gnome-terminal or gaim, and I think you'll see somewhat faster initial startup time. If you want something as powerful and usable as Evolution, you're going to have to load those shared libraries and wait for it to do its own initialization. Applications these days generally expect to be running for long periods of time and so many tradeoffs are made in favor of spending extra time at startup in order to improve the experience later.
In other words, choice is good, as long as you like all of the choices.
I've been using Gnome since it first became stable enough to run a terminal, and I've never looked back.
HOWEVER, I run some apps that are KDE-only as well. I've never seen a problem in doing this.
OOo is, IMHO, the klunkiest, least usable of the desktop applications for UNIX/POSIX systems that I've seen (well, ok if you want to compare to ghostview that's another level of unusability). I use Gnumeric when I need to read or write a spreadsheet and ditto AbiWord for reading office docs (I never write such documents, as any docs that I write are better written in a neutral format like HTML or POD).
I find that Galeon+Evolution+XChat+gnome-terminal+Gaim yeilds a very usable environment, and I hear from folks that use KDE that they have similarly good choices. So, unless you can point to some specific examples of problem integration issues, I'm not sure what it is that you're running into.
If that's truly the goal, SCO has already lost. Linux market share continues to increase, and while there have been studies to show that management of some large firms find the case to be a turn-off for Linux, it turns out that middle and upper management rarely is the driving force behind Linux adoption. By the time the matter crosses that level of management's desk, it's usualy of the form, "we're running some test servers on Linux, and they're costing us half the TCO. We'd like to continue as a pilot project."
FUD doesn't work so well in that case, since the counter-argument is tangible.
Which part of unsupported did you not grok?
Seriously, there will probably be an apt/rpm repository maintained for updates by someone like freshrpms, but again it's not guaranteed. If you want guarantees go with RHE.
You should check out apt for RPM. I suspect that that's the way support for Fedora will be done (with sites like freshrpms acting as a clearinghouse for the updates).
The reason that RH has to do this is that the demands on (primarily) security fixes make maintaining an OS distribution the size of Red Hat prohibative. Maintaining two (or more like 10 in Red Hat's case) was just plain not workable.
I understand why they did this, but I hope they're going to put SOMETHING on store shelves in a box, even if it's just "unsupported Fedora" or "trial RHE". They need to do something to keep Red Hat in the eye of the average geek consumer.
Welcome to the world of posting obfuscated code as retort.... I'll point out that almost all of the obfuscation in your posting is possible in almost any language (strings that are reversed or encoded, one-characterfunction names, clever combinations of variable and operator naming, etc).
;-)
I'll refrain from posting the results of the obfuscated [language here] programming contest as counter-point, though my favorite is the C program that is formatted into the greek letter pi (the whole program text is ASCII art)... the thing that I loved was that pi was repeated through the program in terms of the word "pi" and the number in varying degrees of precision... and in the end all the program did was approximate "e"
As for your implicit critique of Perl's syntax (I'd love to hear a critique of Perl grammar some day, but most people who would love to do so are not capable of doing so): Perl syntax is baroque, but just as with the Baroque Period, too many people allow their aesthetic desire for simplicity to bind them to the power of the complex systems they interact with.
Learn Perl; learn to think in Perl; right around the time you start to dream in Perl (about 2 years for me) you'll begin to be frustrated with how painful the language is on a completely different level. Then try to use another high-level language, and you'll find that those things you find frustrating in Perl NOW aren't frustrating at all in any language other than LISP... because those things are so difficult in most languages, that they never bothered you before.
Perl 6 is working on solving problems in programming that most programmers won't appreciate (dynamic code generation without self-modification; grammar construction as a core language feature; etc). I expect it to get a luke warm reception from the general programmer population, but I'll be paying close attention to those few who "get it"....
You get rated 'Insightful' for stating what OpenSource zealots hope.
No, you get rated insightful for noting what MS has done in the past, and extrapolating the future of their next products based on that.
What if this shell actually knocks the socks off *sh?
That would be nice.
Keep in mind that this isn't a contest. MS has some very nice features burried in their software, and that's great. If MS Windows is ever a better platform choice than the free operating systems out there, I say great!
Woefully, it will still not be the platform I use. Why? Because I require the ability to fix bugs, apply patches on my own timetable (sometimes so fast that my vendor doesn't even know about them yet), and generally control my systems behavior.
Windows does not give me that.
What if Longhorn does indeed provide more security, not only in default settings, but more inherently in the OpenSource?
Security is not a "thing", it's a process. You don't ship your OS in a box with a "NOW WITH 20% MORE SECURITY" sticker and get more security. Longhorn's security will be poor as long as Microsoft continues to deprioritize it in favor of market share. I see no evidence that that has changed since the days of NT4.
Do you think the average developer/manager at MS is dumber than your average OS participant?
No, of course not. The problem is that the average MS employee is working on what a mid-level manager decided he would be working on, based on a company directive from on high that is motivated mostly by marketting. The reason Open Source software tends to be so much more USEFUL, even when it lacks many seemingly obvious features, is the fact that it's created, maintained and refined by those who need it the most. Shells don't seem all that well designed to developers and manageres... and that's because they're not for developers and managers. They're primarily use by sysadmins. A developer spends most of their time in an editor and/or using a rule-based system like make. The shell is just a tool for odd jobs, and many IDEs and feature-laden editors like emacs and vim pretty much suplant the need to use the shell 90% of the time. Sysadmins do not have that luxury.
Look at the MS shell. It is clearly being designed by developers for developers. The ability to manage excel data from the shell is not something that targets the needs of anyone who will have to use this shell routinely. Why is it there? That sort of thing scares me right off the bat, and tells me that this is not a sysadmin tool. Developers under Windows already have very nice tools in their IDEs to script all sorts of interaction with every part of the system that they need. Managers and desktop workers will never want/need a shell.
So ask yourself, which will be more useful: cygwin's bash port to Windows or msh? I can ssh into my Windows box and do admin today, and it requires no msh at all. Why do I need this beast?
But really - if "we" are to compete, we will have to steal the ideas that "work" from MS camp, just as they're "stealing" "our" ideas that WORK.
No, you don't have to steal anything. First off, let's disabuse ourselves of the notion that anything in a shell is new. Shells have existed for decades that do everything msh is (so far) claiming to do. Most of them died a quick death for lack of use.
Next, the most valuable thing that MS has done in the last few years is to put pressure on other OSes to use features that were long available. For example, MS had a journaling fileysystem. Journaling was not new, it was just kind of hard to get right, and all of the implementations out there were fairly speical purpose or closed source. When MS demonstrated that an end-user OS could indeed benefit from having such a feature, dozens of porojects sprang up to take this long-implemented wheel and re-invent it for open source oses.
This sort of "test environment in the large" is very valuable, and MS has alway
There have been bash extensions in the past to do user-level filesystem stuff, actually. It was abandoned as one of those "really cool sounding hacks that no one would ever actually use."
Something to understand here is that SCO's lawyers are not behaving eratically or in an unusual way, given their position.
That is, wen you enter a legal dispute, your first tactic is usually going to be to attack the very foundation of your opponent's position. It doesn't matter if your claims are reasonable (though they should be as reasonable as possible), you just want to take the shot.
Then, idealy, you prepare several fallback positions of increasing weight. There's an emotional trick here and a logical reason for this. The emotional trick is that you set the bar by making the hyperbolic claim. When you claim that the GPL is unconstitutional, you're not attacking the GPL directly so much as you're attempting to start the conversation with a debate over the validity of the GPL so that your next points: the enforcability of the GPL will be recieved better.
The logical reason to do this, however, is obvious to anyone who worries about network security. The first thing you do is always the easiest, no matter how likely it is to stop an attacker, to NOT do the easy things, you would be remiss. After you block all incoming IPX traffic, you still have to deal with the TCP threats, and while it's unlikely that you'll be getting IPX-based attacks from your T1 provider, you should still block it.
That's what SCO has done here. They're not really taking the position that the GPL is obviously unconstitutional, so much as they are making that claim because it's where you start... then you can move on to the arguments that are more likely to work for you.
Whenever I hear someone talk about how "insane" SCO is acting, I have to shake my head. It's not insane for a dying company to make grandious copyright claims against the rest of the industry. It is in fact, a very wise, if desperate, tactic. Get used to it, now that Linux is seen as an ecconmic reality, SCO's wild pot-shots will only be the first of many. The open source community's headache here will be the fact that most businesses don't handle all of those pot-shots in the public eye....
I do not like liars, there appears to me to be a lack of good ethics in business and government
I don't like liars either, but that's rather off-topic since no one involved in this was lying.
These days when I hear/see a democratic politician blame a republican politician
Again, off-topic.
[businesses and their executives want] to blame and point the fingers for failures at everyone, except themselves.
And in this case, that would be correct. The business that outsourced their records did not know that the records were being moved overseas, and could not reasonably have expected to know that. There *is* a culprit here, and that culprit is the company that outsourced overseas. The problem is that many other businesses are doing the same, and the government really does not have the resources to investigate this and enforce the law.
The culprit behind that culprit is decades of omni-partisan cutbacks in the areas of privacy and safety enforcement in the federal government. THAT is what should be addressed in the large, and actually has been over the last 5 years or so... it's a slow process, and cases like this will certainly help to keep it going.
What you describe is a poorly run company, and given that 9/10 new business fail you are certainly right that there are many of them.
However, you cannot generalize that to "most", since new businesses are not, in fact, "most" businesses.
What the average Slashdotter gets confused by (and I don't know if you're in this category or not) is that many well-run companies make choices that are in the company's best interests, but may not make sense technically, or in the greater scheme of the services that that company is precieved to provide.
Thus my question, which you chopped off most of: did the original poster think that the cost/benefit analysis had not been performed, didn't agree with the results, or didn't agree with the condition under which the results would point to the action taken? Keep in mind that one company has been burned in terms of PR, and will possibly be sued, while many, many others have saved costs with no perceptable down-side doing the same thing. In terms of cost-benefit matricies this would weigh in favor of the decision that was made, not against.
I suspect that s/he was in fact unhappy that the market conditions lead to a situation where taking the chance that your company would be the one to get burned with respect to someone else's personal medical information was an acceptable risk. I would tend to agree, but I'm agreeing with a straw-man since the orignal poster was far too incoherent to make that point.
Why, exactly, did this meaningless ramble get modded up?
... wherever outside the USA, then it must be a USA possession or colony
Prescience: Frequently is observing the obvious that will happen while others dream-on obliviously to reality. Examples: Would be the US Congress and Bush Cabinet.
In hindsight, of course, any event can match this outlook. You can look at the stock market crash of 1929 and say that it was "obvious".
By the same token you can look at the fuel shortage that gripped the world in the 1990s and flung us into world-wide depression and ruin and say that it was equally obvious. It was so obvious, in fact, that dozens of respected voices in econmics had predicted it. Of course, it didn't happen, but it was "obvious" that it would.
In hindsight we ignore the failed predictions and remember the successful ones and say that the future is obvious.
And what, pray, was that wild stab at current US administration intended to demonstrate? They are an example of what? In what respect? With what examples to back up that postulate?! I'm no fan of the existing administration (and by that I mean all three branches of the US government), but taking a backhanded, tangential swing at it isn't really doing anyone any good.
If you contract out your core business data or processes/applications, then expect to suffer many consequences beyond your control. Yep, it is USA government and business SOP
So, you're pointing out that there is risk involved in outsourcing... ok... do you think that that risk is not something that companies take into account in their cost/benefit analysis? Are you saying the analysis is flawed or the conditions which balance the equation in favor of the benefit to outsourcing are flawed? Or are you making the mistake of assuming that because one company is suffering because of this situation that this outsourcing was not a net win to the industries involved?
Also, if USA law applies in India, China,
That's beyond inchoherent. No part of India or China is a possession or colony of the US. Please, just stop the random phrase generator before it posts again!
Can someone with mod points please spend them on the parent? "Overrated" is a useful option in this case.
This is thursday, do we think information wants to be free on thursday? ;-)
You're blurring two very different things, here, and while your core point is correct, it does need some clarification.
You can buy a license for Linux. There is, in fact, nothing wrong with buying or providing a license. SCO's problem is that they are a licensee of Linux under the GPL, and under the terms of that license they have certain obligations and one of those is not to sue their licensees or their sub-licensees for the technology contained in that software.
SCO's counter to this is fairly weak, but let me state it anyway: they claim that they did not know that Linux contained this code, and they distributed their own version of Linux, essentially just as much in the dark as Red Hat. Only (again according to SCO) IBM had any clue what rampant duplication of SCO proprietary technology was being hidden away in the Linux source.
The reason this is weak is several-fold: 1) SCO has continued to distribute the 2.4.13 kenerl from their FTP site under the GPL even up to this date. 2) the interaction between the GPL and SCOs claims is not that clear-cut, though I would tend to side with them on this one point, I don't think the outcome is certain 3) SCO helped in the development of some of the IBM technology in question, so they dang well DID know it was in there.
Ok, now on to you as a user.
If you use Linux, the GPL says you can keep using Linux even if the code is found to be proprietary and the GPL goes into its "failsafe mode".
Now, SCO will say that you cannot continue to use it, and they can press that case if they want, but that's their assertion independant of the GPL. The GPL does not stop you from using the software just because the GPL was nullified by the discovery of a conflict between it and other terms.
However, Red Hat (for example) cannot ship an encumbered version of Linux (they can use it, they just can't ship it). So, they would have to remove the encumbering code, which is why they and everyone else have asked SCO to outline the problem code. At this point, I can't see a court siding with SCO, as they have failed over and over and over to give distributors of Linux the information that they need to AVOID infringement. If SCO said, lines 200-20000 of fubar.c are ours, then the community would move to validate that claim and, if it was valid, remove the offending code ASAP. SCO doesn't want that, clearly, or they would have made it happen (as has happened with their claim over the SGI malloc, even though their claim to that code is tenuous at best).
So, when you say "they won't be able to get any updated versions anway, not from SCO, not from RedHat, not from anybody," that's not so. You will, in fact, get an update pretty damn soon after such a chunk of code is revealed (should it exist at all), and that update will be unencumberd. If that means re-writing 90% of linux, then it will take a bit, but even SCO's wildest claims have made it clear that only a few (albeit large) subsystems are affected.
What Red Hat's obligation to SCO will be (if any) is not your concern. That's a business arrangement between Red Hat and SCO.