Religion: americans are the only developed people that don't think creationists are ridiculous
I'd say that the "developed" among us do indeed think they are ridiculous; but we tolerate them because (a) at least 1/2 the population is IQ 100 or under, and there is little point in attempting to appealing to a critical thinking skill that cannot operate in such an environment, and because (b) it is our tradition to tolerate other people's beliefs even if we think they are wrong and would argue a particular point -- and this is especially so if the holder of the belief also falls under the situation described in (a).
Banking: only americans think it's a good idea to write a check and put it in the mail to pay a bill
Well, that's just because our postal and banking systems mostly work. As someone who has been mailing products to other coutries for several decades, I can tell you that many other countries would do much better if they successfully emulated the American postal system. Perfect, no... but it is very, very good. Of course, we bitch roundly about it anyway. We're a nation of chronic complainers.:-)
The problem is that this argument -- more cores should equal more licenses -- is the same argument that a faster clock speed on the same type of hardware should equal more licenses, or more memory on the same hardware should equal more licences, or changing to a CPU with an FPU from one that didn't should equal more licenses.
The fact is, multiple cores means more processing power, not multiple users. We can already have multiple users with a single core CPU design.
There is no valid "commercial reasoning" for multi-core == multi-license.
What they are trying to do here is leverage a fairly minor technology shift into a way to make more money that they don't have to (a) do any work for and (b) can use to victimize a locked-in customer base.
First of all, I'd very much back drivers being tested for adequate reflex and cognitive function prior to the car being allowed to turn on, or failing that, by a trooper who stops someone for driving erratically. If and when such technology becomes available. And yes, of course it would be entirely appropriate to test everyone who was in a wreck for fatigue poisons (or however one would detect serious sleep deprivation) as well as recreational drug use.
It is worth observing that mild sleep deprivation cannot be definitely identified as being in the realm of debilitation-by-choice -- you may not even know that you have this problem; it can be a matter of poor sleep, not even lack of sleep.
In stark contrast, recreational drug consumption (including alchohol, of course) almost always is voluntary and you will be aware that you have been involved in such activities; if you aren't, then someone else needs some jail time. Drugging people without their knowledge is criminal in the most basic sense of the word.
Specifically with regard to alchohol, 0.08 BAL isn't reasonable because no voluntary diminishment of skill is reasonable when you decide to pilot machinery that is dangerous to others.
The same thing goes for serious sleep deprivation. I think it is a pretty safe bet that you know if you're seriously short on sleep.
Everyone needs to be in the best possible shape to drive, because driving is a very dangerous activity.
The fact that this isn't the norm in society reflects only that society is made up of ethical cripples.
FYI, I am in the real world. I've seen the deaths and injuries that come from drugged drivers; I've seen them up close and personal, and lots of them. I was married to a surgeon in rural America for quite a few years, and I can tell you that this isn't something that "lighten up" is the appropriate reaction to.
It's not OK. It'll never be OK. You can't make it OK, and you can't make it seem OK. Grow up before you fuck somebody up.
A grown man having 2 glasses of wine with a meal could now qualify for DWI....that's stupid.
No. A grown man, intentionally decreasing the speed and accuracy of his reflexes by voluntary and knowing consumption of even small amounts of a recreational drug and then getting behind the wheel of a car -- that is stupid.
There is no "ok" level of recreational drug consumption that entitles one to say "I'm ok to drive." Drink and ride, abstain and drive. The ethics should be clear to anyone.
For the record, if anyone "happens" to hit a family member of mine with a machine they are piloting and it turns out that their blood alchohol level was not zero, I'm going to rip their head off and shit down their neck.
I absolutely support anyone's choice to use recreational drugs; but that in no way absolves the user of responsibility -- operating dangerous machinery does not somehow become the appropriate thing to do because you think you "only had a little."
Your rights end where mine begin. Violate mine, and as far as I am concerned you lose yours. All of them. Including the right to breathe air.
No. I can legitimately develop applications for Windows elsewhere -- under Linux, using wine, for example. Or even without using wine. I don't need an application framework from MS, I don't need to pay them anything, and I don't need to buy their tools, either. Though I can certainly choose to use them, and they are quite convenient and powerful so this is a likely situation. But I do have other options.
If I go that way, I've not bought the OS at all. But I still have the opportunity to write applications for the widgets, because there is no cost or obligation for using widgets under Windows, contrary to your attempt to make it seem so.
You just can't accurately say that charging for the OS, or the development tools is the same as charging for the widgets. It's not the same thing at all. And if you really want to get into realistic assessment of costs, Linux has cost me more in time to get set up, and I still don't have a generally usable set of widgets I can target. My time is expensive, and by that metric, Windows is not -- and Linux is.
Re GTK+, it is LGPL encumbered, hence not useful to me. If they want it to be free, then they need to make it free, as in, "here, do anything you want with this." That's free. "Here, you can do this limited set of typical development tasks, but not these other typical development tasks (like mixing my stuff in with their stuff, or proprietary stuff in with their stuff, or patented stuff in with their stuff)" is not free. It is (a) a legal minefield, and (b), annoying to need to bring a lawyer in when you want to just write an application under a GUI, and (c) even more annoying to have the lawyer tell you "nope, you can't use this."
But Linux doesn't have a standard GUI-API, it has add-ons. Tons of them. All with different licenses and costs and limitations and features. All I want is for Linux to develop a nice, standard set of widgets -- basic windows, buttons, checkboxes, lists and so on -- that I can legitimately use without having to read and subsequently compensate for a bunch of legalistic crapola. I want these to work on every Linux machine, and I don't want to have to compile the application for every variation of Linux out there. As long as these issues remain unsolved, I'm not interested in going forward.
Anyway, Windows widgets and use of the API is indeed free. You can do anything you want with them, from any software platform or cross-development environment you can manage to cobble up, and no one will ever say "boo."
At least maybe some sort of "Photoshop Interface" toggle. Then again you can be a smug developer and say "Use it or not. Go 'way."
That is exactly what we did. We offer a far more powerful interface, mouse-wise, than Photoshop does. And of course, that means it is quite different in how it handles. We put in an "operates like Photoshop" mode so that those who were not willing to consider the method we chose would not have that as a reason to dismiss our software out of hand, and so that we could continue to develop and extend the more powerful interface without having to deal with random "but I'm used to the other way" complaints.
And for the record, it's worked out very well for everyone.:-)
...it works a hell of a lot better than any other complex raster graphics program that I know of.
That just means that either you don't know about the better working methods that can be found elsewhere, or you don't know how to use them very well. No big deal. That simply says you're in the same boat as most other Photoshop users, not that you're a sub-standard graphics person.
There are definitely better ways to work than "the Photoshop way." Better because they are faster, more efficient, more precise, more flexible. Then again, Photoshop is what people are used to, and that is the key here -- not that it is UI perfection, but that it is pervasive and for many tasks, it is more than good enough. Habit counts here as well.
A couple of months ago, a friend of mine who is really a pretty expert Photoshop user, was working on an old photo. He was using the healing brush and the clone (pantograph) tool to fix the thing, and he was definitely getting it done. It seemed quite slow to me, because I don't do it that way -- I use something more efficient. I knew he had the other tool on his system, so I got him to start it, popped the image in there, and got the entire healing job -- the complete scratch, which he hadn't yet finished after several minutes -- done with one area selection that took about 2 seconds to complete. I explained how it worked, and why, and his reaction was "wow", but you know what? The next day, I found him back in Photoshop, fixing a different scratched image (these are scans of very old family photos, lots of damage.) I asked him why he wasn't doing it the way I showed him, and looked kind of guilty and said "This is warm and fuzzy... I'm comfortable doing it this way." I just said "cool" an walked off. I think that says a lot about who uses what, and why. This guy is bright, skilled, and generally pretty open minded. But then again, he's very "comfy" with Photoshop and that directs his actions to a very large degree. I don't think this is unusual, either.
On the other hand, if we're going to talk about maximum potential efficiency, that is, how fast a particular task can be done to an equal degree of precision given two diverse approaches, for many tasks Photoshop's one-mouse-button approach falls short of other mechanisms -- this is also the case with some other UI issues and technical capabilities it has (or doesn't have) that are lacking in efficiency and flexibility.
These things typically aren't a big deal unless maximum efficiency and flexibility and speed are issues; if they are, then it is worth some time to look elsewhere. There are some advanced UI approaches out there, several of them quite interesting and useful. And definitely faster.
If you like painting with brushes made of images, then there are some cool tools out there that leave PS in the dust. Which ones might surprise you if you've spent most of your time with Photoshop. If you are a "Master Layer Blending Person" then there are far more advanced image layering systems out there. If you like writing plug-ins, there are easier to develop for plug-in interfaces that provide some really neat things and are far easier to write to. If you are really into efficiency, there are definitely better ways to utilize the mouse. If you are into scripting, there are custom BASIC, python, and "other" script-driven interfaces in some of the other packages that are really quite complete and powerful. There are systems that handle deeper bit-depth images more completely, or consistantly, and there are systems that do more flexible color separations (try mixing UCR and GCR approaches in Photoshop and I think you'll see what I mean about flexibility.)
Photoshop is great. No question about it. But it is not the be-all and end-all of graphics software. It is just the most popular. Part of that is functionality, but another part of it is marketing and simple user enthusiasm, something that can have roots in paying a very large amount of money for a package and then getting done what you wanted to get done. That doesn't mean it's the best way to do something -- it just means this way works.
Sure do. Looked at MS lately? Looked at Billy-boys cash value? Do you realize that you don't have to buy everything, just a majority of the stock, to control the company? Can you say hostile takeover with a Boston lawyer accent?:-)
I don't think it's even a question of if MS could; only a question of if they would want to. If the Ps3 can truly kick the XB2's butt (and that's as much a matter of software as it is of fabulous hardware) then just perhaps they would.
MS might just throw the current XB2 design in the toilet and sell software for the PS3, too. There's nothing quite so predictable, yet as blatently unexpected, as tomorrow's news. I saw that coming! Yeah. Sure I did.:-)
What's that you say? MS wouldn't invest in supporting a hardware architecture and then just let it go? Er... NT Alpha. NT PPC. NT MIPS. Here yesterday, gone... yeah, yesterday, that's the ticket. XB2? Not here today... and not here tomorrow, either?
I bet there are a lot of XB2 engineers crying in their beer tonight. It might not be as bad as it seems, but... it sure seems pretty bad. Beer with salty tears. Yech.:-)
But there is no way in hell Microsoft is getting the Cell processor for the next Xbox.
Oh, I don't know. Microsoft could just up and buy IBM. They might have trouble buying Sony, given that it's not a US company and that Japan has been known to be fiercely protective of its corporate citizens, but IBM? I doubt that'd be a serious problem. If it breaks laws, they'd just buy the politicians -- and it wouldn't be the first time.
Never underestimate the power of cash to alter the world you live in.
No. There are strings attached. The reason you don't know this is because either (a) you have not read the LGPL, or (b), you didn't understand it.
If (a), go read. You're just making yourself look uninformed (not to mention the silly namecalling... what, are you 12 or something?) If (b), I'm sure I'll figure it out next time you post, no further action needed on your part.:-)
So what language is your "great" application written in? What tool-kit/API does it use? What tool-kit under Linux did you try to use that caused you such "burdens".
In order: C, Win32, and none. As I mentioned previously, and as you would know if you had read the thread, we stopped the whole Linux port before we got to code because of the legal issues. Cost is not an issue. More is available for this project than it could possibly cost. We've ported three times; never did it go over budget or over time. Time is a big issue. Legal encumbrance is a big issue. Stability is a big issue. IP protection is a big issue.
Just to be clear, I am sure we could code to pretty much any widget set without much trouble, assuming it is reasonably feature complete (in other words, I am leaving out utterly silly ones like those that don't have menu support or only run under certain desktops) and assuming the widget set doesn't require that you use something other than C to get at it.
I know you are talking FUD, since there are _NO_ source code obligations with Linux GUI tool-kits. You can keep your code closed as much as you like.
I see. Well, when you've actually read the LGPL, you come back and give me an informed opinion, K? Thaaanx.
I think it was your lack of knowledge of Linux development that made you "think" there were no standard API/tool-kit/frameworks under Linux.
Hmmm. Maybe you're confusing my posts with someone else's posts. All I've been discussing is an unencumbered widget API so that applications can code to a standard target. This is a very specific area and that's all I am talking about here. We don't need any libraries other than those required to interface with the OS, basically we need to be launched, we need fopen() and friends, malloc() and friends, and we need a graphics API that supports windows and controls. Collectively, widgets. But there is no graphics API (I refuse to count xwindows... it is far too awkward compared to more modern current metaphors) In Linux, what we have instead are a wide variety of widget sets.
I am agitating for a standard, with-the-OS, and so always-there-to-use, widget capability. Windows has this. The Mac has this. Linux does not have this. I would like Linux to have this. Instead, Linux has this, that and the other thing from third (and fourth, and fifth) parties, and when you try to install an app you're just as likely to be told you can't do that because you don't have the latest and greatest this that or the other thing. I don't want our customers to have that experience. Ever.
Now, you can tell me why you think Linux should not have this, and I will pay attention and (perhaps) even respect your opinion, especially if you read the LGPL before you next reply.:-) However, if you try to tell me that gnome is a widget set, I will proceed to ignore you for what I hope are obvious reasons.
Have you ever read/. and hear all the Linux geeks talk about "all you have to do is./configure;make;make install"?
Certainly, I'm quite familiar with the process. But what made you think we would want to distribute a package someone would have to compile at install time? What we want to do is provide an executable that runs when you execute it. We might go so far as to provide a tissue-thin w
Vendors do this automatically, since Gtk (like most libraries) is a DLL.
No. This is for linking the library into the application. You should read the LGPL. Not to mention the rest of the thread.:)
Microsoft and Apple also provide no warranty, accountability, or responsbility.
No, in fact, they do. They both provide support, fixes, workarounds, suggestions and code. However, if you roll your own for Linux, you can do this yourself, which is interesting and about the only point in its favor, frankly.
Yes, that is entirely reasonable, and it is basically the same with commercial software.
No. It's not. Generally speaking, if I roll a patented technology of ours into a library, I can proceed to distribute the library no problem. This is an LGPL limitation, although it may be a limitation of other non MS and non Apple libraries as well, couldn't say. There's a big difference between a loadable library and code that's linked right in so it'll always work and doesn't depend on an external component.
And your point is?
...the point is that telling a commercial developer they have to allow reverse engineering of their work is stupid. These aren't college students sitting in the dark with dad's computer working for free with some asinine notion of "information wants to fly free" floating around in their skulls, these are people who have (at least) employees who depend on them to make the best choices they can manage to make, and where stockholders and/or investors of other classes may also depend on quality decision making. You put a requirement in there that obligates the vendor to distribute IP they depend upon for income, and you've just exited the game stage left, with that nasty hook around your neck.
What's your point? Microsoft doesn't supply MFC for Linux, and Apple doesn't provide Cocoa for Linux.
The point was that if you include an LGPL'd library, you may not be able to include other libraries because the LGPL says so. It's a legal minefield for developers. I decline to walk in it.
I suggest you do yourself a favor and actually read the LGPL. It's very interesting.:)
The Windows GUI API has no restrictions on it at all. None. You don't need MS's dev tools to use it. There is no such restriction. You don't need their permission to use it. Period. You don't need to inform them you're using it; you don't have to give out your source code if you use it (no matter how you use it) and you don't have to distribute your code if you adjust it, either, assuming you found a compelling reason to do such a thing. If you find a bug, you can tell them and they will (for a price, generally speaking) figure out what is going on and either fix it or tell you what you need to do to get around it. I've quite a bit of experience with those folks, having been developing graphics apps for windows for some years now. They're not so bad.
Aside from that, there is a huge difference between one well defined, encumbrance free target and the multiple encumbered (and moving) targets that comprise the Linux patch-a-GUI fractured environment. No amount of bluster will make this not so. The only thing that can fix it will be actually fixing it. And in the interim, you'll continue to suffer from a dearth of commercial apps. Yes, certainly you have some. But you could have more. You don't have any of the big three graphics programs, for instance, and the OS sure could use them, given that the GIMP is all you have right now.
As for your other comments about graphics, thanks, very interesting. Also very funny. You might want to do a little research before you wing it like that; In fact, you should do some right now. That'll give you time to pull your foot out of your mouth; the poor thing is sizzling in your stomach juices presently.:)
No. It isn't. You pay with obligation if you're not paying with money. You also pay with time, because a lot of this stuff needs work, you have to pick and choose which one, etc. Time is money. With MS and Apple, the GUI just works, and you don't need to worry about it. You just dig in and make your app. That's what it is about. Not "choice", I and most other commercial developers don't give a northbound rat's southern expanse for "choice." What we want is standardization, functionality, reliability, and a well defined API. Truly, you can keep your "choices" -- they cost too much.
Can you get the source code to MS Windows or Mac OS X's GUI environment free of charge with no-strings attached?
Perhaps you can (MS will definitely give you the code given some "I won't tell" legal t-crossing an i-dotting, don't know about Apple), but why on earth would I want such a thing? All I want is a defined API. I have no interest in how it works, just that it does work. We spend enough time writing our own stuff that we have very little interest in looking at the OS code. Define the API and you're done, as far as I am concerned.
The problem with the much older MS Visual studio IDE's is that they are not very good and certainly do not support the latest features of MS's development environment. None of those older environments support MS's.Net for example.
As for older MS IDE's "not being very good", that's nonsense. They're not as up to date, but they contain significant debugging tools and pretty much everything you actually need to get an application done. I am speaking from experience here. WinImages is built using an older VS, and it all works just fine. No point for you on this one.
Now, not using recent OS features can be an advantage. The more recent OS features you use in a commercial application, the more you limit your audience. For instance, if you choose to use an older VS and the libraries that come with it, you can write code that will run without any modification or hoop-jumping on everything from Win95 to XP. Look at putting the current GIMP on stock RH9, which is actually a very recent distribution if you think about it; yet, it simply won't go. GTK+ requires later stuff and there are other issues as well. Basically, if you want to build the current GIMP, you need a significantly more current system. It doesn't have to be that way. This is a shortcoming of the GTK+ widget library design.
There is no single "utopia" OS or development environment. Trying to single out just Linux makes you sound naive, especially when the MS windows development environment has just as many quirks.
Well, to you, perhaps so. My situation is that I have a complex, powerful product I'd like to bring to Linux. Every path we could find had significant roadblocks on it. Many of them were legal pitfalls, but some had amazing shortcomings (like, widget sets with no menu support!) What I think I know about Linux at this point in time is that to get our app ported in such a way as to work on the very largest set of machines without legal pitfalls and unacceptable source code obligations seems to require that we build our own widget set and incorporate it so that all we require from the OS is xwindows and basically fopen() and crew. Right now, that's too much, so a port isn't going to happen. YMMV as your requirements do, and of course, I may discover something tomorrow that obviates all of this, but this is where we are today.
In very sharp contrast, when we looked at porting to the Mac, it all went smooth as butter. Standard GUI, standard API, dev tools all lined up and ready to go. So there is a significant difference here, much as you might not want to acknowledge it.
When Linux gets a standard GIU-API, it'll have "grown up" as far as I am concerned as a developer and commercial software provider.
In the interim, our port to Linux remains on hold.
QT and GTK+ and so on aren't bad because "you have to pay for (them)", if indeed you do, they are bad because they impose restrictions on how you can use them. I'd be delighted to pay (a lot) for a Linux widget set that we could use in an unrestricted manner and that would work in a broad variety of Linux machines. I just haven't found one yet. Smaller developers might have issues with the price; we don't, and that's a good thing, because we have a big app to bring to the table.:)
Also -- about the direction of your reasoning -- if you want to develop for Linux, you have to buy a computer. If I buy a Mac Mini, for instance, I've put out $500, I have the computer, the OS, and the development tools. I spent a lot more on my Linux machine, and then I had to fight with it for many hours to get it configured. My Mac was ready out of the box, and I can tell you that these two factors make the Mac a lot cheaper platform to begin development on than a Linux machine.
Our Windows development systems are more expensive because we buy Visual Studio; but again, the up-front charge isn't a problem. It'd be a problem if we couldn't develop for Windows 98, or if we couldn't use a treeview widget if we wanted to distribute a modified version of the widget, or if we were required to give out our source code. But once you have VS, you can develop anything you want, using the widgets any way you want, and there are no limitations on you at all. That is why QT and GTK+ and the rest of this is different. They're a legal minefield, and no one with half a brain is interested in walking through one of those. Hence, very little commercial closed-source development on Linux.
When and if Linux gets a standard, reasonably modern OS-level GUI-API, things will probably change radically. Until then, the reason you can see all four walls at once is because you're still stuck in that corner.:)
Sure. And when there are "millions of clients" as my first responder imagined, you'd find a client more quickly, and the whole thing would quiet right down to communications between consenting clients, as it were. Or one friend could seed another friend's client, skipping the whole process.
A simple announcement on some place like slashdot would go a long way towards building an initial community, too. Later, a note in your slashdot sig. On your website. In your email signature. Or whatever. Make it easy to find the network, and from there on out, the network has no central point, and it is irrelevant where you entered it from.
Add a plug-in to your browser that scans for "I am on the network" HTML tags. As you browsed the web, your connectivity would grow, no action required from you.
If there is no easy find as at first, then a scan is a perfectly viable early stage alternative.
Encryption is important as well. No one should be able to see what you upload or download. But that is pretty trivial at this point in the game.
My main point is that you absolutely want to avoid a central server of any type, or you've brought "the man" into your computer room.
Although your interpretation is correct, it's really not that profound. You could also make the claim that 50% or more of the sample are at or above average intelligence.
Well, no. Because as we go above "average intelligence", we have to go quite a ways before we begin to get into the realm where people are really able to deal with technical issues. You have to get quite a distance away from 100 before people are generally going to be able to perform well; and even that isn't a given. That's why (a) it is interesting that more than half already land at the 100-or-under level, and (b) why I said "of course, there are a very large number at 101, 102 and so on."
The post I originally replied to observed "there are far mor(sic) stupid people out there than you seem to realize." My comments were relative to that observation, in the current context of P2P and the technical and IP issues that underlie P2P. So my comments direct your attention to the mass of folks in the midde-ish areas of IQ; what we have here is technology that is not ready for the unwashed, yet they have it anyway. It's no surprise there is fuckarosis happening.:)
Of course you don't want just scanning, and of course there's no need to scan the entire Internet. I didn't suggest either one of those things. However, random scanning at a reasonable rate is a perfectly good way to bootstrap into the network without having to have a requirement for a central server. It will serve to bootstrap the client, and if its done in any kind of reasonable manner, there's no reason it wouldn't do it quite well, too.
No. GTK+ has some restrictions and issues. The LGPL is far from a panacea, and anything that uses the LGPL is full of pitfalls for commercial use. Some examples from the LGPL:
If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling
it.
there is no warranty (implicit in this is there is no accountability and no responsibility... IMHO for this reason a commercial developer would do far better to write their own widget set, frankly, than use an LGPL'd set)
we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license.
you may also combine or
link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications
...It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you
distribute.
Windows and the Mac provide GUI/widgets for free, no restrictions whatsoever. Widgets which work in all cases, from any language, upwards compatible without recompile or legal hoop jumping or the requirement to provide source for this, or binaries for that, or recursive versionitis fuckarosis (for instance, try getting the GIMP going on a stock Redhat 9 system and you'll see exactly what's wrong with GTK+'s ability to interoperate from a commercial standpoint.) Until/unless Linux handles these issues, Linux is in a corner.
GTK+ isn't a good answer. It isn't even an answer in some cases.
Linux needs commercial software much less than Windows or Macintosh because it comes with so much out of the box.
Linux comes with plenty, and there's plenty you can immediately add without too much effort. Fine. No argument (I'm a Linux fan, I'd be very unlikely to argue this point.) However, that doesn't obviate the point that there is more to be had, and if Linux was more compatible with commercial efforts, we'd definitely have more of those things (I say definitely, because the fact is I get to make some of those decisions.:)
In my particular area of expertise, the GIMP is "what is available" for Linux. But I have access to something quite a bit more powerful than the GIMP under Windows; despite the years of development put into the GIMP, and ignoring, for the moment, the terrible compatibility problems the GIMP has with not 100% up-to-date Linux systems, the very best that the latest GIMP has to offer, assuming you can get it to work, isn't good enough. For instance, it is ridiculous to contemplate going back to twenty-odd layer blend modes when your workflow normally spans seventy-plus; it is a royal pain in the butt to only be able to see one layer at a time; when CYMK work is required, you're simply out of luck; it is hugely annoying to have to select an area, then go select the op, then select, then op, ad infinitum when you are used to working by setting up the op, then selection, selection, selection... etc. Your working speed is reduced by a factor of (at least) two. There are many more issues like this, but these are enough by themselves to pretty much leave the GIMP unused around here.
These kind of things are like being forced to drive a golf cart to work after you've been driving a car. You can't go back -- or if you do, you wave your hands about saying, look, I'm using the junk transport!
Now, the GIMP is free, and as such is definitely worth eve
Making the claim that more than 50% of the population falls below that mark
I didn't make that claim. I explained that more than 50% falls at or under the median, which is an accurate observation, as well as being not at all what you said.
Think about it. If you have ninety eight 100 IQ folks, one at 90 IQ, and one 110 IQ, then 99 of them fall at or under the median, and the average, both of which are 100. There are an equal number of data points on either side of the median; one per each side.
Why not make a P2P application that works by working through IP addresses at a reasonably friendly rate looking for a particular answer to athe client's inquiry?
If the knockee has the P2P app, it'll answer, and the two apps can have a nice little chat. If not, no answer, and on we go. Plus, of course, you can just manually add people you already know have the app.
At a 2nd tier of connectivity, as clients learn about other clients, they can (slowly and reasonably) share client lists with each other, and pretty soon, you'll have a good sized network connected P2P with no central server at all.
The only people with logs of who has downloaded what would be the people doing the downloading/uploading. Assuming you kept them, which isn't a given.
Add solid encryption; stir to taste.
I mean, really -- how hard a problem is this to actually solve in a final and complete manner?
It seems to me that the P2P developers are not trying very hard.
There are far mor stupid people out there than you seem to realize.
IQ is a metric that is designed such that both the median and the average fall at 100.
A 100 IQ as it fits the populace today denotes someone quite restricted in ability when we're talking about understanding abstract concepts.
Now, on first glance, you might think that the average and median falling at 100 means that 1/2 the people have an IQ of 100 or under, but that is not correct.
Because IQ is a curve with a decided hump in the middle, there are more data points in the center than there are anywhere else.
That means that the correct assessment is that more than 1/2 the people have an IQ of 100 or under. And of course, there are a very large number at 101, 102 and so on.
This illuminates many social problems, including P2P use for purposes that would make tracking one's identity a potential problem for the user.
Of course, it is not only the 100-and-unders that get into trouble; you can attribute that to a lack of critical thinking skills and/or not being in the habit of using them if they are present.
In other words, you don't have to be stupid, to act stupid.
Actually, electrons transit very slowly down a wire, and as AC service is generally 50 or 60 hz, and there is generally considerable distance between where your wiring begins and your electrical power demands begin, I'm afraid we're all using the electrons already present in the wiring -- not those "sent" by a power company. At least if we own our homes, we own our electrons, too. I know I paid for all my wiring.:-)
Think of electrons in a wire as a pipe full of ping-pong balls glued to each other. The electric company is just pushing and pulling on ping pong balls they have, so that the ping pong balls you have will move.
You don't need to pay anything to have access to a very broad spectrum of OS widgets when developing for Windows (or the Mac), no matter if you are developing in a traditional commercial sense or using any other financial model. It is only under Linux that we see charging commercial software for basic GUI capabilities accepted as "normal."
Also, under Windows, if you want to purchase development tools (Visual Studio or otherwise), you certainly can. Still, there are free ones out there, and you can go quite a long way with those. The Mac comes with everything you need; when you buy the machine, you get the tools. And of course the GUI-API and widgets are 100% "there" on the Mac as well.
Under Windows, you also have the option of using an older, very much less expensive version of Visual Studio -- those are still 100% functional and produce fully functional applications under XP (and 95, 98, 2000, and NT) and I see no reason they won't remain so.
I think that if Linux ever matures enough to "come with" a standard, always-there, reasonably modern GUI-API such that software can be directly written to and for it, you'll see a significant burst of commercial development, porting and deployment. Until then, the job of trying to figure out what toolkit has the fewest warts and gotchas will be a significant stumbling block for commercial developers. I know it was for us. We shelved our port-to-Linux project for this very reason. As our application is a large one in terms of code, comments and OS window/widget objects, we need to be extremely conservative about launching a porting effort. The cost of a late-stage failure or roadblock would be very, very high.
Linux has really worked itself into a corner here.
There is a bizarre social aspect, a "we don't need your steenking commercial software" attitude that will probably keep it there, too. It's interesting to watch.
I knew a guy in Mercy Corp that went over to help with the tsunami relief and in one village he was in they had one roughly 100mhz machine they were using to use for searching for missing people
The scene cuts to Jamal, standing in a muddy field, holding the 100 MHz pc
...drops PC... squish ...picks PC up, takes a step... ...drops PC... squish ...picks PC up, takes a step... ...drops PC... squish ...picks PC up, takes a step... ...drops PC... clunk! ...cups hands to mouth...Here's one!
Slashdot Mirror
What that should have said in order to be meaningful was "simulating nuclear weapons". But you knew that. :-)
I'd say that the "developed" among us do indeed think they are ridiculous; but we tolerate them because (a) at least 1/2 the population is IQ 100 or under, and there is little point in attempting to appealing to a critical thinking skill that cannot operate in such an environment, and because (b) it is our tradition to tolerate other people's beliefs even if we think they are wrong and would argue a particular point -- and this is especially so if the holder of the belief also falls under the situation described in (a).
Well, that's just because our postal and banking systems mostly work. As someone who has been mailing products to other coutries for several decades, I can tell you that many other countries would do much better if they successfully emulated the American postal system. Perfect, no... but it is very, very good. Of course, we bitch roundly about it anyway. We're a nation of chronic complainers. :-)
The fact is, multiple cores means more processing power, not multiple users. We can already have multiple users with a single core CPU design.
There is no valid "commercial reasoning" for multi-core == multi-license.
What they are trying to do here is leverage a fairly minor technology shift into a way to make more money that they don't have to (a) do any work for and (b) can use to victimize a locked-in customer base.
It is worth observing that mild sleep deprivation cannot be definitely identified as being in the realm of debilitation-by-choice -- you may not even know that you have this problem; it can be a matter of poor sleep, not even lack of sleep.
In stark contrast, recreational drug consumption (including alchohol, of course) almost always is voluntary and you will be aware that you have been involved in such activities; if you aren't, then someone else needs some jail time. Drugging people without their knowledge is criminal in the most basic sense of the word.
Specifically with regard to alchohol, 0.08 BAL isn't reasonable because no voluntary diminishment of skill is reasonable when you decide to pilot machinery that is dangerous to others.
The same thing goes for serious sleep deprivation. I think it is a pretty safe bet that you know if you're seriously short on sleep.
Everyone needs to be in the best possible shape to drive, because driving is a very dangerous activity.
The fact that this isn't the norm in society reflects only that society is made up of ethical cripples.
FYI, I am in the real world. I've seen the deaths and injuries that come from drugged drivers; I've seen them up close and personal, and lots of them. I was married to a surgeon in rural America for quite a few years, and I can tell you that this isn't something that "lighten up" is the appropriate reaction to.
It's not OK. It'll never be OK. You can't make it OK, and you can't make it seem OK. Grow up before you fuck somebody up.
No. A grown man, intentionally decreasing the speed and accuracy of his reflexes by voluntary and knowing consumption of even small amounts of a recreational drug and then getting behind the wheel of a car -- that is stupid.
There is no "ok" level of recreational drug consumption that entitles one to say "I'm ok to drive." Drink and ride, abstain and drive. The ethics should be clear to anyone.
For the record, if anyone "happens" to hit a family member of mine with a machine they are piloting and it turns out that their blood alchohol level was not zero, I'm going to rip their head off and shit down their neck.
I absolutely support anyone's choice to use recreational drugs; but that in no way absolves the user of responsibility -- operating dangerous machinery does not somehow become the appropriate thing to do because you think you "only had a little."
Your rights end where mine begin. Violate mine, and as far as I am concerned you lose yours. All of them. Including the right to breathe air.
If I go that way, I've not bought the OS at all. But I still have the opportunity to write applications for the widgets, because there is no cost or obligation for using widgets under Windows, contrary to your attempt to make it seem so.
You just can't accurately say that charging for the OS, or the development tools is the same as charging for the widgets. It's not the same thing at all. And if you really want to get into realistic assessment of costs, Linux has cost me more in time to get set up, and I still don't have a generally usable set of widgets I can target. My time is expensive, and by that metric, Windows is not -- and Linux is.
Re GTK+, it is LGPL encumbered, hence not useful to me. If they want it to be free, then they need to make it free, as in, "here, do anything you want with this." That's free. "Here, you can do this limited set of typical development tasks, but not these other typical development tasks (like mixing my stuff in with their stuff, or proprietary stuff in with their stuff, or patented stuff in with their stuff)" is not free. It is (a) a legal minefield, and (b), annoying to need to bring a lawyer in when you want to just write an application under a GUI, and (c) even more annoying to have the lawyer tell you "nope, you can't use this."
But Linux doesn't have a standard GUI-API, it has add-ons. Tons of them. All with different licenses and costs and limitations and features. All I want is for Linux to develop a nice, standard set of widgets -- basic windows, buttons, checkboxes, lists and so on -- that I can legitimately use without having to read and subsequently compensate for a bunch of legalistic crapola. I want these to work on every Linux machine, and I don't want to have to compile the application for every variation of Linux out there. As long as these issues remain unsolved, I'm not interested in going forward.
Anyway, Windows widgets and use of the API is indeed free. You can do anything you want with them, from any software platform or cross-development environment you can manage to cobble up, and no one will ever say "boo."
That is exactly what we did. We offer a far more powerful interface, mouse-wise, than Photoshop does. And of course, that means it is quite different in how it handles. We put in an "operates like Photoshop" mode so that those who were not willing to consider the method we chose would not have that as a reason to dismiss our software out of hand, and so that we could continue to develop and extend the more powerful interface without having to deal with random "but I'm used to the other way" complaints.
And for the record, it's worked out very well for everyone. :-)
That just means that either you don't know about the better working methods that can be found elsewhere, or you don't know how to use them very well. No big deal. That simply says you're in the same boat as most other Photoshop users, not that you're a sub-standard graphics person.
There are definitely better ways to work than "the Photoshop way." Better because they are faster, more efficient, more precise, more flexible. Then again, Photoshop is what people are used to, and that is the key here -- not that it is UI perfection, but that it is pervasive and for many tasks, it is more than good enough. Habit counts here as well.
A couple of months ago, a friend of mine who is really a pretty expert Photoshop user, was working on an old photo. He was using the healing brush and the clone (pantograph) tool to fix the thing, and he was definitely getting it done. It seemed quite slow to me, because I don't do it that way -- I use something more efficient. I knew he had the other tool on his system, so I got him to start it, popped the image in there, and got the entire healing job -- the complete scratch, which he hadn't yet finished after several minutes -- done with one area selection that took about 2 seconds to complete. I explained how it worked, and why, and his reaction was "wow", but you know what? The next day, I found him back in Photoshop, fixing a different scratched image (these are scans of very old family photos, lots of damage.) I asked him why he wasn't doing it the way I showed him, and looked kind of guilty and said "This is warm and fuzzy... I'm comfortable doing it this way." I just said "cool" an walked off. I think that says a lot about who uses what, and why. This guy is bright, skilled, and generally pretty open minded. But then again, he's very "comfy" with Photoshop and that directs his actions to a very large degree. I don't think this is unusual, either.
On the other hand, if we're going to talk about maximum potential efficiency, that is, how fast a particular task can be done to an equal degree of precision given two diverse approaches, for many tasks Photoshop's one-mouse-button approach falls short of other mechanisms -- this is also the case with some other UI issues and technical capabilities it has (or doesn't have) that are lacking in efficiency and flexibility.
These things typically aren't a big deal unless maximum efficiency and flexibility and speed are issues; if they are, then it is worth some time to look elsewhere. There are some advanced UI approaches out there, several of them quite interesting and useful. And definitely faster.
If you like painting with brushes made of images, then there are some cool tools out there that leave PS in the dust. Which ones might surprise you if you've spent most of your time with Photoshop. If you are a "Master Layer Blending Person" then there are far more advanced image layering systems out there. If you like writing plug-ins, there are easier to develop for plug-in interfaces that provide some really neat things and are far easier to write to. If you are really into efficiency, there are definitely better ways to utilize the mouse. If you are into scripting, there are custom BASIC, python, and "other" script-driven interfaces in some of the other packages that are really quite complete and powerful. There are systems that handle deeper bit-depth images more completely, or consistantly, and there are systems that do more flexible color separations (try mixing UCR and GCR approaches in Photoshop and I think you'll see what I mean about flexibility.)
Photoshop is great. No question about it. But it is not the be-all and end-all of graphics software. It is just the most popular. Part of that is functionality, but another part of it is marketing and simple user enthusiasm, something that can have roots in paying a very large amount of money for a package and then getting done what you wanted to get done. That doesn't mean it's the best way to do something -- it just means this way works.
I don't think it's even a question of if MS could; only a question of if they would want to. If the Ps3 can truly kick the XB2's butt (and that's as much a matter of software as it is of fabulous hardware) then just perhaps they would.
MS might just throw the current XB2 design in the toilet and sell software for the PS3, too. There's nothing quite so predictable, yet as blatently unexpected, as tomorrow's news. I saw that coming! Yeah. Sure I did. :-)
What's that you say? MS wouldn't invest in supporting a hardware architecture and then just let it go? Er... NT Alpha. NT PPC. NT MIPS. Here yesterday, gone... yeah, yesterday, that's the ticket. XB2? Not here today... and not here tomorrow, either?
I bet there are a lot of XB2 engineers crying in their beer tonight. It might not be as bad as it seems, but... it sure seems pretty bad. Beer with salty tears. Yech. :-)
Oh, I don't know. Microsoft could just up and buy IBM. They might have trouble buying Sony, given that it's not a US company and that Japan has been known to be fiercely protective of its corporate citizens, but IBM? I doubt that'd be a serious problem. If it breaks laws, they'd just buy the politicians -- and it wouldn't be the first time.
Never underestimate the power of cash to alter the world you live in.
No. There are strings attached. The reason you don't know this is because either (a) you have not read the LGPL, or (b), you didn't understand it.
If (a), go read. You're just making yourself look uninformed (not to mention the silly namecalling... what, are you 12 or something?) If (b), I'm sure I'll figure it out next time you post, no further action needed on your part. :-)
In order: C, Win32, and none. As I mentioned previously, and as you would know if you had read the thread, we stopped the whole Linux port before we got to code because of the legal issues. Cost is not an issue. More is available for this project than it could possibly cost. We've ported three times; never did it go over budget or over time. Time is a big issue. Legal encumbrance is a big issue. Stability is a big issue. IP protection is a big issue.
Just to be clear, I am sure we could code to pretty much any widget set without much trouble, assuming it is reasonably feature complete (in other words, I am leaving out utterly silly ones like those that don't have menu support or only run under certain desktops) and assuming the widget set doesn't require that you use something other than C to get at it.
I see. Well, when you've actually read the LGPL, you come back and give me an informed opinion, K? Thaaanx.
Hmmm. Maybe you're confusing my posts with someone else's posts. All I've been discussing is an unencumbered widget API so that applications can code to a standard target. This is a very specific area and that's all I am talking about here. We don't need any libraries other than those required to interface with the OS, basically we need to be launched, we need fopen() and friends, malloc() and friends, and we need a graphics API that supports windows and controls. Collectively, widgets. But there is no graphics API (I refuse to count xwindows... it is far too awkward compared to more modern current metaphors) In Linux, what we have instead are a wide variety of widget sets.
I am agitating for a standard, with-the-OS, and so always-there-to-use, widget capability. Windows has this. The Mac has this. Linux does not have this. I would like Linux to have this. Instead, Linux has this, that and the other thing from third (and fourth, and fifth) parties, and when you try to install an app you're just as likely to be told you can't do that because you don't have the latest and greatest this that or the other thing. I don't want our customers to have that experience. Ever.
Now, you can tell me why you think Linux should not have this, and I will pay attention and (perhaps) even respect your opinion, especially if you read the LGPL before you next reply. :-) However, if you try to tell me that gnome is a widget set, I will proceed to ignore you for what I hope are obvious reasons.
Certainly, I'm quite familiar with the process. But what made you think we would want to distribute a package someone would have to compile at install time? What we want to do is provide an executable that runs when you execute it. We might go so far as to provide a tissue-thin w
No. This is for linking the library into the application. You should read the LGPL. Not to mention the rest of the thread. :)
No, in fact, they do. They both provide support, fixes, workarounds, suggestions and code. However, if you roll your own for Linux, you can do this yourself, which is interesting and about the only point in its favor, frankly.
No. It's not. Generally speaking, if I roll a patented technology of ours into a library, I can proceed to distribute the library no problem. This is an LGPL limitation, although it may be a limitation of other non MS and non Apple libraries as well, couldn't say. There's a big difference between a loadable library and code that's linked right in so it'll always work and doesn't depend on an external component.
The point was that if you include an LGPL'd library, you may not be able to include other libraries because the LGPL says so. It's a legal minefield for developers. I decline to walk in it.
I suggest you do yourself a favor and actually read the LGPL. It's very interesting. :)
Aside from that, there is a huge difference between one well defined, encumbrance free target and the multiple encumbered (and moving) targets that comprise the Linux patch-a-GUI fractured environment. No amount of bluster will make this not so. The only thing that can fix it will be actually fixing it. And in the interim, you'll continue to suffer from a dearth of commercial apps. Yes, certainly you have some. But you could have more. You don't have any of the big three graphics programs, for instance, and the OS sure could use them, given that the GIMP is all you have right now.
As for your other comments about graphics, thanks, very interesting. Also very funny. You might want to do a little research before you wing it like that; In fact, you should do some right now. That'll give you time to pull your foot out of your mouth; the poor thing is sizzling in your stomach juices presently. :)
No. It isn't. You pay with obligation if you're not paying with money. You also pay with time, because a lot of this stuff needs work, you have to pick and choose which one, etc. Time is money. With MS and Apple, the GUI just works, and you don't need to worry about it. You just dig in and make your app. That's what it is about. Not "choice", I and most other commercial developers don't give a northbound rat's southern expanse for "choice." What we want is standardization, functionality, reliability, and a well defined API. Truly, you can keep your "choices" -- they cost too much.
Perhaps you can (MS will definitely give you the code given some "I won't tell" legal t-crossing an i-dotting, don't know about Apple), but why on earth would I want such a thing? All I want is a defined API. I have no interest in how it works, just that it does work. We spend enough time writing our own stuff that we have very little interest in looking at the OS code. Define the API and you're done, as far as I am concerned.
As for older MS IDE's "not being very good", that's nonsense. They're not as up to date, but they contain significant debugging tools and pretty much everything you actually need to get an application done. I am speaking from experience here. WinImages is built using an older VS, and it all works just fine. No point for you on this one.
Now, not using recent OS features can be an advantage. The more recent OS features you use in a commercial application, the more you limit your audience. For instance, if you choose to use an older VS and the libraries that come with it, you can write code that will run without any modification or hoop-jumping on everything from Win95 to XP. Look at putting the current GIMP on stock RH9, which is actually a very recent distribution if you think about it; yet, it simply won't go. GTK+ requires later stuff and there are other issues as well. Basically, if you want to build the current GIMP, you need a significantly more current system. It doesn't have to be that way. This is a shortcoming of the GTK+ widget library design.
Well, to you, perhaps so. My situation is that I have a complex, powerful product I'd like to bring to Linux. Every path we could find had significant roadblocks on it. Many of them were legal pitfalls, but some had amazing shortcomings (like, widget sets with no menu support!) What I think I know about Linux at this point in time is that to get our app ported in such a way as to work on the very largest set of machines without legal pitfalls and unacceptable source code obligations seems to require that we build our own widget set and incorporate it so that all we require from the OS is xwindows and basically fopen() and crew. Right now, that's too much, so a port isn't going to happen. YMMV as your requirements do, and of course, I may discover something tomorrow that obviates all of this, but this is where we are today.
In very sharp contrast, when we looked at porting to the Mac, it all went smooth as butter. Standard GUI, standard API, dev tools all lined up and ready to go. So there is a significant difference here, much as you might not want to acknowledge it.
When Linux gets a standard GIU-API, it'll have "grown up" as far as I am concerned as a developer and commercial software provider. In the interim, our port to Linux remains on hold.
Also -- about the direction of your reasoning -- if you want to develop for Linux, you have to buy a computer. If I buy a Mac Mini, for instance, I've put out $500, I have the computer, the OS, and the development tools. I spent a lot more on my Linux machine, and then I had to fight with it for many hours to get it configured. My Mac was ready out of the box, and I can tell you that these two factors make the Mac a lot cheaper platform to begin development on than a Linux machine.
Our Windows development systems are more expensive because we buy Visual Studio; but again, the up-front charge isn't a problem. It'd be a problem if we couldn't develop for Windows 98, or if we couldn't use a treeview widget if we wanted to distribute a modified version of the widget, or if we were required to give out our source code. But once you have VS, you can develop anything you want, using the widgets any way you want, and there are no limitations on you at all. That is why QT and GTK+ and the rest of this is different. They're a legal minefield, and no one with half a brain is interested in walking through one of those. Hence, very little commercial closed-source development on Linux.
When and if Linux gets a standard, reasonably modern OS-level GUI-API, things will probably change radically. Until then, the reason you can see all four walls at once is because you're still stuck in that corner. :)
A simple announcement on some place like slashdot would go a long way towards building an initial community, too. Later, a note in your slashdot sig. On your website. In your email signature. Or whatever. Make it easy to find the network, and from there on out, the network has no central point, and it is irrelevant where you entered it from.
Add a plug-in to your browser that scans for "I am on the network" HTML tags. As you browsed the web, your connectivity would grow, no action required from you.
If there is no easy find as at first, then a scan is a perfectly viable early stage alternative.
Encryption is important as well. No one should be able to see what you upload or download. But that is pretty trivial at this point in the game.
My main point is that you absolutely want to avoid a central server of any type, or you've brought "the man" into your computer room.
Well, no. Because as we go above "average intelligence", we have to go quite a ways before we begin to get into the realm where people are really able to deal with technical issues. You have to get quite a distance away from 100 before people are generally going to be able to perform well; and even that isn't a given. That's why (a) it is interesting that more than half already land at the 100-or-under level, and (b) why I said "of course, there are a very large number at 101, 102 and so on."
The post I originally replied to observed "there are far mor(sic) stupid people out there than you seem to realize." My comments were relative to that observation, in the current context of P2P and the technical and IP issues that underlie P2P. So my comments direct your attention to the mass of folks in the midde-ish areas of IQ; what we have here is technology that is not ready for the unwashed, yet they have it anyway. It's no surprise there is fuckarosis happening. :)
Windows and the Mac provide GUI/widgets for free, no restrictions whatsoever. Widgets which work in all cases, from any language, upwards compatible without recompile or legal hoop jumping or the requirement to provide source for this, or binaries for that, or recursive versionitis fuckarosis (for instance, try getting the GIMP going on a stock Redhat 9 system and you'll see exactly what's wrong with GTK+'s ability to interoperate from a commercial standpoint.) Until/unless Linux handles these issues, Linux is in a corner.
GTK+ isn't a good answer. It isn't even an answer in some cases.
Linux comes with plenty, and there's plenty you can immediately add without too much effort. Fine. No argument (I'm a Linux fan, I'd be very unlikely to argue this point.) However, that doesn't obviate the point that there is more to be had, and if Linux was more compatible with commercial efforts, we'd definitely have more of those things (I say definitely, because the fact is I get to make some of those decisions. :)
In my particular area of expertise, the GIMP is "what is available" for Linux. But I have access to something quite a bit more powerful than the GIMP under Windows; despite the years of development put into the GIMP, and ignoring, for the moment, the terrible compatibility problems the GIMP has with not 100% up-to-date Linux systems, the very best that the latest GIMP has to offer, assuming you can get it to work, isn't good enough. For instance, it is ridiculous to contemplate going back to twenty-odd layer blend modes when your workflow normally spans seventy-plus; it is a royal pain in the butt to only be able to see one layer at a time; when CYMK work is required, you're simply out of luck; it is hugely annoying to have to select an area, then go select the op, then select, then op, ad infinitum when you are used to working by setting up the op, then selection, selection, selection... etc. Your working speed is reduced by a factor of (at least) two. There are many more issues like this, but these are enough by themselves to pretty much leave the GIMP unused around here.
These kind of things are like being forced to drive a golf cart to work after you've been driving a car. You can't go back -- or if you do, you wave your hands about saying, look, I'm using the junk transport!
Now, the GIMP is free, and as such is definitely worth eve
I didn't make that claim. I explained that more than 50% falls at or under the median, which is an accurate observation, as well as being not at all what you said.
Think about it. If you have ninety eight 100 IQ folks, one at 90 IQ, and one 110 IQ, then 99 of them fall at or under the median, and the average, both of which are 100. There are an equal number of data points on either side of the median; one per each side.
If the knockee has the P2P app, it'll answer, and the two apps can have a nice little chat. If not, no answer, and on we go. Plus, of course, you can just manually add people you already know have the app.
At a 2nd tier of connectivity, as clients learn about other clients, they can (slowly and reasonably) share client lists with each other, and pretty soon, you'll have a good sized network connected P2P with no central server at all.
The only people with logs of who has downloaded what would be the people doing the downloading/uploading. Assuming you kept them, which isn't a given.
Add solid encryption; stir to taste.
I mean, really -- how hard a problem is this to actually solve in a final and complete manner?
It seems to me that the P2P developers are not trying very hard.
IQ is a metric that is designed such that both the median and the average fall at 100.
A 100 IQ as it fits the populace today denotes someone quite restricted in ability when we're talking about understanding abstract concepts.
Now, on first glance, you might think that the average and median falling at 100 means that 1/2 the people have an IQ of 100 or under, but that is not correct.
Because IQ is a curve with a decided hump in the middle, there are more data points in the center than there are anywhere else.
That means that the correct assessment is that more than 1/2 the people have an IQ of 100 or under. And of course, there are a very large number at 101, 102 and so on.
This illuminates many social problems, including P2P use for purposes that would make tracking one's identity a potential problem for the user.
Of course, it is not only the 100-and-unders that get into trouble; you can attribute that to a lack of critical thinking skills and/or not being in the habit of using them if they are present.
In other words, you don't have to be stupid, to act stupid.
Think of electrons in a wire as a pipe full of ping-pong balls glued to each other. The electric company is just pushing and pulling on ping pong balls they have, so that the ping pong balls you have will move.
Also, under Windows, if you want to purchase development tools (Visual Studio or otherwise), you certainly can. Still, there are free ones out there, and you can go quite a long way with those. The Mac comes with everything you need; when you buy the machine, you get the tools. And of course the GUI-API and widgets are 100% "there" on the Mac as well.
Under Windows, you also have the option of using an older, very much less expensive version of Visual Studio -- those are still 100% functional and produce fully functional applications under XP (and 95, 98, 2000, and NT) and I see no reason they won't remain so.
I think that if Linux ever matures enough to "come with" a standard, always-there, reasonably modern GUI-API such that software can be directly written to and for it, you'll see a significant burst of commercial development, porting and deployment. Until then, the job of trying to figure out what toolkit has the fewest warts and gotchas will be a significant stumbling block for commercial developers. I know it was for us. We shelved our port-to-Linux project for this very reason. As our application is a large one in terms of code, comments and OS window/widget objects, we need to be extremely conservative about launching a porting effort. The cost of a late-stage failure or roadblock would be very, very high.
Linux has really worked itself into a corner here. There is a bizarre social aspect, a "we don't need your steenking commercial software" attitude that will probably keep it there, too. It's interesting to watch.
The scene cuts to Jamal, standing in a muddy field, holding the 100 MHz pc