It was cool seeing places I know. I drive by the Netscape buildings nearly every day on my way to work.
Yeah, same here, I ride light rail by there. Seeing your effective home town on TV is an interesting experience. Also recognized shots of 4th and Market in SF.
Well I just saw it. Living here in the valley, less than 5 miles from Netscape, and having been around their campus at SVLUG meetings (not to mention commutting past it daily), it really hit home.
The pace of the documentary is very odd. It starts out at a very important time in Netscape's lifecycle, but even at the beginning you get the sense Netscape is past its peak here, though it still feels like a startup. The focus is very much on something that is (oh, thank god!) becoming foreign to me, and is generally not such a big deal in the free software world: the rush to release on time. Lots of detail on all nighters, the rush to fix bugs and rewrite code, the usual things you'd expect near a release.
Although I always had the impression they just grep -v'd for profanity, excised third party code, and made a tarball, there was actually a lot of work there, including pulling in third party linux people to try to build it before release and bugfixing.
After the release is chronicled, it's all downhill, and the story skips forward faster. Before you know it, it's discussing people leaving the company, the buyout by AOL, etc.
Throughout, I was very pleased with JWZ's pointed comments on life in the valley. I also enjoyed the segment on Pavlov, since I know him vaguely from IRC and was suprised to realize this was the same person.
Oddly, there is no single establishing shot of a full netscape screen. Either they assume you know what it is, or it's meant to be a mysterious, incomplete entity. A great deal of screen time is given to extreme closups of scrolling code on linux boxes, and people typing (what are supposed to be) crypic commands into shells. Loads of fun, although it can be annoying to try to keep up with what the programmers are doing and try to listen to the narrator at the same time. Video of a shell prompt being typed at is hypnotic to me..
There's a tiny glint of hope at the end -- will Mozilla be released successfully at long last? Of course, this we don't know. Here's hoping. --
We're more concerned about eg, her being snake-bit 20 miles from nowhere in the middle of the rainforest. This is where a global phone really comes in handy. --
My younger sister is going to be traveling all around the world this year, from the Ecuadorian rain forests, to Tasmania and the Australian outback, to good old Great Britian. Alone. She understandably wants some way to call for help in emergencies.
This isn't some fat cat on a boat, just a regular person (with a kick-ass grant:-), and a very real nead for global communication.
I was in San Fransisco today and one of the MUNI stations is a huge Microsoft advertisement. However, as the main add comes into site on the way down the escalator, you see: "MICRO$OFT". Someone's added some strategic white tape in just the right places. Caused quite a double-take.
I'm pleased to see him mention Debian's Social Contract and the Debian Free Software Guidelines as well. It's a shame though, that he compeletly misunderstands these documents, and depicts them as free software licenses. The DFSG is not a license, it is a way to categorize licenses.
I'm the maintainer of the realplayer installer package in the contrib distribution of Debian. Just to forstall a flood of email, I'm writing to let people know that this version will *not* be supported by the installer until Real makes it available in some format other than a self-extracting program that must be run as root under X and requires user interaction to install. That's stupid, and I'm just not gonna go there. Once a rpm or (god forbid!) a tarball is available, the realplayer installer in unstable will be updated to use it.
In the meantime, Debian folks who really need it can install it by hand. --
"1. First, it is fine to have different window managers. Just make them at least independently consistent. The obvious example - cut and paste, different in every situation and exteremely frustrating and inefficient."
What on earth are you talking about? Window managers have nothing at all to do with copy and paste. And copy and paste is consistent amoung every X app I have ever used. You select text with the left button and paste with the middle button.
Few programs support cut and paste at all; but that's either an X or an application-level issue, it has nothing to do with window managers. --
Finally, consider this python statement: x=['a','b',{'c':'d','e':['f','g']},['h',['i','j']] ]. I admit that perhaps I'm not the swiftest perl programmer ever, but it is certainly not that easy to make a data structure which is a list of strings, hashes of strings and lists, and lists of lists in perl.
Amazingly, your code above is almost exactly how one does it in perl:
The problem is that most people who make statements like you did are completly unaware of perl's [] syntax.
As for OOP in perl -- the amazing thing about perl's approach to OOP is it gives you complete fexability as to which varient of OOP you want to use. Can classless OOP (the variety of OOP used in LambdaMOO) be implmented in python? It can in perl.. Granted, this is completly useless to the beginner, but guess which language I choose to implement a lambdamoo clone in? --
> Redhat, Corel, SUSE, Debian, Slackware, all > these distributions are starting to cater to > what the "wealthy organizations" are "demanding" > not to what "Joe-User-downloading-for-free > -off-the-internet" is asking for.
Debian is not a company. If someone from a big comany comes to debian and asks us to do something, we listen to them exactly as much as we do to any other individual user, and no more.
I hope the rest of your post made more sense, but I couldn't bear to read on after reading such bullshit in the second sentence. --
Of course this poster is flaming without many facts. Debian's init system is sysv, and is in the place you'll find it on most other sysv unices, _except_ redhat. --
Kennith, the cricual thing you are forgetting is that Y2K problems are still being found. Debian could have behaved like some other distributions did and claimed to be 100% Y2K compliant many months in advance, and then as more problems were found, either kept their head stuck in the sand, or backpedaled and released patches with little fanfare.
But we didn't, because we're more interested in overall quality than in PR, and because we belive in openness. So instead we put up a public list of known Y2K problems, and worked on keeping that up-to-date, and on fixing them. When we had a large collection of Y2K fixes available, I publicized it in Debian Weekly News, well knowing someone would respond the way you have, but considering it much more important to make sure everyone had a chance to upgrade to it.
Compare this with Red Hat's response -- their Y2K page is a mixture of reassurance, and legalese -- "You won't have problem, but if you do, you can't sue us." (You can't sue Debian either.;-) It's not under the legal/ directory of thier web site by mistake.
Nethack's developers finally woke up and recently released a y2k-safe version of nethack, fixing problems we had been aware of for months -- days too late for it to go into our Y2K update. (It is in unstable, of course, and has been backported to stable now.) Do you really think that other distributions that claimed y2k compliance this summer already had that fix in place? If they did, why didn't they share it? Redhat's errata page lists exactly 0 Y2K fixes for Red Hat 6.1, which has been out since October.
You mean like the %pre, %post, %preun and %postun scripts in RPM?
You're ignoring the bit where Wichert says "special-case upgrades, handle error-recovery in failed and aborted upgrades, etc." Debian postinst scripts can each be called in multiple ways, with informative parameters. So for example, if all files in a package are replaced by files from other packages and the package "disappears", its postrm is run with parameters that let it know what's going on. Or if you install a package that is replacing a package it conflicts with, and the new package's postinst fails, the conflicting package's postinst gets a chance to deal with this situation. There are all kinds of complex situations like this, enumerated here. I'm not aware of RPM scripts having access to such detailed information.
Right now, installing Debian takes a couple of hours. Is any work being done on improving the install process? Is any work being done on making package management less interactive (answer all of the config questions either before or after install, rather than during).
Yes, debconf will allow either of these to be done, as well as limiting the questions you see to only the most important ones.
You imply that Debian developers are not also upstream providers. But, in reality, over 134 of the packages in Debian were written by Debian developers, including well known things like sysvinit.
It was cool seeing places I know. I drive by the Netscape buildings nearly every day on my way to work.
Yeah, same here, I ride light rail by there. Seeing your effective home town on TV is an interesting experience. Also recognized shots of 4th and Market in SF.
--
Well I just saw it. Living here in the valley, less than 5 miles from Netscape, and having been around their campus at SVLUG meetings (not to mention commutting past it daily), it really hit home.
The pace of the documentary is very odd. It starts out at a very important time in Netscape's lifecycle, but even at the beginning you get the sense Netscape is past its peak here, though it still feels like a startup. The focus is very much on something that is (oh, thank god!) becoming foreign to me, and is generally not such a big deal in the free software world: the rush to release on time. Lots of detail on all nighters, the rush to fix bugs and rewrite code, the usual things you'd expect near a release.
Although I always had the impression they just grep -v'd for profanity, excised third party code, and made a tarball, there was actually a lot of work there, including pulling in third party linux people to try to build it before release and bugfixing.
After the release is chronicled, it's all downhill, and the story skips forward faster. Before you know it, it's discussing people leaving the company, the buyout by AOL, etc.
Throughout, I was very pleased with JWZ's pointed comments on life in the valley. I also enjoyed the segment on Pavlov, since I know him vaguely from IRC and was suprised to realize this was the same person.
Oddly, there is no single establishing shot of a full netscape screen. Either they assume you know what it is, or it's meant to be a mysterious, incomplete entity. A great deal of screen time is given to extreme closups of scrolling code on linux boxes, and people typing (what are supposed to be) crypic commands into shells. Loads of fun, although it can be annoying to try to keep up with what the programmers are doing and try to listen to the narrator at the same time. Video of a shell prompt being typed at is hypnotic to me..
There's a tiny glint of hope at the end -- will Mozilla be released successfully at long last? Of course, this we don't know. Here's hoping.
--
We're more concerned about eg, her being snake-bit 20 miles from nowhere in the middle of the rainforest. This is where a global phone really comes in handy.
--
Many good points, however:
:-), and a very real nead for global communication.
My younger sister is going to be traveling all around the world this year, from the Ecuadorian rain forests, to Tasmania and the Australian outback, to good old Great Britian. Alone. She understandably wants some way to call for help in emergencies.
This isn't some fat cat on a boat, just a regular person (with a kick-ass grant
So, what options are left?
--
I was in San Fransisco today and one of the MUNI stations is a huge Microsoft advertisement. However, as the main add comes into site on the way down the escalator, you see: "MICRO$OFT". Someone's added some strategic white tape in just the right places. Caused quite a double-take.
--
I'm pleased to see him mention Debian's Social Contract and the Debian Free Software Guidelines as well. It's a shame though, that he compeletly misunderstands these documents, and depicts them as free software licenses. The DFSG is not a license, it is a way to categorize licenses.
--
It's amazing how good Debian is, given how chaotic the development cycle is beneath the veneer of seriousness
One could say the same thing about the linux kernel, or any number of other free software projects.
--
According to this advogato article, mostly kernel hackers (including Alan Cox) got offers. Seems some apache folks ago got it.
--
I'm the maintainer of the realplayer installer
package in the contrib distribution of Debian. Just to forstall a flood of
email, I'm writing to let people know that this version will *not* be
supported by the installer until Real makes it available in some format
other than a self-extracting program that must be run as root under
X and requires user interaction to install. That's stupid, and I'm just not
gonna go there. Once a rpm or (god forbid!) a tarball is available, the
realplayer installer in unstable will be updated to use it.
In the meantime, Debian folks who really need it can install it by hand.
--
What on earth are you talking about? Window managers have nothing at all to do with copy and paste. And copy and paste is consistent amoung every X app I have ever used. You select text with the left button and paste with the middle button.
Few programs support cut and paste at all; but that's either an X or an application-level issue, it has nothing to do with window managers.
--
"quotes a LinuxCare employee, and is probably only slightly more solid than the same rumors we've been hearing for ages now"
Actually, Art Tyde is the CEO of LinuxCare. Not a random employee.
--
Amazingly, your code above is almost exactly how one does it in perl:
$x=['a','b',{'c' => 'd','e' => ['f','g']},['h',['i','j']]]
The problem is that most people who make statements like you did are completly unaware of perl's [] syntax.
As for OOP in perl -- the amazing thing about perl's approach to OOP is it gives you complete fexability as to which varient of OOP you want to use. Can classless OOP (the variety of OOP used in LambdaMOO) be implmented in python? It can in perl.. Granted, this is completly useless to the beginner, but guess which language I choose to implement a lambdamoo clone in?
--
"What happens when X is broken and you need to install xserver-foo to get it working?"
Debconf will fall back to one of it's other ui's automatically. Once I or someone else actually writes a good X ui, that is..
--
It's basically where I wrote down everything I learned about the package formats while writing alien.
--
> Redhat, Corel, SUSE, Debian, Slackware, all
> these distributions are starting to cater to
> what the "wealthy organizations" are "demanding" > not to what "Joe-User-downloading-for-free
> -off-the-internet" is asking for.
Debian is not a company. If someone from a big comany comes to debian and asks us to do something, we listen to them exactly as much as we do to any other individual user, and no more.
I hope the rest of your post made more sense, but I couldn't bear to read on after reading such bullshit in the second sentence.
--
> You can't open-source domain names!!
Yes you can. See ml.org.
--
Why would linus care? He hasn't gone after Caldera, or RedHat, or SuSe, which all distribute binary-only components.
--
You can buy unstable on a cd from many vendors who are listed on debian's web site. http://www.debian.org/distrib/vendors
--
Of course this poster is flaming without many facts. Debian's init system is sysv, and is in the place you'll find it on most other sysv unices, _except_ redhat.
--
Kennith, the cricual thing you are forgetting is that Y2K problems are still being found. Debian could have behaved like some other distributions did and claimed to be 100% Y2K compliant many months in advance, and then as more problems were found, either kept their head stuck in the sand, or backpedaled and released patches with little fanfare.
But we didn't, because we're more interested in overall quality than in PR, and because we belive in openness. So instead we put up a public list of known Y2K problems, and worked on keeping that up-to-date, and on fixing them. When we had a large collection of Y2K fixes available, I publicized it in Debian Weekly News, well knowing someone would respond the way you have, but considering it much more important to make sure everyone had a chance to upgrade to it.
Compare this with Red Hat's response -- their Y2K page is a mixture of reassurance, and legalese -- "You won't have problem, but if you do, you can't sue us." (You can't sue Debian either. ;-) It's not under the legal/ directory of thier web site by mistake.
Nethack's developers finally woke up and recently released a y2k-safe version of nethack, fixing problems we had been aware of for months -- days too late for it to go into our Y2K update. (It is in unstable, of course, and has been backported to stable now.) Do you really think that other distributions that claimed y2k compliance this summer already had that fix in place? If they did, why didn't they share it? Redhat's errata page lists exactly 0 Y2K fixes for Red Hat 6.1, which has been out since October.
--
Yes, I did some minor updates to the install process to make debian stable use the 2.2 kernel for the boxed set.
--
You mean like the %pre, %post, %preun and %postun scripts in RPM?
You're ignoring the bit where Wichert says "special-case upgrades, handle error-recovery in failed and aborted upgrades, etc." Debian postinst scripts can each be called in multiple ways, with informative parameters. So for example, if all files in a package are replaced by files from other packages and the package "disappears", its postrm is run with parameters that let it know what's going on. Or if you install a package that is replacing a package it conflicts with, and the new package's postinst fails, the conflicting package's postinst gets a chance to deal with this situation. There are all kinds of complex situations like this, enumerated here. I'm not aware of RPM scripts having access to such detailed information.
--
Right now, installing Debian takes a couple of hours. Is any work being done on improving the install process? Is any work being done on making package management less interactive (answer all of the config questions either before or after install, rather than during).
Yes, debconf will allow either of these to be done, as well as limiting the questions you see to only the most important ones.
--
That's what ] is for. (Well, in some lispish dialects anyway, it closes all open parens.)
--
You imply that Debian developers are not also upstream providers. But, in reality, over 134 of the packages in Debian were written by Debian developers, including well known things like sysvinit.