AFAIK, nobody at MIT has plans to migrate any important services to a Windows-based platform any time soon. Kerberized POP, krb5-authenticated print services, Kerberized Zephyr, AFS, an so forth will all continue to run on Unix-based machines.
This means that the issue is (mostly) irrelevant to Athena. Since every service is going to run on Unix, we don't care about Windows "extensions" to Kerberos; if Windows machines can access Unix services using a Unix-based Kerberos server, then everything Just Works (TM).
Personally, I think Pismere is just a lost cause. Even if Win2K is "a new standard of reliability", I suspect a test cluster of 10 Windows-based machines would have much more serious problems than the 10 beta Linux-Athena machines currently available for public use in W20-575. Just about everything we need is available now (and has been for several years) on Unix, and people with personal PCs have been able to install SIPB's Linux-Athena to get Athena on their desktop. With an official supported MIT I/S Linux-Athena coming soon, it's clear that MIT isn't planning on pushing Windows as their Intel-based OS of choice.
Keep in mind that nothing stops DoubleClick et al. from tracking you by, say, your IP address. There's nothing particularly sacred about your cookie; it's just "more unique" than other ways They have of identifying you. (Me, I refuse cookies from everywhere but Slashdot.:-)
I suspect there are a couple of factors at work here:
Most people who actually write code use stable, proven tools. I write most of my code in XEmacs, and also use vim a great deal. Other people rely on FSF Emacs, plain vi, jed, joe, and other editors that have been around "a while". At least in my corner of the world, people just don't use these newfangled programs like gedit.
For people to want to work on free software code, the code has to want to be worked on. Both the GNOME and Gtk code I've looked at has been pretty hostile: there are almost no comments at all in any of the code, and one has to dredge through miles of source to figure out what's broken and how.
For that matter, the underlying toolkits need to be documented a lot better. There continues to fail to be a complete, functional set of documentation for Gtk+ or for the GNOME libraries. This is really annoying for people trying to work on end-user applications.
Really, the GNOME people need to put more effort into making their source tree developer-friendly, and into writing useful documentation. Until then, I suspect free software developers who might otherwise be anxious to work on GNOME code will run screaming.
Upgrading from 2.0 to 2.2 should be much easier than from 1.2 to 2.anything, because you don't have to deal with the libc5->libc6 upgrade. Just running apt-get update; apt-get dist-upgrade should do most of the hard work for you.
This has been discussed to some extent on the Debian lists. Sure, you can wait for XFree86 4.0. And then you'll want to wait for kernel 2.4. And then you'll want to wait for GNOME 2.0, and this, and that, and the other thing. At some point you just need to sit down and say, "we're going to release with what we have", or else you'll never get a release out.
Or the Windows version of Word: 1.0, then 2.0, then 6.0 to sync up with the version number of DOS-Word, then 97 because year-based versioning schemes are cool or something. *sigh*
Re:XFree86 versioning??? Was:4.0 aka release sched
on
XFree86 3.3.6 released
·
· Score: 1
3.3.x is the current "stable" release. 4.0 will be the next stable release, when it's ready. 3.9.x are snapshots of the developing 4.0 source tree, and I'd guess wouldn't be usable by the average user.
I don't feel like most of Debian pays huge amounts of attention to licensing stuff. In particular, Debian isn't really picky about, say, having an entirely GPL'd distribution; the BSD and Artistic licenses are seen as equally "free" in Debian's eyes. As an end user, I don't actually pay attention to the licenses of most of the stuff installed on my system. It's Just There, and because it has the Debian "free" stamp of approval, I know I can use it and possibly hack on it without problems.
I'm curious what the difference between a "distribution" and an "Operating System" is. I see an "Operating System" as a kernel and maybe the Debian "base" section, the minimum amount of stuff you need to get something useful running. Is the issue here that the FreeBSD people maintain both kernel code and user-space code? If there are stable interfaces between the two, then that's pretty irrelevant.
Once upon a time, I started using this little operating system called Linux. I was working at a start-up where everybody had 1.2.13 kernels patched for ELF support. But everybody knew these kernels were rock solid. A year or two went by while work on 1.3.x progressed, and then 2.0.0 was released.
A flurry of 2.0.x kernels came out. Finally, 2.0.18, the "last" stable kernel was released. No, wait, there was 2.0.19. Then 2.0.29. And so on, up to 2.0.37. Which we think is stable.
Consider, for a moment, the system used by Gnus, the singing, dancing mail and news reader for Emacs. Gnus has alpha releases with names ("September", "Red", "Quassia", "Pterodactyl"). These aren't announced to the general public, though they are discussed on a mailing list. These are essentially analagous to the a.n.x Linux kernel releases, for odd n. Then there are beta releases, which have version numbers like a.n.x for even n. These are probably stable enough to use, but if you care a lot about your mail you'll wait. Finally, there is a single final release with a version number of the form a.n for odd n (5.3, 5.5, 5.7).
The problem with the Linux kernel development model is that it has lots of "alpha" and "beta" releases, but no "final" release. So there's really no way to tell if a particular even-numbered kernel release is "stable" or not, aside from by reputation. At some point there needs to be a "final" we've-done-all-the-testing-we-can-possibly-think-o f-and-fixed-every-single-bug-which-is-wh y-we're-working-on-the-next-version release.
Once upon a time, I had a job working for a small company located maybe 10 miles from my home in Silicon Valley. I didn't have a car, so most of the time I used some combination of walking, busses, and possibly the local light rail system. This took me an hour and a half. Each way. Every day. If it wasn't too hot, I could bike, which only took an hour. Or, if I was lucky, I could borrow a car -- and make the drive to work in only 15 minutes.
It's easy to say, "people would ride public transit if it worked". But the simple fact is that "modern" urban developments, like what is now San Jose, are incredibly hostile towards working transit systems. Consider:
Residents don't want busses going down residential streets, but major streets are far enough apart that it can be at least a 15-20 minute walk to the nearest bus stop.
San Jose can be reasonably neatly divided into two pieces along route 280. South of the freeway, the city is primarily residential, but all of the jobs are north of it. This means that, in a north-south transit system, everybody will get on at the south end and get off at the north end, meaning you need higher capacity than if people were continuously getting on and getting off.
People are already quite attached to their cars, and I'd suspect the automotive and petroleum industries have quite a bit more political clout than the nonexistent mass transit industry. So funding is more likely to go to big road projects than to big transit projects.
And without funding, public transit is stuck at the same level it is now: busses that run on extremely sparse routes every half hour at most, and sometimes just don't show up.
All of this means that public transit systems have to fight a hard uphill battle to keep the minimal level of service they have now. And this level of service isn't encouraging; when it takes six times as long to take the bus as it is to drive, anybody with a car will prefer to use it at almost any cost.
What, in particular is wrong with X? I use even some of its more obscure features on a regular basis. What I would like to see in kernel graphics support is KGI, with good device support, and then XGGI on the userspace side, but that probably won't happen until GGI is ready.
Well, no, not really. But it's different. Over Zephyr (to pick an IM system completely at random), you can have a conversation between individuals, or a discussion within a group. It's kind of like the difference between talking to someone on the phone (or having a conference call) and writing them a letter (or trying to resolve something via the opinion page of your local paper).
How much time and trouble are spent writing little messages back and forth that could actually be used in something productive?
Zephyr is also used pretty extensively at MIT. I don't claim to understand its architecture, and what documentation there is for it advertises itself as outdated. But it does offer some useful features, including:
The ability to send messages to other users (much like AIM, from what I remember back when I was an AOL user and had never had even a Unix shell account before)
"Classes" and "instances", which carry messages on some particular subject (e.g. "help", or any of a number of classes each belonging to a particular student group)
X and tty support in the default client, and a proliferation of other clients (at least at MIT)
Users can hide an unhide themselves, so other users can locate them or not, and set whether an announcement is sent when they log in
I have no idea how this compares to the feature set in AIM, ICQ, or IRC. I just know they're all out there, and AFAICT do more or less the same thing.
Your average home/corporate user won't do very well at all without bash, cp, ls, df, cat, rm, or any of the other GNU tools that live in/bin. And lots of the things that regularly appear in/usr/bin aren't "developer tools", either, but things an even slightly clueful user would expect to have. Even things like libc are GNU software these days. If you take out everything that's GNU software, your Linux system is entirely crippled.
(IMHO, Emacs is also a "standard" part of most Un*x systems, and apparently lots of people get lost if their system doesn't include make, gcc, and libc header files. So even those "developer tools" should probably be a standard part of Corel KDE/GNU/Debian Linux (TM).)
It's kind of too bad that the ZDNet article didn't say more about some of the cooler features of the Open Source bake sale:
Pies cost 95 cents, with a 3 cent mandatory upgrade, for a total of 98 cents.
Source for the pies (in Scheme) was freely available; when the booth was in Lobby 10, there were stacks of printed source code under each of the pies.
The pie source was GPL'd.
All proceeds went to the FSF.
Even more amusing was that, when I showed up to my 11:00 Urban Studies class with a slice of Open Source apple pie, the instructor even had something of a clue about Open Source and Linux. Cool.:-)
Actually, the intelligence I've heard is that it will be Building 32. Which is consistent; then you can walk through 33, 35, 37, 39, 38, 34, 36, 32, in that order. Apparently Building 20 is having its number retired.
You could add them to your user menu on the panel. Or, if you're running Debian and the packages have standard Debian menu entries, they should appear on the Debian menu in the panel.
FWIW, I'm not too fond of any of them myself. Of the five, I like #2 the best as well, genie bottle or otherwise. (The bottle at least seems to go decently with the spirally thing, even if it doesn't add any meaningful content.)
As a point, these Debian packages are still under serious development. They're in a separate staging area (a) to resolve version skew and (b) because the developers believe that things aren't stable/bug-free/well-packaged enough to put into the unstable distribution. As much as I'd like to have a working GNOME setup again, I'm waiting until the packages actually get released.
As somebody who tries to be helpful on the comp.os.linux.* newsgroups, I've got to say there's a lot of general newbie clue failure out there. Questions like "how do I find out how much free disk space I have" get asked over and over and over again, more frequently than not cross-posted to several newsgroups. People don't understand how to use the resources available to them: FAQs and HOWTOs go unread, DejaNews unchecked, and even the past 24 hours' worth of newsgroup posts that contain a nearly identical question and a more than functional answer are completely ignored.
Well, I'm part of an MIT student group that projects 35mm films every weekend. We get films in between "real theaters" and when they come out on video. For a second-run theater like us, $20,000 can be a lot. If new films are produced only in digital, it'll essentially kill the second-run theaters, leaving your choices an increasingly expensive show in a first-run theater or renting the video (also getting more expensive and of poorer quality).
I'd be really hesitant to label the Debian GNOME maintainers as "poor bastards". The simple fact is that there are lots of little pieces related to Gtk+ and GNOME and such, and the maintainers are putting a lot of work into making sure it all works together. So we have a working GNOME that is part of Debian, and not just some random RPMs that the GNOME people put out that may or may not work with other RPMs.
Twin was originally designed as a tool to source-port Windows applications to Other OSes (like Linux and the Mac). Working binary emulation I think is more of a secondary goal, but there is an x86 emulator in the Twin sources. Wine, if I understand correctly, is only a binary emulator, and only runs on machines that can natively run x86 machine code.
The problem seems to be not so much that the different development versions of Gtk+ weren't compatible with each other (the incompatibilities were well-known as far as I could tell) but that developers of other packages insisted on releasing software that depended on libraries known to be in development. Debian seems to have dealt well with the Gtk+-1.1 incompatibilities, but at the cost of having close to a dozen different versions of the same library in the unstable tree.
Now that Gtk+-1.2 is out, hopefully everybody will fix those last little incompatibilities, and we can be back to having one active version of the library. *sigh*
Slashdot Mirror
This means that the issue is (mostly) irrelevant to Athena. Since every service is going to run on Unix, we don't care about Windows "extensions" to Kerberos; if Windows machines can access Unix services using a Unix-based Kerberos server, then everything Just Works (TM).
Personally, I think Pismere is just a lost cause. Even if Win2K is "a new standard of reliability", I suspect a test cluster of 10 Windows-based machines would have much more serious problems than the 10 beta Linux-Athena machines currently available for public use in W20-575. Just about everything we need is available now (and has been for several years) on Unix, and people with personal PCs have been able to install SIPB's Linux-Athena to get Athena on their desktop. With an official supported MIT I/S Linux-Athena coming soon, it's clear that MIT isn't planning on pushing Windows as their Intel-based OS of choice.
Keep in mind that nothing stops DoubleClick et al. from tracking you by, say, your IP address. There's nothing particularly sacred about your cookie; it's just "more unique" than other ways They have of identifying you. (Me, I refuse cookies from everywhere but Slashdot. :-)
- Most people who actually write code use stable, proven tools. I write most of my code in XEmacs, and also use vim a great deal. Other people rely on FSF Emacs, plain vi, jed, joe, and other editors that have been around "a while". At least in my corner of the world, people just don't use these newfangled programs like gedit.
- For people to want to work on free software code, the code has to want to be worked on. Both the GNOME and Gtk code I've looked at has been pretty hostile: there are almost no comments at all in any of the code, and one has to dredge through miles of source to figure out what's broken and how.
- For that matter, the underlying toolkits need to be documented a lot better. There continues to fail to be a complete, functional set of documentation for Gtk+ or for the GNOME libraries. This is really annoying for people trying to work on end-user applications.
Really, the GNOME people need to put more effort into making their source tree developer-friendly, and into writing useful documentation. Until then, I suspect free software developers who might otherwise be anxious to work on GNOME code will run screaming.Upgrading from 2.0 to 2.2 should be much easier than from 1.2 to 2.anything, because you don't have to deal with the libc5->libc6 upgrade. Just running apt-get update; apt-get dist-upgrade should do most of the hard work for you.
This has been discussed to some extent on the Debian lists. Sure, you can wait for XFree86 4.0. And then you'll want to wait for kernel 2.4. And then you'll want to wait for GNOME 2.0, and this, and that, and the other thing. At some point you just need to sit down and say, "we're going to release with what we have", or else you'll never get a release out.
Or the Windows version of Word: 1.0, then 2.0, then 6.0 to sync up with the version number of DOS-Word, then 97 because year-based versioning schemes are cool or something. *sigh*
3.3.x is the current "stable" release. 4.0 will be the next stable release, when it's ready. 3.9.x are snapshots of the developing 4.0 source tree, and I'd guess wouldn't be usable by the average user.
I'm curious what the difference between a "distribution" and an "Operating System" is. I see an "Operating System" as a kernel and maybe the Debian "base" section, the minimum amount of stuff you need to get something useful running. Is the issue here that the FreeBSD people maintain both kernel code and user-space code? If there are stable interfaces between the two, then that's pretty irrelevant.
A flurry of 2.0.x kernels came out. Finally, 2.0.18, the "last" stable kernel was released. No, wait, there was 2.0.19. Then 2.0.29. And so on, up to 2.0.37. Which we think is stable.
Consider, for a moment, the system used by Gnus, the singing, dancing mail and news reader for Emacs. Gnus has alpha releases with names ("September", "Red", "Quassia", "Pterodactyl"). These aren't announced to the general public, though they are discussed on a mailing list. These are essentially analagous to the a.n.x Linux kernel releases, for odd n. Then there are beta releases, which have version numbers like a.n.x for even n. These are probably stable enough to use, but if you care a lot about your mail you'll wait. Finally, there is a single final release with a version number of the form a.n for odd n (5.3, 5.5, 5.7).
The problem with the Linux kernel development model is that it has lots of "alpha" and "beta" releases, but no "final" release. So there's really no way to tell if a particular even-numbered kernel release is "stable" or not, aside from by reputation. At some point there needs to be a "final" we've-done-all-the-testing-we-can-possibly-think-o f-and-fixed-every-single-bug-which-is-wh y-we're-working-on-the-next-version release.
It's easy to say, "people would ride public transit if it worked". But the simple fact is that "modern" urban developments, like what is now San Jose, are incredibly hostile towards working transit systems. Consider:
- Residents don't want busses going down residential streets, but major streets are far enough apart that it can be at least a 15-20 minute walk to the nearest bus stop.
- San Jose can be reasonably neatly divided into two pieces along route 280. South of the freeway, the city is primarily residential, but all of the jobs are north of it. This means that, in a north-south transit system, everybody will get on at the south end and get off at the north end, meaning you need higher capacity than if people were continuously getting on and getting off.
- People are already quite attached to their cars, and I'd suspect the automotive and petroleum industries have quite a bit more political clout than the nonexistent mass transit industry. So funding is more likely to go to big road projects than to big transit projects.
- And without funding, public transit is stuck at the same level it is now: busses that run on extremely sparse routes every half hour at most, and sometimes just don't show up.
All of this means that public transit systems have to fight a hard uphill battle to keep the minimal level of service they have now. And this level of service isn't encouraging; when it takes six times as long to take the bus as it is to drive, anybody with a car will prefer to use it at almost any cost.What, in particular is wrong with X? I use even some of its more obscure features on a regular basis. What I would like to see in kernel graphics support is KGI, with good device support, and then XGGI on the userspace side, but that probably won't happen until GGI is ready.
Well, no, not really. But it's different. Over Zephyr (to pick an IM system completely at random), you can have a conversation between individuals, or a discussion within a group. It's kind of like the difference between talking to someone on the phone (or having a conference call) and writing them a letter (or trying to resolve something via the opinion page of your local paper).
What? Internet? Productive? Huh? :-)
- The ability to send messages to other users (much like AIM, from what I remember back when I was an AOL user and had never had even a Unix shell account before)
- "Classes" and "instances", which carry messages on some particular subject (e.g. "help", or any of a number of classes each belonging to a particular student group)
- X and tty support in the default client, and a proliferation of other clients (at least at MIT)
- Users can hide an unhide themselves, so other users can locate them or not, and set whether an announcement is sent when they log in
I have no idea how this compares to the feature set in AIM, ICQ, or IRC. I just know they're all out there, and AFAICT do more or less the same thing.(IMHO, Emacs is also a "standard" part of most Un*x systems, and apparently lots of people get lost if their system doesn't include make, gcc, and libc header files. So even those "developer tools" should probably be a standard part of Corel KDE/GNU/Debian Linux (TM).)
- Pies cost 95 cents, with a 3 cent mandatory upgrade, for a total of 98 cents.
- Source for the pies (in Scheme) was freely available; when the booth was in Lobby 10, there were stacks of printed source code under each of the pies.
- The pie source was GPL'd.
- All proceeds went to the FSF.
Even more amusing was that, when I showed up to my 11:00 Urban Studies class with a slice of Open Source apple pie, the instructor even had something of a clue about Open Source and Linux. Cool.Actually, the intelligence I've heard is that it will be Building 32. Which is consistent; then you can walk through 33, 35, 37, 39, 38, 34, 36, 32, in that order. Apparently Building 20 is having its number retired.
You could add them to your user menu on the panel. Or, if you're running Debian and the packages have standard Debian menu entries, they should appear on the Debian menu in the panel.
FWIW, I'm not too fond of any of them myself. Of the five, I like #2 the best as well, genie bottle or otherwise. (The bottle at least seems to go decently with the spirally thing, even if it doesn't add any meaningful content.)
As a point, these Debian packages are still under serious development. They're in a separate staging area (a) to resolve version skew and (b) because the developers believe that things aren't stable/bug-free/well-packaged enough to put into the unstable distribution. As much as I'd like to have a working GNOME setup again, I'm waiting until the packages actually get released.
As somebody who tries to be helpful on the comp.os.linux.* newsgroups, I've got to say there's a lot of general newbie clue failure out there. Questions like "how do I find out how much free disk space I have" get asked over and over and over again, more frequently than not cross-posted to several newsgroups. People don't understand how to use the resources available to them: FAQs and HOWTOs go unread, DejaNews unchecked, and even the past 24 hours' worth of newsgroup posts that contain a nearly identical question and a more than functional answer are completely ignored.
Well, I'm part of an MIT student group that projects 35mm films every weekend. We get films in between "real theaters" and when they come out on video. For a second-run theater like us, $20,000 can be a lot. If new films are produced only in digital, it'll essentially kill the second-run theaters, leaving your choices an increasingly expensive show in a first-run theater or renting the video (also getting more expensive and of poorer quality).
This could be why they're still in a special development "sandbox", and not released into even the unstable Debian distribution.
I'd be really hesitant to label the Debian GNOME maintainers as "poor bastards". The simple fact is that there are lots of little pieces related to Gtk+ and GNOME and such, and the maintainers are putting a lot of work into making sure it all works together. So we have a working GNOME that is part of Debian, and not just some random RPMs that the GNOME people put out that may or may not work with other RPMs.
Twin was originally designed as a tool to source-port Windows applications to Other OSes (like Linux and the Mac). Working binary emulation I think is more of a secondary goal, but there is an x86 emulator in the Twin sources. Wine, if I understand correctly, is only a binary emulator, and only runs on machines that can natively run x86 machine code.
The problem seems to be not so much that the different development versions of Gtk+ weren't compatible with each other (the incompatibilities were well-known as far as I could tell) but that developers of other packages insisted on releasing software that depended on libraries known to be in development. Debian seems to have dealt well with the Gtk+-1.1 incompatibilities, but at the cost of having close to a dozen different versions of the same library in the unstable tree.
Now that Gtk+-1.2 is out, hopefully everybody will fix those last little incompatibilities, and we can be back to having one active version of the library. *sigh*