1. GC forks as a rip of an X11 program, at that time it is an official GNU project.
a. All correspondance regarding personal finance packages will be forwarded to GC developers.
b. FSF includes a link to GC.
c. GC acknowledges itself as a GNU project and includes a link to FSF.
d. GC developers at that time opt not to use other technical services from FSF.
2. GC development continues via a private firm.
3. Firm goes under, but assigns copyright to FSF.
4. New generation of developers on GC forget about their relationship with FSF and create a web page that doesn't link back to FSF anymore.
5. RMS notices and asks them to fix it. FSF is still pointing to GC from its web site and forwarding messages.
6. Original developer chimes in and provides the history.
RMS is NOT trying to hijack this project. FSF has original copyright on 90% of the code -- it's their project. The current developers are actually working on a fork even if they don't realize it. If the GC developers try to distance themselves from the GNU Project, RMS will be completely correct in trying to find a new maintainer for their branch and on insisting that their branch remains the original trunk.
Example 1: GNU Emacs vs XEmacs. Even though XEmacs is out there, FSF needs someone to maintain the Emacs that is part of the GNU Project.
Example 2: GCC vs EGCS. GCC development stagnated, EGCS became the new GCC and the new GCC is the official GNU Project C compiler. Forks can return.
Given the history that RMS knew, and the fact that that history was backed up by the original developer, the question on the thread of whether or not GC is GNU Project does indeed become "Do the current developers on GC want to work on a non-GNU fork?"
When BitKeeper tried to pull similar shenanigans, Linus dropped BitKeeper like a stone, and wrote his own source code management system, called "git."
Note that BitKeeper's eventual "shenanigans" were predicted by RMS when everyone else called him paranoid for thinking a for-profit entity might someday change its mind.
No, it was a real and concrete question. Is a company acting in bad faith if it ships its embedded GPLv3 product with just exactly enough hard disk space to run the software it ships with, but no more? Or if the software is burned into EEPROM and unupgradable?
It's a question that you can't answer. Neither can Linus. And that's why we're worried.
Actually, it's a question that is easy to answer: if a company has a product with GPLv3 code, and that code is physically user upgradable (e.g. hard disk, flash), then the company needs to comply with those provisions of GPLv3 that apply in this case: users should be able to replace the GPLv3 parts with their own versions. So Tivo would NOT be in compliance with GPLv3-licensed software due to the DRM keys.
If a device is NOT user upgradable, then complying with GPLv3 just means contributing back the source. RMS has stated similar views regarding ROM-based applications: if the user can't upgrade the device, then GPL compliance means source code availability and no more. By example, it would be very unreasonable to expect a Linux-based MP3 player to ship with everything required in the player to replace all the software (such as a large hard drive, video/keyboard support, etc.).
In your contrived example, if a company goes to extraordinary lengths to prevent upgrades of ANY kind, then it's just like running GPLv3 code in ROM: that's ok. If they use measures specifically to prevent users from upgrading but allowing the company itself to, then that's NOT OK as per the draft of GPLv3. Limiting hard drive space is only one way to do that, they could also sign the software ala DRM, modify the kernel to use a special procedure such as allowing writes only to specific disk blocks or using an undocumented ioctl, or resort to a hardware dongle. In all the cases it's just this: if there is a software upgrade path available for the hardware manufacturer, then the user must be able to use it too for GPLv3 software. If the manufacturer doesn't like that, they are perfectly free to use any of the multitude of software available under other terms.
You can see this clearly in the way he tries to name projects after himself, and in the way he tries to micromanage projects that he has really very little involvement with!
I followed your link to the discussion regarding GnuCash. RMS sent an email a) congratulating them on a new release, and b) asking them to clarify their web page in a very minor way to reflect the history in a way that the original author (Linas Vepstas) agrees is correct. As this message points out, GnuCash did in fact start out as an official GNU project and a significant churck of code (about 90%+) is currently copyrighted FSF. It also spurred a discussion that resulted in a clarification within the GnuCash team about their relationship to FSF (which is generally neutral/positive) and Gnome (which could get better by a lot).
...and these guys are preemptively coming out and saying that it wouldn't be a good idea even if it were possible.
So why didn't they just announce that it isn't possible and stop there? Why go further with the value statements about GPLv3? This would certainly have sufficed if their purpose was just to discuss v3 as it relates to the kernel:
"The kernel is at GPLv2 and will stay that way, end of story. For those of you who dearly love GPLv3 for whatever reason, sorry, we can't do it with the Linux kernel. If you really want a full GPLv3 toolchain check out (... list of obscure kernels that are GPLv2 and could go GPLv3...) or fork a BSD kernel."
I read the thread at http://lwn.net/Articles/200422/ and I have to agree that it sounds fishy that they went to all this trouble. So they are critical developers, well experienced, etc., but if they are so cool with Tivo DRM (because Tivo does return source code), why do they care if the GNU toolchain goes GPLv3? Someone else on the thread mentioned that embedded consumer devices will likely work from a GPLv2-only fork of the toolchain as if that's a bad thing. If all they care about is the fact Tivo et al return code to the kernel, why should they care if Tivo et al deliberately choose to use an obsolete glibc?
Their fundamental argument seems to be: "We're engineers and we're happy that this high-quality product is both available for end users " (me: who they still seem to think means device manufacturers rather than consumers) " and for us to play with, and so long as the source is available to us under the same terms we made it available to everyone else we are happy."
Yet they are saying in the thread: "Third parties will restrict all users freedom; that is a given. They will select software that enables their business objectives.... What is going to be the impact of adopting GPLv3? You wont have anyone using your software."
Is this really their beef with GPLv3? If so, it sounds like they're more in it for the notoriety ("my code runs all over!") than any kind of technical achievement.
I'm not dissing their technical merits, but I have to agree with other threads here that their statement about GPLv3 is not well supported factually, seems to (deliberately) misunderstand GPLv3 (especially the DRM and patent clauses), and serves only to provide cover for embedded device manufacturers over the concerns of both distros and end users. It feels very much like a group of people who are defending their lucrative industry niche at the expense of the very factors that helped create that niche in the first place.
Re:Languages continue to evolve into ... Lisp
on
Python 2.5 Released
·
· Score: 4, Insightful
About half a year ago, I tried to get into Lisp. It sounds like the holy grail - execution speed and error checking of a compiled language with all the speed of development of more dynamic languages. Perhaps s-expressions should be perfectly suited for HTML too (I'm still stuck in this web app world, at the moment). So I picked up Practical Common Lisp, installed SBCL, joined some mailing lists, found some libraries, got experimenting...
Two things meant I got disinterested in a month or so: it has far too many slightly-differently-named functions in the standard language, many with non-obvious names too (that's what PHP gets its harshest criticism for); and also the huge library of things you need nowadays (internet stuff, databases, OS stuff, etc) is either missing or rather undeveloped.
All very true criticisms. I too have switched my new code to Lisp for the purpose of being a better programmer (and because I've got two years in a MS program to get my basic math toolset switched over). It IS getting better, and faster at that. I think we're approaching critical mass of people adopting it and pushing it into the Python/Java/Perl/etc. space with sockets, threads, SQL, UFFI (now CFFI), etc.
I think the biggest problems I've got with Lisp are packaging, pathnames, and the REPL.
Packaging means ASDF, which I don't like at all compared to Java or Perl's filesystem packages. To get a package with dependencies to work OK, you've got to create a.asd file and add a defpackage to either a separate.lisp file or your main one, and the.asd specification is not documented well (the wiki page for setting up sub-modules is flat-out wrong).
Pathnames... UGH. I've already had to write my own version of a java.io.File just to have a string that is guaranteed to refer to an actual file.
REPL. Well, it's very nice to be able to talk to a running Lisp, especially when the Lisp is an application server and you want to alter some values or force a reload of an app, or just to poke around and see what kind of stats have been collected. However, the distinction made in the spec between compile-time, interpret-time, and run-time for code makes some things difficult, e.g. defconstant is completely useless with SBCL. I like REPL, every book should mention it, but they should very quickly move OFF REPL and show people how to just load a.lisp file and run it. The implementations should also make it easier to tune the output of the Lisp (try to get compile-warning's squished in SBCL, it's not pretty).
I would LOVE (and gladly buy two) copies of a book that had this information in it:
1. What is Lisp, and where to find the community web sites 2. How to locate, download, and install all the major Lisps on Linux, Mac, and Windows 3. Basic language grammar, including CLOS 4. How to use ASDF (including complex examples) 5. How to fully interface with the operating system, including implementation-specific functions for file i/o, network i/o, command-line arguments, the environment, threads, and more 6. How to package a standalone Lisp application to deliver to customers 7. How to use UFFI 8. How to set up a Lisp web application server (modlisp or Araneida or...) 9. How to use the most common libraries: CLSQL, OpenGL, SDL
I know Lisp'ers love (and I do too) the fact we've got a spec and multiple implementations, but dangit if it isn't really difficult to get it all together and be able to actually DO something with it within a couple weeks.
Imagine for a second if Jerry Falwell and Oral Roberts teamed up and decided to turn their army of Christian fundamentalist drones into a revolutionary army (even if a peaceful one) against the U.S. government. You think the U.S. government would just let them?
You think they haven't done it? Go look at the Republican Party agenda sometime.
The only thing that'll make them reconsider is a mass exodus away to a competitor and to be frank, I don't see that happening.
They lost me, and I barely used it. Every heavy Facebook user I know has joined an anti-feed group. I think they could easily lose over 5%, maybe even up to 15-20%, of all existing users, and with the news "features" they could slow down adoption of new users too.
This reminds me of the uproar when dejanews first appeared on the scene. All these people who had made public posts to usenet under a mistaken belief that what they said would never go beyond the little "community" of that group were very unhappy to see all of there messages in a searchable database.
That's an exceedingly analogous situation, and that's exactly what I thought too. When dejanews showed up, I thought it was lame and no one would use their www version when compared to the power of the full-blown client newsreaders; then a few years ago I saw the search facilities in Google Groups and saw my entire posting history going back to when I was *16*. By now every one of those posts is so old no one will care (plus I never learned Elvish or wrote posts on sex), but I got the point: I now use Usenet only very sparingly and only in a very professional manner on the assumption that any employer may see it years down the road. I also cut back a lot on Slashdot when I saw how many sites out there blatantly rip threads and get them into the search engines.
I didn't use Facebook much, but I liked the fact that people in my classes could at least see who I was, note that I was happily married, and maybe notice a blurb about a great job opportunity with a cool group I had worked with recently. But now my Facebook account is deactivated and will stay that way even if they turn off (or allow users to tune) the "news feed" and "mini-feed" functions.
More than anything, the Facebook team has shown me that they are both capable and willing to implement a historical profile auditing function which spits in the face of social norms. We do not post lists on people's doors that include the contents of their grocery carts over the last six months, and we do not email photographs of every post-it note that appears on a whiteboard to a list of fifty people. Online, we expect personal profiles to be current only, to be "live", not to track their own changes and provide search features on deleted information, even if third parties such as the Wayback Machine and Google Cache might sometimes be able to do it.
Precisely. You haven't seen it, you've got no idea what it feels like. I'll spell it out for you.
You log in, and on your homepage is a list of items that have changed on all the people on your friends list, including things like this:
so-and-so has joined group "There is a difference between retro and Euro-trash, and I crossed it!".
so-and-so has removed "books by Carl Sagan" from their interests list.
so-and-so is now sleeping.
so-and-so is now friends with so-and-so.
so-and-so has dropped ECON 101 from their classes list.
so-and-so has added pictures to their "Trip to Cancun" photo album.
This is on your homepage. To continue with your analogy, it's like going to google.com and seeing a list posted below the search bar that includes people in your street, from your hometown, and at your job, with each list item being a DUI, divorce, job promotion, new child, death in the family, and contents of their last trip to the grocery store. All updated within seconds. You CANNOT go to google.com and turn this list off either, and your browser is set with google.com as its startup page and you cannot change that. Your Facebook home page and the "news feed" are the gateway you must go through in order to use the site at all.
Each message looks quite innocuous, but taken together it becomes very creepy. I only had about 20 people on my friends list, mostly from a college-age church group who use Facebook all the time to organize events, but since they were used to Facebook and edited their profile routinely I immediately had dozens of events in the "News Feed" and suddenly I was seeing way more than I ever wanted to see. It wasn't MY public information turning into public announcements, it was theirs, but I felt slimy seeing it all in one place and immediately knowing so much more than they had intended to present. For instance, each event is timestamped, so you know exactly when your friends are online and not. And by seeing the sequence for any given individual, you can infer pretty quickly if they are feeling up or down too at that time.
To analogize, imagine if you were walking into a small singles group event (bowling, dinner, movie, etc.) and you had spent some time out in public before you got there: here is where you bought the shirt, over there you had lunch, yesterday you rented the musical Rent, last week you were seen leaving a party that was later busted by the police. Now you walk in to that singles group and there is a floating sign above your head with all of these things printed clearly for everyone to see. Instead of someone saying "Hi my name is so-and-so, who are you?" you get "Man, you like Rent? You're so lame!" You lose outright the ability to control your own presentation, what we used to call in the old days being appropriate. This feature (the floating thing right over your head) is the "mini-feed", which also can't be fully turned off. You can hide specific events but you have to do that every single time you make a change.
Everyone likes to say, "But it's the Internet, and it's public! Stop crying about privacy!" Yes but. The outside of your house is public too, but would you be cool with someone videotaping everyone coming and going through your doors? How about an inventory of your pantry and refrigerator posted on the street next to your mailbox? The point isn't that this information shouldn't be public, it's that automatically combining it in the right context tells people far more than you ever intended. As civilized people we routinely "forget" things that we see around us all the time (such as the contents of someone's grocery cart) precisely to respect polite boundaries. We know it's just a polite fiction, yet it's one we all do.
Insisting that "it's all different on the Internet" particularly in regards to social sites is silly.
The problem lies in that no one has the stomach for really turning them loose to do just that, and thanks to the speed of modern news networks, no one can get away with Dresdens or Hiroshimas anymore.
That's not a problem, that's a feature. "Turning them loose" to deal with Iraq would lead directly to the elimination of practically all life on Earth once the first nuclear weapon was used. I'd rather have us "lose" than throw 4.5 billion years of evolution down the drain.
Something seems flawed about a view of economics in which the "rich" are automatically bad and do not deserve money, while the "middle" are expected to do nothing but aquire enough money to become rich.
Conversely, something is wrong with a view of economics that says fundamental human nature changes as one gets wealthier. In Reagonomics, rich people respond only to positive economic incentives (lower taxes) while poor people respond only to negative economic incentives (reduced economic safety net).
I think your statement the "rich" are automatically bad [yet] the middle do nothing but acquire enough money to become rich can also be stated as: "everyone wants to be lazy, but too much laziness is bad."
Can it be observed? Can you repeat it and document the results of the repetition?
Seriously. It's not testable. If it's not testable, it's not science.
No. The Big Bang itself may not be testable, but any theory that requires a Big Bang must also account for how a handful of critical constants in the universe come about. Since those constants ARE testable, and have been tested to death already, any theory that posits the Big Bang is directly testable too.
Next you're going to say that pi or any other irrational number can't be used in mathematics because they require an infinite number of digits to write out.
My view is that God created the universe from nothing. Perhaps you don't find that believeable.
Which God? How did God do it? How can you test your idea of how God did it?
I find the idea that it all came from nothing by natural processes to be ridiculous. If matter is "all there is, all there ever was, and all that ever will be" then the universe should have equilibrated an eternity ago. All heat and motion and should have stopped virtually an infinite amount of time before you and I existed.
Given that there are plenty of energy/density gradients still in the universe, your idea of what is ridiculous is already irrelevant. We ARE here, and the universe is far from equilibrium, and the concept of thermodynamic equilibrium doesn't even apply at cosmic scales where gravity dominates.
Frankly origins is not science and has no place in science textbooks because it's all speculation.
There is a branch of science called cosmology whose purpose is to study origins using what is known of the present and what can be measured from the past. Since we can see photons that were generated over fifteen billion years ago, and we can directly measure radioactive decay, and we are approaching a more consistent theory to explain how matter and forces are related, I see plenty of material available for scientific study of the origins of everything.
I don't have answers for everything, but here are a few:
1) DVDs. I use Debian, just installed testing to my laptop and DVDs work OK out of the box using Kaffeine. Actually, I like Kaffeine a lot better than WMP for DVD playback: not only does it work with a simple and uncluttered interface, it has a simple dialog (hit 'v') that can be used to adjust hue, color, and audio/video sync. The downside is that on my laptop I had to manually adjust the sync to make it right, but I'm not sure if that is something Kaffeine can be made to do on its own (like mplayer) or not.
2) Cameras, MP3 players: my rule is simple. If it is USB and advertised to work on Mac OS X, it will work on Linux. I don't know if that is true for iPods (to me iPods are too expensive), but it's been a good rule of thumb for the devices I've bought (a Canon camera, several MP3 players).
3) Wireless IS a conundrum, I agree. I do think the manufacturers are at fault, but the ultimate problem lies with the FCC's rule banning wireless receivers from certain frequencies. Since it is impractical to make the hardware enforce the law, the checks are made in software and the manufacturers refuse to write their drivers for non-Windows OS. That said, I have had success by looking up the cards ahead of time and picking one that is known to work with Linux.
It would be naive to think that all things being equal, a student from such an educational background is more fit for an intellectual environment. But I guess you don't believe in the concept of evolutionary fitness.
You were doing fine until you leaped into Social Darwinism there. "Evolutionary fitness" vs an intellectual environment? If anything, being a good social fit for an intellectual environment is an evolutionary handicap, as the #1 factor against having children is education level: the higher the degree the less likely one will have children.
So you're ditching Linux because of the proposal that supporting binary/proprietry software is OK - yet you're going to BSD (which can use binary windows drivers in the kernel) or Open Solaris (controlled by Sun) or GNU/Hurd (which for all intents and purposes may as well not exist)?
I think the GP is (might be?) ditching the Linux kernel because there is growing evidence that a movement exists within the "Linux community" (whatever that is) that is actively trying to compromise ultimate user freedom in order to gain short-term acceptance in the mainstream in a fashion similar to Windows and OS X. Symptoms include encouraging users to use binary drivers rather than choose hardware with open-source drivers, implementing technologies to play locked content rather than insist on open media formats, and encouraging hardware vendors to use Free Software in their DRM-locked systems rather than insist they use proprietary or public-domain software.
I too believe that such a movement exists and is gaining ground due to simple fact that it is a software-maker-business friendly position and the megacorps have the money to encourage this view. We'll find out in the next couple years who is going to win -- the short-term pragmatists vs the long-term realists -- when the new LGPL comes out and all the FSF projects move over.
As for the OP's options: GNU Hurd is generally stagnant but could move forward quickly now; OpenSolars is dead in the water; NetBSD could be forked into a GPLv3 version (perhaps called "GPL/BSD"?:) ).
Linux is rapidly being locked out of the mainstream by stupid moves like GPLv3,
GPLv3 is not a stupid move. Face it, there are (at least) three distinct classes of computer users whose interests are now in full conflict due to DRM: consumers, software developers, and content sellers. GPLv3 brings this conflict out into the open and provides some practical leverage for software developers against content creators, sorely needed in these days where the content creators have so much more money to purchase favorable legislation.
Fortunately Linux is not likely to go to GPLv3,
It will be greatly affected by GPLv3 once glibc moves to a GPLv3-like license (still LGPL, but users must be able to replace it). Given: the Linux kernel only works with the FSF toolchain (gcc, glibc), and once glibc can be replaced with a user version that doesn't bother checking signatures on new binaries, the whole TCPA/DRM lockdown comes apart. There goes the Tivo business model.
Linux kernel developers will find themselves thrown into this conflict. Do they *really* want Tivo, or maybe nVidia/ATI, to be able to use the code they wrote to dictate policy on users? If so, they'll need to either fork the entire FSF toolchain (hard) or move to BSD libc (maybe easier). Ironically enough, Linux now needs the FSF more than the other way around.
OTOH, maybe enough critical Linux kernel developers will take the FSF side and fork the kernel to stay compatible with newer versions of glibc. What then? What if something really important (like the SCSI support layer) threatened to fork into GPLv2 and GPLv3+, with many of the knowledgable developers picking only one to work on? Would Linus push for unified kernel development even if he was "forced" to stay compatible with glibc?
Or maybe the glibc developers will split in their camp, creating one version for the Linux kernel and another for everything else; they have just as much reason to pick Tivo's side as Linus does. It could domino against the FSF with a number of major FSF components forking into GPLv2 and ignoring the "GPLv3 or later" version; or it could domino against the Tivo-minded developers with a major Linux distro expicitly forking all "GPLv2 or later" applications into "GPLv3 or later", forcing their users into DRM+freedom. All it takes is two extra words in the project-wide COPYING file and your code becomes a political football for someone else to play with.
Personally, I'm glad GPLv3 is pushing this out into the open. These issues will determine the fate of the 21st Century "information economy"; if developers and consumers don't get a voice we will definitely be screwed.
Even the Microsoft CLI is more friendly than Unix, what with the "help" command.
~$ help GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu) These shell commands are defined internally. Type `help' to see this list. Type `help name' to find out more about the function `name'. Use `info bash' to find out more about the shell in general. Use `man -k' or `info' to find out more about commands not in this list.
A star (*) next to a name means that the command is disabled....
The Linux desktop has become quite usable - but it got there by copying Microsoft, and that is no shit...KDE and Gnome are both pretty hardcore ripoffs of Windows, although GNOME also manages to copy MacOS at the same time... Unfortunately, [Unix] only got there by copying Windows, which kind of blows the whole usability argument to kingdom come.
I disagree. Windows never had selection buffer, virtual desktops, or remote desktop, items I absolutely require to be reasonably productive on X. KDE/GNOME brought us unified widget sets and control panels, and both were certainly inspired by both Windows and MacOS, but they go so far beyond Windows in overall functionality it's not even funny.
I don't see why computers should be any different. Yes I want disclosure about security problems, espically if teh company is slow in getting a patch out. However disclose the problem, what it relates to, what the potential attack vectors, and what if anythign can be done to fix it. Don't go and post code that not only shows people how the exploit works but allows them to just compile and do it. Do that and in all likelyhood my system will be 0wned before I ever read the notice and try to do anything about it.
In an ideal world, a security researcher will discover a fix and do the following:
1) Create code that reliably exercises the flaw that can be used to verify that the problem really exists and that the fix (when it is finished by the vendor/OSS group) works. You can call this the "exploit code" if you want; it is necessary for someone to create it so that the fix in step 3 below can be tested.
2) Notify the vendor/group of the hole and pass along the exploit code.
3) The vendor/group evaluates the problem, assigns a reasonable fix schedule to it, and eventually a fix is produced, verified to work against the exploit code, and distributed to the world.
4) The hole is then announced on a security bulletin *along with the exploit code* to notify customers/users that might not have updated already that they should do so at their earliest convenience, and to provide customers/users (many of whom are knowledgable programmers) the same tool given to the vendors to verify that the hole is plugged in their systems.
This is a reasonable system. The whitehats try to do it all the time, and for many OSS projects it works out just this way. Blackhats OTOH do only #1 and then distribute the exploit code only to other blackhats, so that when they use a flaw both vendors and customers/users are taken unawares.
Unfortunately, many closed-source vendors break the whitehat process between steps #2 and #3. They are given notification and exploit code, but rather than prioritize a fix they decide that no fix is necessary, because their local astrologer told them that only whitehats find flaws. After enough time with no action, the whitehats MUST move on to #4 so that users can isolate the systems with the hole in order to preserve the rest of their network.
In your house analogy, this is equivalent to notifying a neighborhood that the developer who built many of their houses made a serious mistake in the wiring such that any house at any time might burn to the ground, and that their insurance will not cover it, and the developer has decided not to pay for a fix, and the local fire department has announced that they will not intervene to stop any fires that start due to a wiring fault.
A device is available that can quickly determine which houses are at risk. The developer is spending twice as much money needed to fix the wiring on ads in the local newspaper exhorting those citizens who have these "bad house detector" devices to destroy them rather than share them with their neighbors so that they can hire their own electricians.
The process YOU want is already being followed by the majority of legitimate whitehats. The process McAfee wants leaves everyone screwed.
Everytime Slashdot mentions Linux, you bring up wyoGuide as though it's some magic bullet that would fix everything if only every Linux user started adhering to it. I've decided to respond this time instead of move on.
Here are the problems I've got with wyoGuide:
1) It assumes that developers should make new Linux applications that look and behave like established Windows applications circa 1997. Even Windows applications don't do this anymore, and users seem more than happy to use applications with skinnable eye candy rather than Office 97 menus.
2) The example language is C++, and the example toolkit is wxWindows. There are plenty of other cross-platform GUI toolkits, and other languages include cross-platform GUI as a core feature. You'll get more traction if you include more languages (Java would be a good choice, as many CS students are taught that now) and other toolkits.
3) The screenshots are all Windows. Sorry, I've got NO applications on my Linux desktop that look like that. Include some OS X and Linux screenshots and maybe people from the non-Windows side will begin listening.
4) As with #3, your tone in the document and in your Slashdot posts seems to put most of the blame on Linux developers for not making their applications resemble Windows, and then you go on inside the document and make wrong statements about non-Windows platforms:
a) Section 10.1: Linux already has a defacto standard for application paths: binary/symlink in/usr/bin, application data (including app-specific libraries) in/usr/lib/appname, documentation in/usr/share/doc/appname, and top-level configuration file in/etc/appname(.conf) . Desktop Windows applications ported to Linux should use this standard, not some dump-it-all-in-one-place-any-structure-you-want Windows-style solution (which you call "the easiest solution").
b) Section 6.1: preferences dialog. Many Mac applications do not have "Apply" or "OK" buttons, they simply apply immediately and you close the window to get out.
c) Section 3.7: On Linux, the Ctrl key is Ctrl, the Alt key is often called "Meta" but modern desktops often just leave it as Alt. Any Linux app that used Alt-C/X/V instead of Ctrl-C/X/V would be broken.
5) More of the "at all costs, make it resemble Windows" criteria in Section 3: "The standard entries in the file menu have their defined command keys as shown in the sample, if they have any. These keys are reserved and may not used elsewhere, not even if the corresponding menu entry is missing." I see that menu and think Office 97 (except that the editing filenames should be below Quit). Some applications might want those keys for other things, and some users might want to remap those functions to other keys.
6) What about keyboard accelerators, ala Alt-F -> File menu dropdown? If you're going to mandate/suggest the keyboard shortcuts, you may as well include the accelerators too.
7) You mention the Windows registry barely in passing in Section 6.3. It needs more than that: Windows applications must use the registry _correctly_ such that non-admin users can use their application.
8) You added a section for coding style? Now I'm beginning to think that you might not actually write a lot of code.
In short, when I read wyoGuide, I see a document telling me how to use one language with one toolkit to make an inconsistent Windows-like application with some "helpful" newb tips at the end.
Let me offer some suggestions:
1) Move the code snippets out to separate links. We're talking HCI design, not "low-level" implementation. Coders can always click the links to see source code snippets. And an HTML page with annotated source that links BACK to the wyoGuide would be nice.
2) Focus on successful applications that have already proven themselves cross-platform, such as Mozilla, Abiword, Gaim, LyX, etc. Show screenshots
We use StarOffice for most of the PCs here because Texas' stupid "Robin Hood" law strips us of about $22,000,000 a year, forcing across-the-board budget cuts.
As a Texan myself, I say yippee. Do you really expect that if Robin Hood disappeared the multiple school districts benefitting from your $22 mil would be able to purchase Microsoft Office for _their_ students? Of course not. The whole point of Robin Hood is to force all Texas schools to suffer the consequences of extreme inequity. Poor districts can't afford things like adequate numbers of teachers and buses, hence your school can't afford software licenses for elective computer classes.
Tell your PTA that if they really want MS Office they are welcome to individually donate licenses (at $300 each) or cut funds from more expensive extracurricular activities like football. (Maybe _your_ local community will prize computer software over football, mine sure didn't.) Or they could vote in a state corporate (or personal) income tax to shift the funding burden away from property taxes.
Doh, made a mistake. Actually there are 16,298 total physical library outlets (including branches but excluding bookmobiles). Assuming perfect coverage, practically everyone CAN walk to a public library.
However, MY nearest public library is further than two miles away, and I live in a ~80,000 population town. So perfect coverage isn't.
If by "most people" you mean "people living within two miles of a public library", sure.
The United States had 9074 public libraries" as of 2001. It also has 3,537,441 square miles in total. Assuming no overlap in public libraries, (9074*3.14159*2^2) = 114027 square miles of "walkable" library coverage, or 3.2% of the total land area.
Only about 6% of the land of the United States is actually used for residence.
The absolute upper limit of "percentage of people living in the United States who can walk to a public library" is thus 3.2 / 5.5 = 58% .
Zope is beautiful, from what little I have seen lisp is beautiful. Alas at this point I am convinced that they are just art.
I won't speak for Zope, but my experience with Lisp is that it is most of the way through a painful transition phase. Prior to the standardization of CommonLisp, the OSS and commercial implementations had diverged quite a bit, each providing their own way for network, SQL, etc. Nowadays, there are lots of libraries out there for these things that are getting ported between all the implementations, AND critical features of other languages are finding their way back into Lisp via these libraries.
Right now if you wanted to you could write a Lisp program that used TCP/IP (+ FTP/SMTP/HTTP/etc.), threads, SQL, regexps, windowing, XML, and crypto, AND deploy this as a webapp in either a standalone Lisp server or behind an Apache server. However, the libraries are still separate pieces that you have to download and incorporate, and the documentation is not yet at the point that with a single book you can be guided through all this (unlike Java ,.Net, and Python where almost any 400-page tome would cover it all in some respect). But it's getting there.
I am seriously looking at Java/Swing as the next wave of what started as DOS/Turbo Pascal and got reimplemented in Windows/Delphi.
If you are looking for the next One Great Language (as I was last year) I'd strongly urge you to look beyond Java for a few practical reasons:
1) Sun and IBM may be gung-ho on Java, but it's losing ground compared to Python, Ruby, C#/Mono, etc. (Check this out too: http://oodt.jpl.nasa.gov/better-web-app.mov.) As a former J2EE developer, let me also state that Sun is very slow with fixing critical bugs, and many more of those bugs appear on typical desktop applications than the server.
2) As a language, Java is "OK" but not all that great, and it doesn't look like it's going to get much better over the next decade. "Better" in this case means how quickly you can write good abstractions.
3) Its lack of a Java-certified yet free-as-in-speech runtime stack is a problem. I wouldn't commit any of my future livelihood to the sufferance of any vendor, Sun or otherwise.
4) Java doesn't integrate that well with non-Java code. JNI is a pain to use (I've done it), the APIs that do talk to the OS are lowest-common-denominator and hence usually incomplete for any serious work, forcing you into JNI. If you're going to use a platform that insists on a clear separation between its runtime and the underlying OS, you may as well go with Lisp and at least get multiple free implementations and serious language abstraction.
Anyway, I'm not trying to preach here, Java's got a great place and powers a lot of the world. It's just (to me) not a good choice for the One Great Language, he one that you switch your primary problem-solving-think into. It would be like deliberately choosing to use Cobol in 1988 when Turbo Pascal was already available.
Not really. In your example, all the code is still GPL-compatible (you said Bob's code is BSD, and it's OK to put BSD-licensed code in a GPL binary), so the API isn't really necessary if you're just trying to avoid a license conflict.
The real-world example is kernel + BSD API + closed-source binary blob: this combination is perfectly legal for an end-user to create for themselves (or for their entire organization), but they cannot distribute it to new end-users without violating the GPL. Hence no Linux distribution can offer it.
Slashdot Mirror
Read the whole thread yourself:
1. GC forks as a rip of an X11 program, at that time it is an official GNU project.
a. All correspondance regarding personal finance packages will be forwarded to GC developers.
b. FSF includes a link to GC.
c. GC acknowledges itself as a GNU project and includes a link to FSF.
d. GC developers at that time opt not to use other technical services from FSF.
2. GC development continues via a private firm.
3. Firm goes under, but assigns copyright to FSF.
4. New generation of developers on GC forget about their relationship with FSF and create a web page that doesn't link back to FSF anymore.
5. RMS notices and asks them to fix it. FSF is still pointing to GC from its web site and forwarding messages.
6. Original developer chimes in and provides the history.
RMS is NOT trying to hijack this project. FSF has original copyright on 90% of the code -- it's their project. The current developers are actually working on a fork even if they don't realize it. If the GC developers try to distance themselves from the GNU Project, RMS will be completely correct in trying to find a new maintainer for their branch and on insisting that their branch remains the original trunk.
Example 1: GNU Emacs vs XEmacs. Even though XEmacs is out there, FSF needs someone to maintain the Emacs that is part of the GNU Project.
Example 2: GCC vs EGCS. GCC development stagnated, EGCS became the new GCC and the new GCC is the official GNU Project C compiler. Forks can return.
Given the history that RMS knew, and the fact that that history was backed up by the original developer, the question on the thread of whether or not GC is GNU Project does indeed become "Do the current developers on GC want to work on a non-GNU fork?"
When BitKeeper tried to pull similar shenanigans, Linus dropped BitKeeper like a stone, and wrote his own source code management system, called "git."
Note that BitKeeper's eventual "shenanigans" were predicted by RMS when everyone else called him paranoid for thinking a for-profit entity might someday change its mind.
No, it was a real and concrete question.
Is a company acting in bad faith if it ships its embedded GPLv3 product with just exactly enough hard disk space to run the software it ships with, but no more? Or if the software is burned into EEPROM and unupgradable?
It's a question that you can't answer. Neither can Linus. And that's why we're worried.
Actually, it's a question that is easy to answer: if a company has a product with GPLv3 code, and that code is physically user upgradable (e.g. hard disk, flash), then the company needs to comply with those provisions of GPLv3 that apply in this case: users should be able to replace the GPLv3 parts with their own versions. So Tivo would NOT be in compliance with GPLv3-licensed software due to the DRM keys.
If a device is NOT user upgradable, then complying with GPLv3 just means contributing back the source. RMS has stated similar views regarding ROM-based applications: if the user can't upgrade the device, then GPL compliance means source code availability and no more. By example, it would be very unreasonable to expect a Linux-based MP3 player to ship with everything required in the player to replace all the software (such as a large hard drive, video/keyboard support, etc.).
In your contrived example, if a company goes to extraordinary lengths to prevent upgrades of ANY kind, then it's just like running GPLv3 code in ROM: that's ok. If they use measures specifically to prevent users from upgrading but allowing the company itself to, then that's NOT OK as per the draft of GPLv3. Limiting hard drive space is only one way to do that, they could also sign the software ala DRM, modify the kernel to use a special procedure such as allowing writes only to specific disk blocks or using an undocumented ioctl, or resort to a hardware dongle. In all the cases it's just this: if there is a software upgrade path available for the hardware manufacturer, then the user must be able to use it too for GPLv3 software. If the manufacturer doesn't like that, they are perfectly free to use any of the multitude of software available under other terms.
You can see this clearly in the way he tries to name projects after himself, and in the way he tries to micromanage projects that he has really very little involvement with!
I followed your link to the discussion regarding GnuCash. RMS sent an email a) congratulating them on a new release, and b) asking them to clarify their web page in a very minor way to reflect the history in a way that the original author (Linas Vepstas) agrees is correct. As this message points out, GnuCash did in fact start out as an official GNU project and a significant churck of code (about 90%+) is currently copyrighted FSF. It also spurred a discussion that resulted in a clarification within the GnuCash team about their relationship to FSF (which is generally neutral/positive) and Gnome (which could get better by a lot).
I don't see any sign of meglomania there.
Jumping in...
So why didn't they just announce that it isn't possible and stop there? Why go further with the value statements about GPLv3? This would certainly have sufficed if their purpose was just to discuss v3 as it relates to the kernel:
I read the thread at http://lwn.net/Articles/200422/ and I have to agree that it sounds fishy that they went to all this trouble. So they are critical developers, well experienced, etc., but if they are so cool with Tivo DRM (because Tivo does return source code), why do they care if the GNU toolchain goes GPLv3? Someone else on the thread mentioned that embedded consumer devices will likely work from a GPLv2-only fork of the toolchain as if that's a bad thing. If all they care about is the fact Tivo et al return code to the kernel, why should they care if Tivo et al deliberately choose to use an obsolete glibc?
Their fundamental argument seems to be: "We're engineers and we're happy that this high-quality product is both available for end users " (me: who they still seem to think means device manufacturers rather than consumers) " and for us to play with, and so long as the source is available to us under the same terms we made it available to everyone else we are happy."
Yet they are saying in the thread: "Third parties will restrict all users freedom; that is a given. They will select software that enables their business objectives. ... What is going to be the impact of adopting GPLv3? You wont have anyone using your software."
Is this really their beef with GPLv3? If so, it sounds like they're more in it for the notoriety ("my code runs all over!") than any kind of technical achievement.
I'm not dissing their technical merits, but I have to agree with other threads here that their statement about GPLv3 is not well supported factually, seems to (deliberately) misunderstand GPLv3 (especially the DRM and patent clauses), and serves only to provide cover for embedded device manufacturers over the concerns of both distros and end users. It feels very much like a group of people who are defending their lucrative industry niche at the expense of the very factors that helped create that niche in the first place.
About half a year ago, I tried to get into Lisp. It sounds like the holy grail - execution speed and error checking of a compiled language with all the speed of development of more dynamic languages. Perhaps s-expressions should be perfectly suited for HTML too (I'm still stuck in this web app world, at the moment). So I picked up Practical Common Lisp, installed SBCL, joined some mailing lists, found some libraries, got experimenting...
.asd file and add a defpackage to either a separate .lisp file or your main one, and the .asd specification is not documented well (the wiki page for setting up sub-modules is flat-out wrong).
... UGH. I've already had to write my own version of a java.io.File just to have a string that is guaranteed to refer to an actual file.
.lisp file and run it. The implementations should also make it easier to tune the output of the Lisp (try to get compile-warning's squished in SBCL, it's not pretty).
...)
Two things meant I got disinterested in a month or so: it has far too many slightly-differently-named functions in the standard language, many with non-obvious names too (that's what PHP gets its harshest criticism for); and also the huge library of things you need nowadays (internet stuff, databases, OS stuff, etc) is either missing or rather undeveloped.
All very true criticisms. I too have switched my new code to Lisp for the purpose of being a better programmer (and because I've got two years in a MS program to get my basic math toolset switched over). It IS getting better, and faster at that. I think we're approaching critical mass of people adopting it and pushing it into the Python/Java/Perl/etc. space with sockets, threads, SQL, UFFI (now CFFI), etc.
I think the biggest problems I've got with Lisp are packaging, pathnames, and the REPL.
Packaging means ASDF, which I don't like at all compared to Java or Perl's filesystem packages. To get a package with dependencies to work OK, you've got to create a
Pathnames
REPL. Well, it's very nice to be able to talk to a running Lisp, especially when the Lisp is an application server and you want to alter some values or force a reload of an app, or just to poke around and see what kind of stats have been collected. However, the distinction made in the spec between compile-time, interpret-time, and run-time for code makes some things difficult, e.g. defconstant is completely useless with SBCL. I like REPL, every book should mention it, but they should very quickly move OFF REPL and show people how to just load a
I would LOVE (and gladly buy two) copies of a book that had this information in it:
1. What is Lisp, and where to find the community web sites
2. How to locate, download, and install all the major Lisps on Linux, Mac, and Windows
3. Basic language grammar, including CLOS
4. How to use ASDF (including complex examples)
5. How to fully interface with the operating system, including implementation-specific functions for file i/o, network i/o, command-line arguments, the environment, threads, and more
6. How to package a standalone Lisp application to deliver to customers
7. How to use UFFI
8. How to set up a Lisp web application server (modlisp or Araneida or
9. How to use the most common libraries: CLSQL, OpenGL, SDL
I know Lisp'ers love (and I do too) the fact we've got a spec and multiple implementations, but dangit if it isn't really difficult to get it all together and be able to actually DO something with it within a couple weeks.
Imagine for a second if Jerry Falwell and Oral Roberts teamed up and decided to turn their army of Christian fundamentalist drones into a revolutionary army (even if a peaceful one) against the U.S. government. You think the U.S. government would just let them?
You think they haven't done it? Go look at the Republican Party agenda sometime.
The only thing that'll make them reconsider is a mass exodus away to a competitor and to be frank, I don't see that happening.
They lost me, and I barely used it. Every heavy Facebook user I know has joined an anti-feed group. I think they could easily lose over 5%, maybe even up to 15-20%, of all existing users, and with the news "features" they could slow down adoption of new users too.
This reminds me of the uproar when dejanews first appeared on the scene. All these people who had made public posts to usenet under a mistaken belief that what they said would never go beyond the little "community" of that group were very unhappy to see all of there messages in a searchable database.
That's an exceedingly analogous situation, and that's exactly what I thought too. When dejanews showed up, I thought it was lame and no one would use their www version when compared to the power of the full-blown client newsreaders; then a few years ago I saw the search facilities in Google Groups and saw my entire posting history going back to when I was *16*. By now every one of those posts is so old no one will care (plus I never learned Elvish or wrote posts on sex), but I got the point: I now use Usenet only very sparingly and only in a very professional manner on the assumption that any employer may see it years down the road. I also cut back a lot on Slashdot when I saw how many sites out there blatantly rip threads and get them into the search engines.
I didn't use Facebook much, but I liked the fact that people in my classes could at least see who I was, note that I was happily married, and maybe notice a blurb about a great job opportunity with a cool group I had worked with recently. But now my Facebook account is deactivated and will stay that way even if they turn off (or allow users to tune) the "news feed" and "mini-feed" functions.
More than anything, the Facebook team has shown me that they are both capable and willing to implement a historical profile auditing function which spits in the face of social norms. We do not post lists on people's doors that include the contents of their grocery carts over the last six months, and we do not email photographs of every post-it note that appears on a whiteboard to a list of fifty people. Online, we expect personal profiles to be current only, to be "live", not to track their own changes and provide search features on deleted information, even if third parties such as the Wayback Machine and Google Cache might sometimes be able to do it.
(well, having not looked at it...)
Precisely. You haven't seen it, you've got no idea what it feels like. I'll spell it out for you.
You log in, and on your homepage is a list of items that have changed on all the people on your friends list, including things like this:
so-and-so has joined group "There is a difference between retro and Euro-trash, and I crossed it!".
so-and-so has removed "books by Carl Sagan" from their interests list.
so-and-so is now sleeping.
so-and-so is now friends with so-and-so.
so-and-so has dropped ECON 101 from their classes list.
so-and-so has added pictures to their "Trip to Cancun" photo album.
This is on your homepage. To continue with your analogy, it's like going to google.com and seeing a list posted below the search bar that includes people in your street, from your hometown, and at your job, with each list item being a DUI, divorce, job promotion, new child, death in the family, and contents of their last trip to the grocery store. All updated within seconds. You CANNOT go to google.com and turn this list off either, and your browser is set with google.com as its startup page and you cannot change that. Your Facebook home page and the "news feed" are the gateway you must go through in order to use the site at all.
Each message looks quite innocuous, but taken together it becomes very creepy. I only had about 20 people on my friends list, mostly from a college-age church group who use Facebook all the time to organize events, but since they were used to Facebook and edited their profile routinely I immediately had dozens of events in the "News Feed" and suddenly I was seeing way more than I ever wanted to see. It wasn't MY public information turning into public announcements, it was theirs, but I felt slimy seeing it all in one place and immediately knowing so much more than they had intended to present. For instance, each event is timestamped, so you know exactly when your friends are online and not. And by seeing the sequence for any given individual, you can infer pretty quickly if they are feeling up or down too at that time.
To analogize, imagine if you were walking into a small singles group event (bowling, dinner, movie, etc.) and you had spent some time out in public before you got there: here is where you bought the shirt, over there you had lunch, yesterday you rented the musical Rent, last week you were seen leaving a party that was later busted by the police. Now you walk in to that singles group and there is a floating sign above your head with all of these things printed clearly for everyone to see. Instead of someone saying "Hi my name is so-and-so, who are you?" you get "Man, you like Rent? You're so lame!" You lose outright the ability to control your own presentation, what we used to call in the old days being appropriate. This feature (the floating thing right over your head) is the "mini-feed", which also can't be fully turned off. You can hide specific events but you have to do that every single time you make a change.
Everyone likes to say, "But it's the Internet, and it's public! Stop crying about privacy!" Yes but. The outside of your house is public too, but would you be cool with someone videotaping everyone coming and going through your doors? How about an inventory of your pantry and refrigerator posted on the street next to your mailbox? The point isn't that this information shouldn't be public, it's that automatically combining it in the right context tells people far more than you ever intended. As civilized people we routinely "forget" things that we see around us all the time (such as the contents of someone's grocery cart) precisely to respect polite boundaries. We know it's just a polite fiction, yet it's one we all do.
Insisting that "it's all different on the Internet" particularly in regards to social sites is silly.
The problem lies in that no one has the stomach for really turning them loose to do just that, and thanks to the speed of modern news networks, no one can get away with Dresdens or Hiroshimas anymore.
That's not a problem, that's a feature. "Turning them loose" to deal with Iraq would lead directly to the elimination of practically all life on Earth once the first nuclear weapon was used. I'd rather have us "lose" than throw 4.5 billion years of evolution down the drain.
Something seems flawed about a view of economics in which the "rich" are automatically bad and do not deserve money, while the "middle" are expected to do nothing but aquire enough money to become rich.
Conversely, something is wrong with a view of economics that says fundamental human nature changes as one gets wealthier. In Reagonomics, rich people respond only to positive economic incentives (lower taxes) while poor people respond only to negative economic incentives (reduced economic safety net).
I think your statement the "rich" are automatically bad [yet] the middle do nothing but acquire enough money to become rich can also be stated as: "everyone wants to be lazy, but too much laziness is bad."
Can it be observed? Can you repeat it and document the results of the repetition?
Seriously. It's not testable. If it's not testable, it's not science.
No. The Big Bang itself may not be testable, but any theory that requires a Big Bang must also account for how a handful of critical constants in the universe come about. Since those constants ARE testable, and have been tested to death already, any theory that posits the Big Bang is directly testable too.
Next you're going to say that pi or any other irrational number can't be used in mathematics because they require an infinite number of digits to write out.
My view is that God created the universe from nothing. Perhaps you don't find that believeable.
Which God? How did God do it? How can you test your idea of how God did it?
I find the idea that it all came from nothing by natural processes to be ridiculous. If matter is "all there is, all there ever was, and all that ever will be" then the universe should have equilibrated an eternity ago. All heat and motion and should have stopped virtually an infinite amount of time before you and I existed.
Given that there are plenty of energy/density gradients still in the universe, your idea of what is ridiculous is already irrelevant. We ARE here, and the universe is far from equilibrium, and the concept of thermodynamic equilibrium doesn't even apply at cosmic scales where gravity dominates.
Frankly origins is not science and has no place in science textbooks because it's all speculation.
There is a branch of science called cosmology whose purpose is to study origins using what is known of the present and what can be measured from the past. Since we can see photons that were generated over fifteen billion years ago, and we can directly measure radioactive decay, and we are approaching a more consistent theory to explain how matter and forces are related, I see plenty of material available for scientific study of the origins of everything.
I don't have answers for everything, but here are a few:
1) DVDs. I use Debian, just installed testing to my laptop and DVDs work OK out of the box using Kaffeine. Actually, I like Kaffeine a lot better than WMP for DVD playback: not only does it work with a simple and uncluttered interface, it has a simple dialog (hit 'v') that can be used to adjust hue, color, and audio/video sync. The downside is that on my laptop I had to manually adjust the sync to make it right, but I'm not sure if that is something Kaffeine can be made to do on its own (like mplayer) or not.
2) Cameras, MP3 players: my rule is simple. If it is USB and advertised to work on Mac OS X, it will work on Linux. I don't know if that is true for iPods (to me iPods are too expensive), but it's been a good rule of thumb for the devices I've bought (a Canon camera, several MP3 players).
3) Wireless IS a conundrum, I agree. I do think the manufacturers are at fault, but the ultimate problem lies with the FCC's rule banning wireless receivers from certain frequencies. Since it is impractical to make the hardware enforce the law, the checks are made in software and the manufacturers refuse to write their drivers for non-Windows OS. That said, I have had success by looking up the cards ahead of time and picking one that is known to work with Linux.
It would be naive to think that all things being equal, a student from such an educational background is more fit for an intellectual environment. But I guess you don't believe in the concept of evolutionary fitness.
You were doing fine until you leaped into Social Darwinism there. "Evolutionary fitness" vs an intellectual environment? If anything, being a good social fit for an intellectual environment is an evolutionary handicap, as the #1 factor against having children is education level: the higher the degree the less likely one will have children.
So you're ditching Linux because of the proposal that supporting binary/proprietry software is OK - yet you're going to BSD (which can use binary windows drivers in the kernel) or Open Solaris (controlled by Sun) or GNU/Hurd (which for all intents and purposes may as well not exist)?
:) ).
I think the GP is (might be?) ditching the Linux kernel because there is growing evidence that a movement exists within the "Linux community" (whatever that is) that is actively trying to compromise ultimate user freedom in order to gain short-term acceptance in the mainstream in a fashion similar to Windows and OS X. Symptoms include encouraging users to use binary drivers rather than choose hardware with open-source drivers, implementing technologies to play locked content rather than insist on open media formats, and encouraging hardware vendors to use Free Software in their DRM-locked systems rather than insist they use proprietary or public-domain software.
I too believe that such a movement exists and is gaining ground due to simple fact that it is a software-maker-business friendly position and the megacorps have the money to encourage this view. We'll find out in the next couple years who is going to win -- the short-term pragmatists vs the long-term realists -- when the new LGPL comes out and all the FSF projects move over.
As for the OP's options: GNU Hurd is generally stagnant but could move forward quickly now; OpenSolars is dead in the water; NetBSD could be forked into a GPLv3 version (perhaps called "GPL/BSD"?
Linux is rapidly being locked out of the mainstream by stupid moves like GPLv3,
GPLv3 is not a stupid move. Face it, there are (at least) three distinct classes of computer users whose interests are now in full conflict due to DRM: consumers, software developers, and content sellers. GPLv3 brings this conflict out into the open and provides some practical leverage for software developers against content creators, sorely needed in these days where the content creators have so much more money to purchase favorable legislation.
Fortunately Linux is not likely to go to GPLv3,
It will be greatly affected by GPLv3 once glibc moves to a GPLv3-like license (still LGPL, but users must be able to replace it). Given: the Linux kernel only works with the FSF toolchain (gcc, glibc), and once glibc can be replaced with a user version that doesn't bother checking signatures on new binaries, the whole TCPA/DRM lockdown comes apart. There goes the Tivo business model.
Linux kernel developers will find themselves thrown into this conflict. Do they *really* want Tivo, or maybe nVidia/ATI, to be able to use the code they wrote to dictate policy on users? If so, they'll need to either fork the entire FSF toolchain (hard) or move to BSD libc (maybe easier). Ironically enough, Linux now needs the FSF more than the other way around.
OTOH, maybe enough critical Linux kernel developers will take the FSF side and fork the kernel to stay compatible with newer versions of glibc. What then? What if something really important (like the SCSI support layer) threatened to fork into GPLv2 and GPLv3+, with many of the knowledgable developers picking only one to work on? Would Linus push for unified kernel development even if he was "forced" to stay compatible with glibc?
Or maybe the glibc developers will split in their camp, creating one version for the Linux kernel and another for everything else; they have just as much reason to pick Tivo's side as Linus does. It could domino against the FSF with a number of major FSF components forking into GPLv2 and ignoring the "GPLv3 or later" version; or it could domino against the Tivo-minded developers with a major Linux distro expicitly forking all "GPLv2 or later" applications into "GPLv3 or later", forcing their users into DRM+freedom. All it takes is two extra words in the project-wide COPYING file and your code becomes a political football for someone else to play with.
Personally, I'm glad GPLv3 is pushing this out into the open. These issues will determine the fate of the 21st Century "information economy"; if developers and consumers don't get a voice we will definitely be screwed.
Even the Microsoft CLI is more friendly than Unix, what with the "help" command.
...
~$ help
GNU bash, version 2.05b.0(1)-release (i386-pc-linux-gnu)
These shell commands are defined internally. Type `help' to see this list.
Type `help name' to find out more about the function `name'.
Use `info bash' to find out more about the shell in general.
Use `man -k' or `info' to find out more about commands not in this list.
A star (*) next to a name means that the command is disabled.
The Linux desktop has become quite usable - but it got there by copying Microsoft, and that is no shit...KDE and Gnome are both pretty hardcore ripoffs of Windows, although GNOME also manages to copy MacOS at the same time... Unfortunately, [Unix] only got there by copying Windows, which kind of blows the whole usability argument to kingdom come.
I disagree. Windows never had selection buffer, virtual desktops, or remote desktop, items I absolutely require to be reasonably productive on X. KDE/GNOME brought us unified widget sets and control panels, and both were certainly inspired by both Windows and MacOS, but they go so far beyond Windows in overall functionality it's not even funny.
I don't see why computers should be any different. Yes I want disclosure about security problems, espically if teh company is slow in getting a patch out. However disclose the problem, what it relates to, what the potential attack vectors, and what if anythign can be done to fix it. Don't go and post code that not only shows people how the exploit works but allows them to just compile and do it. Do that and in all likelyhood my system will be 0wned before I ever read the notice and try to do anything about it.
In an ideal world, a security researcher will discover a fix and do the following:
1) Create code that reliably exercises the flaw that can be used to verify that the problem really exists and that the fix (when it is finished by the vendor/OSS group) works. You can call this the "exploit code" if you want; it is necessary for someone to create it so that the fix in step 3 below can be tested.
2) Notify the vendor/group of the hole and pass along the exploit code.
3) The vendor/group evaluates the problem, assigns a reasonable fix schedule to it, and eventually a fix is produced, verified to work against the exploit code, and distributed to the world.
4) The hole is then announced on a security bulletin *along with the exploit code* to notify customers/users that might not have updated already that they should do so at their earliest convenience, and to provide customers/users (many of whom are knowledgable programmers) the same tool given to the vendors to verify that the hole is plugged in their systems.
This is a reasonable system. The whitehats try to do it all the time, and for many OSS projects it works out just this way. Blackhats OTOH do only #1 and then distribute the exploit code only to other blackhats, so that when they use a flaw both vendors and customers/users are taken unawares.
Unfortunately, many closed-source vendors break the whitehat process between steps #2 and #3. They are given notification and exploit code, but rather than prioritize a fix they decide that no fix is necessary, because their local astrologer told them that only whitehats find flaws. After enough time with no action, the whitehats MUST move on to #4 so that users can isolate the systems with the hole in order to preserve the rest of their network.
In your house analogy, this is equivalent to notifying a neighborhood that the developer who built many of their houses made a serious mistake in the wiring such that any house at any time might burn to the ground, and that their insurance will not cover it, and the developer has decided not to pay for a fix, and the local fire department has announced that they will not intervene to stop any fires that start due to a wiring fault.
A device is available that can quickly determine which houses are at risk. The developer is spending twice as much money needed to fix the wiring on ads in the local newspaper exhorting those citizens who have these "bad house detector" devices to destroy them rather than share them with their neighbors so that they can hire their own electricians.
The process YOU want is already being followed by the majority of legitimate whitehats. The process McAfee wants leaves everyone screwed.
Everytime Slashdot mentions Linux, you bring up wyoGuide as though it's some magic bullet that would fix everything if only every Linux user started adhering to it. I've decided to respond this time instead of move on.
/usr/bin, application data (including app-specific libraries) in /usr/lib/appname, documentation in /usr/share/doc/appname, and top-level configuration file in /etc/appname(.conf) . Desktop Windows applications ported to Linux should use this standard, not some dump-it-all-in-one-place-any-structure-you-want Windows-style solution (which you call "the easiest solution").
Here are the problems I've got with wyoGuide:
1) It assumes that developers should make new Linux applications that look and behave like established Windows applications circa 1997. Even Windows applications don't do this anymore, and users seem more than happy to use applications with skinnable eye candy rather than Office 97 menus.
2) The example language is C++, and the example toolkit is wxWindows. There are plenty of other cross-platform GUI toolkits, and other languages include cross-platform GUI as a core feature. You'll get more traction if you include more languages (Java would be a good choice, as many CS students are taught that now) and other toolkits.
3) The screenshots are all Windows. Sorry, I've got NO applications on my Linux desktop that look like that. Include some OS X and Linux screenshots and maybe people from the non-Windows side will begin listening.
4) As with #3, your tone in the document and in your Slashdot posts seems to put most of the blame on Linux developers for not making their applications resemble Windows, and then you go on inside the document and make wrong statements about non-Windows platforms:
a) Section 10.1: Linux already has a defacto standard for application paths: binary/symlink in
b) Section 6.1: preferences dialog. Many Mac applications do not have "Apply" or "OK" buttons, they simply apply immediately and you close the window to get out.
c) Section 3.7: On Linux, the Ctrl key is Ctrl, the Alt key is often called "Meta" but modern desktops often just leave it as Alt. Any Linux app that used Alt-C/X/V instead of Ctrl-C/X/V would be broken.
5) More of the "at all costs, make it resemble Windows" criteria in Section 3: "The standard entries in the file menu have their defined command keys as shown in the sample, if they have any. These keys are reserved and may not used elsewhere, not even if the corresponding menu entry is missing." I see that menu and think Office 97 (except that the editing filenames should be below Quit). Some applications might want those keys for other things, and some users might want to remap those functions to other keys.
6) What about keyboard accelerators, ala Alt-F -> File menu dropdown? If you're going to mandate/suggest the keyboard shortcuts, you may as well include the accelerators too.
7) You mention the Windows registry barely in passing in Section 6.3. It needs more than that: Windows applications must use the registry _correctly_ such that non-admin users can use their application.
8) You added a section for coding style? Now I'm beginning to think that you might not actually write a lot of code.
In short, when I read wyoGuide, I see a document telling me how to use one language with one toolkit to make an inconsistent Windows-like application with some "helpful" newb tips at the end.
Let me offer some suggestions:
1) Move the code snippets out to separate links. We're talking HCI design, not "low-level" implementation. Coders can always click the links to see source code snippets. And an HTML page with annotated source that links BACK to the wyoGuide would be nice.
2) Focus on successful applications that have already proven themselves cross-platform, such as Mozilla, Abiword, Gaim, LyX, etc. Show screenshots
We use StarOffice for most of the PCs here because Texas' stupid "Robin Hood" law strips us of about $22,000,000 a year, forcing across-the-board budget cuts.
As a Texan myself, I say yippee. Do you really expect that if Robin Hood disappeared the multiple school districts benefitting from your $22 mil would be able to purchase Microsoft Office for _their_ students? Of course not. The whole point of Robin Hood is to force all Texas schools to suffer the consequences of extreme inequity. Poor districts can't afford things like adequate numbers of teachers and buses, hence your school can't afford software licenses for elective computer classes.
Tell your PTA that if they really want MS Office they are welcome to individually donate licenses (at $300 each) or cut funds from more expensive extracurricular activities like football. (Maybe _your_ local community will prize computer software over football, mine sure didn't.) Or they could vote in a state corporate (or personal) income tax to shift the funding burden away from property taxes.
Doh, made a mistake. Actually there are 16,298 total physical library outlets (including branches but excluding bookmobiles). Assuming perfect coverage, practically everyone CAN walk to a public library.
However, MY nearest public library is further than two miles away, and I live in a ~80,000 population town. So perfect coverage isn't.
Most people live within walking distance of one,
If by "most people" you mean "people living within two miles of a public library", sure.
The United States had 9074 public libraries" as of 2001. It also has 3,537,441 square miles in total. Assuming no overlap in public libraries, (9074*3.14159*2^2) = 114027 square miles of "walkable" library coverage, or 3.2% of the total land area.
Only about 6% of the land of the United States is actually used for residence.
The absolute upper limit of "percentage of people living in the United States who can walk to a public library" is thus 3.2 / 5.5 = 58% .
Zope is beautiful, from what little I have seen lisp is beautiful. Alas at this point I am convinced that they are just art.
.Net, and Python where almost any 400-page tome would cover it all in some respect). But it's getting there.
I won't speak for Zope, but my experience with Lisp is that it is most of the way through a painful transition phase. Prior to the standardization of CommonLisp, the OSS and commercial implementations had diverged quite a bit, each providing their own way for network, SQL, etc. Nowadays, there are lots of libraries out there for these things that are getting ported between all the implementations, AND critical features of other languages are finding their way back into Lisp via these libraries.
Right now if you wanted to you could write a Lisp program that used TCP/IP (+ FTP/SMTP/HTTP/etc.), threads, SQL, regexps, windowing, XML, and crypto, AND deploy this as a webapp in either a standalone Lisp server or behind an Apache server. However, the libraries are still separate pieces that you have to download and incorporate, and the documentation is not yet at the point that with a single book you can be guided through all this (unlike Java ,
I am seriously looking at Java/Swing as the next wave of what started as DOS/Turbo Pascal and got reimplemented in Windows/Delphi.
.) As a former J2EE developer, let me also state that Sun is very slow with fixing critical bugs, and many more of those bugs appear on typical desktop applications than the server.
If you are looking for the next One Great Language (as I was last year) I'd strongly urge you to look beyond Java for a few practical reasons:
1) Sun and IBM may be gung-ho on Java, but it's losing ground compared to Python, Ruby, C#/Mono, etc. (Check this out too: http://oodt.jpl.nasa.gov/better-web-app.mov
2) As a language, Java is "OK" but not all that great, and it doesn't look like it's going to get much better over the next decade. "Better" in this case means how quickly you can write good abstractions.
3) Its lack of a Java-certified yet free-as-in-speech runtime stack is a problem. I wouldn't commit any of my future livelihood to the sufferance of any vendor, Sun or otherwise.
4) Java doesn't integrate that well with non-Java code. JNI is a pain to use (I've done it), the APIs that do talk to the OS are lowest-common-denominator and hence usually incomplete for any serious work, forcing you into JNI. If you're going to use a platform that insists on a clear separation between its runtime and the underlying OS, you may as well go with Lisp and at least get multiple free implementations and serious language abstraction.
Anyway, I'm not trying to preach here, Java's got a great place and powers a lot of the world. It's just (to me) not a good choice for the One Great Language, he one that you switch your primary problem-solving-think into. It would be like deliberately choosing to use Cobol in 1988 when Turbo Pascal was already available.
Problem Solved.
Not really. In your example, all the code is still GPL-compatible (you said Bob's code is BSD, and it's OK to put BSD-licensed code in a GPL binary), so the API isn't really necessary if you're just trying to avoid a license conflict.
The real-world example is kernel + BSD API + closed-source binary blob: this combination is perfectly legal for an end-user to create for themselves (or for their entire organization), but they cannot distribute it to new end-users without violating the GPL. Hence no Linux distribution can offer it.