This is very easy to fix. First we run in a public server (or a network of servers) a service that can return the checksum for the executable on demand. So just a single executable is required. Then the service provides this data on demand to clients.
The client would typically check whether it has the checksum being requested on its cache, if it does not, then it contacts the checksum.aim-provider.com server with the appropiate arguments, gets the value, and provides this back to AOL.
Actually, if you read the entire article (but i think you got confused), the benefits of free software (being able to modify, and redistribute said modifications) is part of the features that the interview mentions.
I do not know if that is on the web version, but it was definetly in the printed version (which also included a mini-FAQ on the whole Linux thing).
Well, the people running the projects are the friends I worked with a few years ago (Patrick Vielle and Jose Barberan). I am glad the government has followed up on this.
I was in Mexico City this weekend trying to get the eMexico project to adopt free software as well. You can read the paper I presented here: http://primates.ximian.com/~miguel/emexico.html
Well, that is correct if you are just trying to do the obvious. There are a number of extensions to X that address this problem (Indeed games in Linux do use this strategy to bypass the X server).
SGI pioneered Direct Rendering, which is a trick that requires hardware + (kernel and or X) support to allow user land applications to directly drive the hardware.
Various PC hardware cards have supported this for a long time, and a few people were working on this. I lost track of this project a long time ago, as my interests shifted to other things.
No, the situation is not as you picture it. I think you should have also put links to the various follow-up articles, in which we explain what is going on in GNOME.
Nautilus --which has a large set of developers and a lot of work going towards it-- is really one of the core components of the desktop. I am sorry for Alan if there are not too many hackers working on new IRC clients, or on new color selectors, I think that overall, we are more focused on the problems of users than we were in the past.
Components like Evolution contain some killer features that will help a lot of people transition to Linux, and the kind of work and effort required to develop an application of this size is not trivial. Just supporting every feature correctly for IMAP and broken IMAP servers is a daunting task. Having the best syncronizing tool for PalmPilots and for syncing multiple devices is also an important feature not available anywhere else (not to mention vFolders, quick searches, great user interfaces and more).
Both applications (Nautilus and Evolution) rely on very new technologies that are at the core of GNOME
Also, look at things like the Ximian Setup Tools, which are just a set of GNOME applications (branded by my company, to get some credit for the work we are putting on it) that addresses the major problem of having a user-friendly unified system configuration for Unix (here)
Our work on the Bonobo foundation is unparalleled. Once we started deploying it, many new ideas came out (like Monikers) that have enabled extremely powerful mechanisms to be created.
We sadly do not have white-papers for all of our technologies, but we are working towards documenting them. If you are interested in helping, get in touch with me.
A few things we have recently done and are shipping as part of GNOME 1.4:
Bonobo 1.0 Ready to ship with GNOME 1.4
GtkHTML: An HTML editor and rendering engine.
EBrowser: A Bonobo component to do web browsing
Gnome Spell: A Bonobo component for doing spelling, suggestions, and dictionary lookups. All available to any application that supports Bonobo.
Gnome VFS: Access any resources on the network transparently.
There are a lot more technologies comming down for GNOME 2.0, and you can read about some of them at: http://primates.ximian.com/~miguel/gnome-2.0
Other things like Gtk from frame buffers and Pango are developed at the RHAD Labs (http://www.labs.redhat.com) and constitute part of the core technologies in GNOME 2.0
It seems that a few conclussions are drawn incorrectly in this interview.
Usability and toolkits. The fact that the GIMP has not a great user interface, does not mean it is caused by its use of Gtk+. Usability and good user interfaces are long tasks that require usability testing, reuse of good paradigms, and constant improvement. It is not a function of the toolkit as you like to present here.
For instance, take Gnumeric: the best free spreadsheet available, the one with the most confortable user interface, pleasant to use and only surpased in functionality (but not in usability) by OpenOffice. Guess what? Gnumeric is fully written in Gtk+.
Evolution is another good example: it has a great user interface, but some bits of usability are still not there, and we are working actively to do user testing to make sure we provide a better interface, but this has nothing to do with the underlying technologies (as you like to convenientnly present in your interview). It has to do with matching the "User view" with the application, rather than forcing the application model into users.
Bonobo and CORBA: I have repeated this a number of times, but it seems that people are not interested in facts, but more interested in doing marketing "their way".
OpenParts (KDE's CORBA-based component architecture) failed for a number of things, few of which could be traced to CORBA, I will enumerate the ones i remember, for the sake of completeness:
The dependency on MICO: MICO was the biggest and slowest CORBA implementation around the block. GNOME used MICO for a few releases, and before GNOME 1.0, we had written our own thin and fast implementation to circumvent the problems of size and bloat associated with MICO. The KDE team chose to keep using it because MICO was "feature complete".
Incorrect programming practices: The C++ CORBA binding implemented by MICO is the one that uses the C++ exception mechanism to report errors during a Remote Procedure Call invocation. This is CORBA's way of telling you "there was an error while talking to the remote server, here is the reason...". The code in OpenParts and in KOffice at the time decided that it would make their code "ugly" if they had to check for exceptions, hence they ignored all exceptions, so code that should have looked like this:
try {
corba_object->method (x);
} catch (...) {
handle corba errors here;
}
Was actually written like this:
corba_object->method (x);
Of course you get "unreliable" code if you do not handle errors. (btw, notice that most security holes on BugTraq a few years ago were all caused because people did not handle boundary conditions correctly, nor handle errors from Unix system calls correctly.
Complex and big interfaces: The "base" interface in KOM had something between 17 to 23 methods, a pretty large interface. The "base" interface in Bonobo, COM, UNO and XPCOM is only three.
Bonobo and GNOME: Bonobo 1.0 is shipping as part of the upcoming GNOME 1.4 release. And it is the building block used by Nautilus and Evolution. Various applications support Bonobo already and they can integrate directly with Nautilus and Evolution (Indeed, OpenOffice integration with Bonobo is being demoed at every Linux show at the Sun booths where you can see Bonobo/OpenOffice integration being demoed).
Could you tell us what makes you think that DnD is broken? I am sure that the developers would like to know this, and I would love to fix things that are annoying users.
The 2 sets of mime types is indeed annoying.
KDE docklets work in GNOME just fine.
In general GNOME integrates the KDE menu into its own menu. Ideally we should be sharing the same menu.
I agree with you about the themes. I have suggested in the past to the KDE people to write together an cross-theme API that would allow theme engines to be written once, and used everywhere, but there was not too much enthusiast on Matthias part. He has since stalled saying that `he has an idea for this, and that he will post later', but the idea has yet to happen. The approach of having a unified subset of the API calls required to have a theme engine is not only doable but simple.
(On the other hand, Helix software installer is called "Red Carpet";-)
Nat and I arrived to the name "Helix Code" (which was the name under which we incorporated our "International GNOME Support" company) after much debate.
The project began By the end of the summer we were still using IGS as our name, and we had been talking to a lot of people about IGS. Although we did not like the name, and we started looking for a new one.
Nat had picked up the name Hopscotch, which I did not like. The name also had problems because some company owned the trademark for the name, so we had to look for another one. The debate for the name had created so many constraints that we were uncapable of agreeing to the suggestions that the other one did.
Eventually, we came up with two lists of suggestions, and Nat said `Ok, remove the ones you dont hate from my list, and I will do the same to yours'.
And we ended up with two empty lists.
So we were in this Evolution kind of mood (because of our product, and our recent interest in evolution), and Nat suggested finally `what about Code Helix?' and given our previous frustration, we quickly agreed on it. We later that day changed our minds, as we thought that Code Helix would make people think `They do developer tools' (I do not remember what was the thought process that followed here), but we changed the name to `Helix Code'.
Now, this was not a final name, it was just a temporary name that we would use to incorporate the company, and we would change it as soon as possible. Neither Nat nor I liked the name originally, so every time we told a friend "We are starting a company!" when the question about the name came in, we would explain for five minutes why it was not such a great name and so on.
We began the work to find a new name almost in march 2000, when we were told by our lawyers that it would be very hard to avoid other companies to produce Helix products (like this complete copy of Helix Code that is not associated with us: Helix Code UK).
A temporary name that Jacob liked was "Loolix Bode" which was what the ATT 411 service guessed when we called for information about the company once.
The process of the name change had been going for a number of months and many names were suggested. Both Nat and I experimented extreme frustration and lack of imagination after countless meetings to change the name. Jacob to this day calls the company "Loolix Bode 2000". And Ian still calls the company "Mr. Rupert's Quality Software Group" (mr rupert being the Helix mascot).
After a year, I am very attached to Helix Code, but the name and products we would produce would be pretty much unprotectable, and there would be no guarantee to customers that they were purchasing software or services from us. And too many companies already had Helix-prefixed products that were in similar domains.
There were a lot of nice sounding names, and various names we scanned from various countries, towns, cultures, languages, but most of the ones I liked were at least taken on the DNS.
There are even more details to the story, but they are quite boring.
The Ximian name fits nicely with our monkey logo and with our monkey culture and with the evolutionary theme that has been in the company since we started it.
As I said on the interview (but it seems the url got lost somewhere), we have been working on a cross-platform set of tools to configure and customize your Linux system.
Well, I originally heard of query-based folders in the Paquiderm mailer (Jim Gettys showed this to us a long time ago). Paquiderm, and the help of Nyao Nguyen (who was a VM author). Jamie Zawinski later pushed for the current setup which is: work the way people expect using files-as-folders and add vfolders, and let people migrate.
Now, I did not claim it was a new invention, just that we hope that Evolution will help popularize this way of handling e-mail.
The reporter you quote there chose to "selectively" quote Dom, and "selectively" quote Havoc.
Although both wanted to convey a different story, the reporter chose to push forward his own agenda. You can mail Dom and ask him, and you can mail Havoc and ask him.
You can read the archives of the gnome-office-list where the discussion and a complete explanation can be found:
McKusick's Soft Updates has also a nice feature: unlike the journaling file systems, it does not have the burden of writing blocks to a logging device. So a soft-updates enabled kernel runs at the speed of traditional asyncronous file systems (ie, default ext2) while providing a very good level of reliability (it is not a syncronous file system, so it runs at a very enjoyable speed).
You can boot a Soft Updates file system without fscking it, the file system will be in a functional state. The only problem is that you might start to loose free blocks that are believed to be busy. So every 100 or 200 crashes you might want to run fsck to free those 100 blocks.
I agree with you regarding the ext2 file system when running in async mode: when there is a lot of activity on the disk, and a lot of changes to the file system, crashing an ext2 file system will loose a considerable ammount of data. ext2 fsck will not be able to recover your file system properly (it has happened to me a couple of times already).
For non-SoftUpdates kernels and non-Journaling kernels, if you are running a system with sensitive information, I suggest turning syncronous access on the file system (add option sync to it).
The sad part here is that the BSDs have traditionally been optimized for the syncronous case, so they run at acceptable speeds. Linux ext2fs has never been optimized for this case so in practice it is very slow.
I am using ReiserFS on my laptop, but on a server, if I had to choose, I would run SoftUpdates for BSD kernels and ReiserFS for Linux kernels.
No corruption, no losses. It's like having an UPS attached.
Just remember, reiserfs still won't save you from total hardware failure due to power spikes.
Journaling file systems protect you from a number of problem: system crashes and power failures. They typically protect only the metadata regions of the disk (which is the administrative information used by the filesystem to run the filesystem).
To protect against hard drive failures you want to use one of the RAID setups.
The ideal combination is RAID+Logging+Backups.
Depending on your needs, budget and speed requirements you will choose your proper combination.
Myself, I use ReiserFS in my laptop which has proved to be very helpful on my 21 gig hard drive every time the kernel decides to crash after coming back from a suspend.
Yes, it will show who is the "provider" for a given channel. As you can see from the screenshots, part of the information for the Debian channel that Vlad had a screenshot for, includes the debian web page.
Making the retrieval of source code simpler is also something I know Joe and Vlad want to do as part of their "locate file" feature on Red Carpet.
There were a lot of improvements in GNOME 1.2 (Bongo GNOME), that came from different people. Jacob Berkman lead the effort to 1.2 and was one of the key people that were polishing little bits everywhere: improving, fixing, making it more usable and giving love to the user interface.
The GNOME UI team (you can find them at developer.gnome.org) provided an organized effort that helped developers improve the GNOME user interface. This team lead by Jim Cape produced mockups, screenshots, and glade files for developers to use. They provided concrete suggestions and did everything they could in their hands.
There is still a lot left to do, but we realize that there are problems in the GNOME UI, and we will keep improving it.
Tuomas kept improving the GNOME artwork for 1.2 and he is still doing this for 1.4.
And we recently hired Anna to work on user interface design. Joakim has also been providing a lot of input with full rationales and mockups based on his previous experience to improve the GNOME.
Red Carpet will be an integral part of the Helix Setup Tools (see http://www.helixcode.com/setuptools.php3).
The Helix Setup Tools are tools targeted to simplify management of a computer, and it is targeted to end users.
We have been working towards making the Helix Setup Tools address a number of needs of our users:
1. Location management (reconfiguring your system to different kind of configuration setups easily. Useful for laptop users that use a computer at home, at work, and while traveling).
2. Cluster support: configure clusters of machines, updgrade packages in clusters of machines, backup configuraiton of clusters of machines.
3. Rollback support: restore the system configuration to a date in the past.
So yes, clustering is important for us (more from the point of view of "we have a lab with computers, and we do not want to manually run helix-update on each machine" than from "we are doing a high availability cluster that does this very specific task" though).
Helix will not be updated behind your back. That is a security concern we have always had. Although we could have done an automatic updater, we are aware of privacy concerns people have and the different levels of security that people want.
The new version will have an option to do automatic updates if you choose to, but it is not the default.
We would love to hear your opinion on security matters and we would be glad to tell you how things are done internally, but lets do that without attacking each other and by making informed comments instead of worst-case-scenario-assumptions.
GNOME is a project. The GNOME project produces source code and ships it in the form of compressed tar files.
Helix GNOME is an easy-to-install, pre-compiled GNOME that ships things as packages that are easy to install and upgrade.
Helix GNOME does not support Slackware, but anyone can contribute Slackware packages to the GNOME project and put them up on ftp.gnome.org.
We do not have resources at Helix to maintain Slackware right now. We hope we will be able to in the future (and also add FreeBSD to the list).
Nobody has stepped forward to produce Slackware packages, but I am sure that if you convert the rpms to Slackware packages, we can put them up on gnome.org
As you notice there is a bar on the right that lists the channels you are subscribed to, and you can get a list of those you are not subscribed to.
We will be providing other channels besides the regular Helix GNOME channel. For instance, you can see a channel for the distribution installed in your system and a channel for testing the Helix Evolution groupware client.
Other channels will be available with other types of software as well.
Red Carpet supports multiple packaging formats unlike the previous version of the helix installer/updater. It works with both RPM and Debian packagescurrently and we plan on adding support for Solaris packages in the future as well (indeed the screenshots show the Debian version running).
You can customize your panels in pretty much any way you want. Try hitting the right mouse button in the applets and in the panel to explore the options in the panel.
Helix GNOME is just a packaged version of the latest GNOME. We took special care into making things pretty and Tuomas, Joakim and Anna have been working very hard to provide nice, pleasant user interfaces.
But all the contributions of Helix are contributed back to the main GNOME sources.
We just happen to ship the latest GNOME in a real-time fashion: you can always update to the new improvements as developers produce the code.
With Red Carpet (something that you do not see on the screenshots) we will roll three levels of updates: emergency updates, latest packages, and long-term tested packages. The intention is to catter to both people who always want the latest applications and fixes, and those who want a tested and reliable system.
Slashdot Mirror
This is very easy to fix. First we run in a public server (or a network of servers) a service that can return the checksum for the executable on demand. So just a single executable is required. Then the service provides this data on demand to clients.
The client would typically check whether it has the checksum being requested on its cache, if it does not, then it contacts the checksum.aim-provider.com server with the appropiate arguments, gets the value, and provides this back to AOL.
It is nothing but a 10 minute hack.
Miguel.
Actually, if you read the entire article (but i think you got confused), the benefits of free software (being able to modify, and redistribute said modifications) is part of the features that the interview mentions.
I do not know if that is on the web version, but it was definetly in the printed version (which also included a mini-FAQ on the whole Linux thing).
miguel.
Well, the people running the projects are the friends I worked with a few years ago (Patrick Vielle and Jose Barberan). I am glad the government has followed up on this.
I was in Mexico City this weekend trying to get the eMexico project to adopt free software as well. You can read the paper I presented here: http://primates.ximian.com/~miguel/emexico.html
Miguel.
Well, that is correct if you are just trying to do the obvious. There are a number of extensions to X that address this problem (Indeed games in Linux do use this strategy to bypass the X server).
SGI pioneered Direct Rendering, which is a trick that requires hardware + (kernel and or X) support to allow user land applications to directly drive the hardware.
Various PC hardware cards have supported this for a long time, and a few people were working on this. I lost track of this project a long time ago, as my interests shifted to other things.
Miguel.
The following links might be interesting to read:
1, 2, 3, 4.
Nautilus --which has a large set of developers and a lot of work going towards it-- is really one of the core components of the desktop. I am sorry for Alan if there are not too many hackers working on new IRC clients, or on new color selectors, I think that overall, we are more focused on the problems of users than we were in the past.
Components like Evolution contain some killer features that will help a lot of people transition to Linux, and the kind of work and effort required to develop an application of this size is not trivial. Just supporting every feature correctly for IMAP and broken IMAP servers is a daunting task. Having the best syncronizing tool for PalmPilots and for syncing multiple devices is also an important feature not available anywhere else (not to mention vFolders, quick searches, great user interfaces and more).
Both applications (Nautilus and Evolution) rely on very new technologies that are at the core of GNOME
Also, look at things like the Ximian Setup Tools, which are just a set of GNOME applications (branded by my company, to get some credit for the work we are putting on it) that addresses the major problem of having a user-friendly unified system configuration for Unix (here)
Our work on the Bonobo foundation is unparalleled. Once we started deploying it, many new ideas came out (like Monikers) that have enabled extremely powerful mechanisms to be created.
We sadly do not have white-papers for all of our technologies, but we are working towards documenting them. If you are interested in helping, get in touch with me.
A few things we have recently done and are shipping as part of GNOME 1.4:
- Bonobo 1.0 Ready to ship with GNOME 1.4
- GtkHTML: An HTML editor and rendering engine.
- EBrowser: A Bonobo component to do web browsing
- Gnome Spell: A Bonobo component for doing spelling, suggestions, and dictionary lookups. All available to any application that supports Bonobo.
- Gnome VFS: Access any resources on the network transparently.
There are a lot more technologies comming down for GNOME 2.0, and you can read about some of them at: http://primates.ximian.com/~miguel/gnome-2.0Other things like Gtk from frame buffers and Pango are developed at the RHAD Labs (http://www.labs.redhat.com) and constitute part of the core technologies in GNOME 2.0
Miguel.
For instance, take Gnumeric: the best free spreadsheet available, the one with the most confortable user interface, pleasant to use and only surpased in functionality (but not in usability) by OpenOffice. Guess what? Gnumeric is fully written in Gtk+.
Evolution is another good example: it has a great user interface, but some bits of usability are still not there, and we are working actively to do user testing to make sure we provide a better interface, but this has nothing to do with the underlying technologies (as you like to convenientnly present in your interview). It has to do with matching the "User view" with the application, rather than forcing the application model into users.
OpenParts (KDE's CORBA-based component architecture) failed for a number of things, few of which could be traced to CORBA, I will enumerate the ones i remember, for the sake of completeness:
try {
corba_object->method (x);
} catch (...) {
handle corba errors here;
}
Was actually written like this: corba_object->method (x); Of course you get "unreliable" code if you do not handle errors. (btw, notice that most security holes on BugTraq a few years ago were all caused because people did not handle boundary conditions correctly, nor handle errors from Unix system calls correctly.
The translation files are most likely a derived work of the original text strings, which are copyrighted by Sun and licensed under the GPL.
By being a derived work from a GPL material they might be in violation of the GPL. Definetly material for the more license savvy people.
Independently of whether they are violating or not the license it seems like a very bizarre restriction.
Best wishes,
Miguel.
- Could you tell us what makes you think that DnD is broken? I am sure that the developers would like to know this, and I would love to fix things that are annoying users.
- The 2 sets of mime types is indeed annoying.
- KDE docklets work in GNOME just fine.
- In general GNOME integrates the KDE menu into its own menu. Ideally we should be sharing the same menu.
- I agree with you about the themes. I have suggested in the past to the KDE people to write together an cross-theme API that would allow theme engines to be written once, and used everywhere, but there was not too much enthusiast on Matthias part. He has since stalled saying that `he has an idea for this, and that he will post later', but the idea has yet to happen. The approach of having a unified subset of the API calls required to have a theme engine is not only doable but simple.
(On the other hand, Helix software installer is called "Red Carpet"Miguel.
Can you tell us which DnD functionality Windows user have enjoyed that is not available to users on GNOME?
miguel.
Nat and I arrived to the name "Helix Code" (which was the name under which we incorporated our "International GNOME Support" company) after much debate.
The project began By the end of the summer we were still using IGS as our name, and we had been talking to a lot of people about IGS. Although we did not like the name, and we started looking for a new one.
Nat had picked up the name Hopscotch, which I did not like. The name also had problems because some company owned the trademark for the name, so we had to look for another one. The debate for the name had created so many constraints that we were uncapable of agreeing to the suggestions that the other one did.
Eventually, we came up with two lists of suggestions, and Nat said `Ok, remove the ones you dont hate from my list, and I will do the same to yours'.
And we ended up with two empty lists.
So we were in this Evolution kind of mood (because of our product, and our recent interest in evolution), and Nat suggested finally `what about Code Helix?' and given our previous frustration, we quickly agreed on it. We later that day changed our minds, as we thought that Code Helix would make people think `They do developer tools' (I do not remember what was the thought process that followed here), but we changed the name to `Helix Code'.
Now, this was not a final name, it was just a temporary name that we would use to incorporate the company, and we would change it as soon as possible. Neither Nat nor I liked the name originally, so every time we told a friend "We are starting a company!" when the question about the name came in, we would explain for five minutes why it was not such a great name and so on.
We began the work to find a new name almost in march 2000, when we were told by our lawyers that it would be very hard to avoid other companies to produce Helix products (like this complete copy of Helix Code that is not associated with us: Helix Code UK).
A temporary name that Jacob liked was "Loolix Bode" which was what the ATT 411 service guessed when we called for information about the company once.
The process of the name change had been going for a number of months and many names were suggested. Both Nat and I experimented extreme frustration and lack of imagination after countless meetings to change the name. Jacob to this day calls the company "Loolix Bode 2000". And Ian still calls the company "Mr. Rupert's Quality Software Group" (mr rupert being the Helix mascot).
After a year, I am very attached to Helix Code, but the name and products we would produce would be pretty much unprotectable, and there would be no guarantee to customers that they were purchasing software or services from us. And too many companies already had Helix-prefixed products that were in similar domains.
There were a lot of nice sounding names, and various names we scanned from various countries, towns, cultures, languages, but most of the ones I liked were at least taken on the DNS.
There are even more details to the story, but they are quite boring.
The Ximian name fits nicely with our monkey logo and with our monkey culture and with the evolutionary theme that has been in the company since we started it.
Best wishes,
Miguel.
As I said on the interview (but it seems the url got lost somewhere), we have been working on a cross-platform set of tools to configure and customize your Linux system.
You can see Arturo's screenshots here:
http://primates.helixcode.com/~arturo/hst
Miguel.
Well, I originally heard of query-based folders in the Paquiderm mailer (Jim Gettys showed this to us a long time ago). Paquiderm, and the help of Nyao Nguyen (who was a VM author). Jamie Zawinski later pushed for the current setup which is: work the way people expect using files-as-folders and add vfolders, and let people migrate.
Now, I did not claim it was a new invention, just that we hope that Evolution will help popularize this way of handling e-mail.
Miguel.
The reporter you quote there chose to "selectively" quote Dom, and "selectively" quote Havoc.
2 000-October/msg00003.html. And Havoc's post (Evan, the reporter, chose not to write anything Havoc said) is here:
2 000-October/msg00000.html
Although both wanted to convey a different story, the reporter chose to push forward his own agenda. You can mail Dom and ask him, and you can mail Havoc and ask him.
You can read the archives of the gnome-office-list where the discussion and a complete explanation can be found:
Dom's explanation is here:
http://mail.gnome.org/archives/gnome-office-list/
http://mail.gnome.org/archives/gnome-office-list/
Best wishes,
Miguel
Excel looks so ugly in comparission of the beautiful Gnumeric spreadsheet!
They still have a better general purpose spreadsheet though.
Anyways, congrats to the Wine team!
McKusick's Soft Updates has also a nice feature: unlike the journaling file systems, it does not have the burden of writing blocks to a logging device. So a soft-updates enabled kernel runs at the speed of traditional asyncronous file systems (ie, default ext2) while providing a very good level of reliability (it is not a syncronous file system, so it runs at a very enjoyable speed).
You can boot a Soft Updates file system without fscking it, the file system will be in a functional state. The only problem is that you might start to loose free blocks that are believed to be busy. So every 100 or 200 crashes you might want to run fsck to free those 100 blocks.
I agree with you regarding the ext2 file system when running in async mode: when there is a lot of activity on the disk, and a lot of changes to the file system, crashing an ext2 file system will loose a considerable ammount of data. ext2 fsck will not be able to recover your file system properly (it has happened to me a couple of times already).
For non-SoftUpdates kernels and non-Journaling kernels, if you are running a system with sensitive information, I suggest turning syncronous access on the file system (add option sync to it).
The sad part here is that the BSDs have traditionally been optimized for the syncronous case, so they run at acceptable speeds. Linux ext2fs has never been optimized for this case so in practice it is very slow.
I am using ReiserFS on my laptop, but on a server, if I had to choose, I would run SoftUpdates for BSD kernels and ReiserFS for Linux kernels.
Miguel.
Journaling file systems protect you from a number of problem: system crashes and power failures. They typically protect only the metadata regions of the disk (which is the administrative information used by the filesystem to run the filesystem).
To protect against hard drive failures you want to use one of the RAID setups.
The ideal combination is RAID+Logging+Backups.
Depending on your needs, budget and speed requirements you will choose your proper combination.
Myself, I use ReiserFS in my laptop which has proved to be very helpful on my 21 gig hard drive every time the kernel decides to crash after coming back from a suspend.
Miguel.
Yes, it will show who is the "provider" for a given channel. As you can see from the screenshots, part of the information for the Debian channel that Vlad had a screenshot for, includes the debian web page.
Making the retrieval of source code simpler is also something I know Joe and Vlad want to do as part of their "locate file" feature on Red Carpet.
Miguel.
There were a lot of improvements in GNOME 1.2 (Bongo GNOME), that came from different people. Jacob Berkman lead the effort to 1.2 and was one of the key people that were polishing little bits everywhere: improving, fixing, making it more usable and giving love to the user interface.
The GNOME UI team (you can find them at developer.gnome.org) provided an organized effort that helped developers improve the GNOME user interface. This team lead by Jim Cape produced mockups, screenshots, and glade files for developers to use. They provided concrete suggestions and did everything they could in their hands.
There is still a lot left to do, but we realize that there are problems in the GNOME UI, and we will keep improving it.
Tuomas kept improving the GNOME artwork for 1.2 and he is still doing this for 1.4.
And we recently hired Anna to work on user interface design. Joakim has also been providing a lot of input with full rationales and mockups based on his previous experience to improve the GNOME.
Red Carpet will be an integral part of the Helix Setup Tools (see http://www.helixcode.com/setuptools.php3).
The Helix Setup Tools are tools targeted to simplify management of a computer, and it is targeted to end users.
We have been working towards making the Helix Setup Tools address a number of needs of our users:
1. Location management (reconfiguring your system to different kind of configuration setups easily. Useful for laptop users that use a computer at home, at work, and while traveling).
2. Cluster support: configure clusters of machines, updgrade packages in clusters of machines, backup configuraiton of clusters of machines.
3. Rollback support: restore the system configuration to a date in the past.
So yes, clustering is important for us (more from the point of view of "we have a lab with computers, and we do not want to manually run helix-update on each machine" than from "we are doing a high availability cluster that does this very specific task" though).
Miguel.
Helix will not be updated behind your back. That is a security concern we have always had. Although we could have done an automatic updater, we are aware of privacy concerns people have and the different levels of security that people want.
The new version will have an option to do automatic updates if you choose to, but it is not the default.
We would love to hear your opinion on security matters and we would be glad to tell you how things are done internally, but lets do that without attacking each other and by making informed comments instead of worst-case-scenario-assumptions.
Miguel.
GNOME is a project. The GNOME project produces source code and ships it in the form of compressed tar files.
Helix GNOME is an easy-to-install, pre-compiled GNOME that ships things as packages that are easy to install and upgrade.
Helix GNOME does not support Slackware, but anyone can contribute Slackware packages to the GNOME project and put them up on ftp.gnome.org.
We do not have resources at Helix to maintain Slackware right now. We hope we will be able to in the future (and also add FreeBSD to the list).
Nobody has stepped forward to produce Slackware packages, but I am sure that if you convert the rpms to Slackware packages, we can put them up on gnome.org
Miguel.
This is exactly the intention.
As you notice there is a bar on the right that lists the channels you are subscribed to, and you can get a list of those you are not subscribed to.
We will be providing other channels besides the regular Helix GNOME channel. For instance, you can see a channel for the distribution installed in your system and a channel for testing the Helix Evolution groupware client.
Other channels will be available with other types of software as well.
Miguel.
We will keep your comment in mind for Red Carpet.
Please, if you have more suggestions on how to improve Helix's updater, let us know by sending mail to beta@helixcode.com.
Miguel
Red Carpet supports multiple packaging formats unlike the previous version of the helix installer/updater. It works with both RPM and Debian packagescurrently and we plan on adding support for Solaris packages in the future as well (indeed the screenshots show the Debian version running).
You can customize your panels in pretty much any way you want. Try hitting the right mouse button in the applets and in the panel to explore the options in the panel.
Miguel.
Helix GNOME is just a packaged version of the latest GNOME. We took special care into making things pretty and Tuomas, Joakim and Anna have been working very hard to provide nice, pleasant user interfaces.
But all the contributions of Helix are contributed back to the main GNOME sources.
We just happen to ship the latest GNOME in a real-time fashion: you can always update to the new improvements as developers produce the code.
With Red Carpet (something that you do not see on the screenshots) we will roll three levels of updates: emergency updates, latest packages, and long-term tested packages. The intention is to catter to both people who always want the latest applications and fixes, and those who want a tested and reliable system.
Miguel.