Ubuntu makes a fine server OS. What do you think www.ubuntulinux.org is running on? Remember that Ubuntu is basically a branch of Debian, which many people find okay to run on servers.
Securing it in a networked environment is also pretty easy -- the default install doesn't have any services listening on the network, so the only listening services will be the ones you install.
Actually, the "Human" theme that Ubuntu uses as default is based on Industrial (slightly different colours, and square corners on the windows). This may change in the future though.
In many cases, a library will require some other support files at runtime. Unlike dynamic linker dependencies, there isn't a reliable way to find out about these requirements. The common way to handle this is to combine the library and support files into a single package that is installed as a single unit (or include a dependency on the package containing those support files).
Now in the case of a small "libsquat.xx.so.3" being part of a large package, if the library doesn't require all the files in the package, and the library is intended for use by other programs a linux distro will usually package the library separately with only the files it requires, and make the larger package depend on the library package. If there are particular instances where this hasn't happened in your distro, perhaps you could try filing a bug.
As for recursive package removal, it is fairly trivial to find all the leaf nodes on the package dependency tree that could be removed without causing an inconsistency, but it isn't easy to tell whether it is safe to remove said packages. Which leaf packages is the user actually using? The user may be using some packages that may have been installed to satisfy dependencies, so you can't just remove packages that weren't explicitly installed by the user.
Lastly, if "fungame" requires libsquat.xx.so.3, then libsquat.xx.so.4 would _not_ satisfy that dependency. If two libraries have different sonames, then they provide different ABIs (they use different filenames so that you can install them in parallel to satisfy the dependencies).
Overall, the features you've brought up are already available in the current generation of package management systems -- you just want finer grained packaging.
Well, the "System Monitor" app matches up application icons to processes in the process list, so the user should be able to work out the name if they need to. However, they shouldn't need to for a few reasons:
Applcations shouldn't need manual killing in the first place:)
If an application has hung, you can use the close button in the window title bar. The Metacity window manager uses the _NET_WM_PING window manager protocol to see if the app is alive. If the app isn't responding, it asks the user if they want to kill the app (using XKillClient and if it is a local process kill() as well).
If you want to find out what the executable name a particular menu item will launch, you can right click on it and choose properties. This should be discoverable enough for users who know how to run remote X applications.
Now as for GConf, it is an abstraction for storing and retrieving preferences, and getting notification of changes to preferences. The gconf-editor program is simply a program that uses the GConf API.
I'm not sure why you thought it necessary to use gconf-editor to change your font though. The fonts control panel is pretty easy to find (it is "Font" under the desktop preferences menu). Was there some other basic preference that you were thinking of?
Sure there might be an executable installed as/usr/bin/gcalctool, but it is exposed in the menus simply as "Calculator". The title bar for the calculator also says "Calculator" as opposed to "Gnome Calculator" or "Gcalctool". The "Gcalctool" name is shown in the about dialog, but that is it.
The user doesn't need to care about what the underlying executable name is. This is what the parent post was probably refering to.
Now if Gnome did install executables with names like/usr/bin/calculator, people would complain because it would make it more difficult to integrate into a distribution because of file name conflicts.
On what basis do you think that a mail client should not be included in the Gnome desktop release?
A significant portion of users need a mail client, so it makes sense to include one (in the same way that a web browser, and other utilities are included).
Things are still modular, so you don't need to install Evolution. There isn't anything stopping you from integrating another mail client, and distributors can easily change the defaults if they want a different default mail client.
Also, what would be the benefit of included evolution-data-server without Evolution? A calendar and address book backend is not particularly useful without a way to manipulate them...
The component of Evolution that handles storage of calendar and address book data has been split off into a separate evolution-data-server module. This is the module that other programs use for calendar and address book integration.
It would also be possible for other mail clients to make use of e-d-s for address book storage, in which case they would also benefit from the desktop integration.
The script used to upload files to the master FTP site also mailed MD5 sums to a mailing list hosted on another machine. That script doesn't appear to have been altered (to insert a backdoor, the script would need to repack the tarballs with an exploit on the fly), so the MD5 sums from that mailing list should be reliable.
Re:One thing I'd love to see in KDE that was added
on
Gnome 2.4 Release(d)
·
· Score: 1
Gnome 2.4 supports.hidden files, just like MacOS X and KDE.
Is slashdot ever going to switch to use the logo that the Gnome project has been using for over a year? Surely people would be more likely to associate the new logo with the project.
Because that is where we decided to hold it. 2002 was in Brisbane, 2001 was in Sydney and CALU was held in Melbourne. It will be somewhere else next year.
Many Western Australians would have had the same reason for not going to previous conferences, so holding the odd conference over here is a good idea.
It is too bad you can't make it though, because it is going to be a great conference:)
There is support for the RandR extension in the latest releases of gtk+ (including the version in the beta). I don't know if any apps have been modified to use it though. Probably the only ones that need to care about screen size changinges are the window manager (metacity), the panel and nautilus.
The GNOME Foundation is not a money laundering operation, like you seem to be implying.
The major way companies like Sun, Ximian and Red Hat help is by employing people to work on GNOME. They don't get a tax deduction for hiring people to work on GNOME.
The GNOME Foundation does not employ any developers (it has one employee: Tim Ney, the executive director, who does a lot of the organisational work). You can find details of what the Foundation does at foundation.gnome.org/.
If you think the main reason most people work on GNOME is to help big business, then you are mistaken. It certainly hasn't been the motivation for my contributions, which started before Sun started working on GNOME, and before any Linux distro was including GNOME (let alone as its default desktop).
On the subject of tax deductability, the GNOME Foundation meets the criteria for section 501(c)(3) (the foundation's work is of public benefit). If you don't feel that it should have tax exempt status, then you should campaign against the law.
You make it sound like the foundation is trying to trick people in to donating. We are being quite open about what the money will be used for, so each person who considers donating can make an informed choice.
I probably wouldn't call the GNOME Foundation as a charity either. However, it is a non profit organisation as recognised by US law (I suppose charities are a subset of non-profits).
If you would prefer to give your spare income to another charity/non-profit, that is your choice. We are being upfront about what the money will be used for.
If you feel that a donation to the GNOME foundation does not deserve a tax deduction (ie. you would prefer to pay tax on the contribution), feel free to not declare the donation.
Xft can handle Type1, TTF and OpenType fonts (and in the version included in CVS XFree86, bitmap PCF fonts as well). Simply add a "dir" line to the XftConfig file for each font directory. No need to create fonts.dir files or anything -- Xft will discover the fonts in that directory itself. One of the nice things you can do is to add ~/fonts to the Xft font path in your local ~/.xftconfig file. Then you can drop fonts in that folder and they become usable to all your Xft using applications.
You should probably still run XFS, so that older applications (such as gtk 1.2 based ones, and most Xt ones) that use core X font rendering still work. Note that the reason most distros are set up to use a font server rather than leaving the X server to render the fonts is that it adds a level of parallelism. If the X server was rendering fonts, it would block while doing so. With the font server rendering fonts, the X server is free to do other stuff while waiting for the fonts to be rendered, which can take a while for CJK fonts, for instance.
First of all, you must enable Xft support (the new font system for X). This is done by defining the GDK_USE_XFT environment variable before running a program. The best way to turn this on for the entire desktop is by defining it in the X startup script (probably ~/.gnomerc, ~/.Xclients or ~/.xinitrc):
#!/bin/bash
export GDK_USE_XFT=1
# set up $PATH and $LD_LIBRARY_PATH if needed
exec gnome-session
After doing this, you may still not see antialiased fonts. For instance, on Red Hat systems, the default/etc/X11/XftConfig file has the following lines:
match
any size < 14
any size > 8
edit antialias=false;
which turns off antialiasing for fonts with sizes between 8 and 14. By commenting out these lines, AA will be enabled for all fonts. If you have an LCD panel, add a line like the following to/etx/X11/XftConfig or ~/.xftconfig:
match edit rgba=rgb;
This will turn on ClearType style subpixel antialiasing.
As an example, here is a list of all bugs with the GNOME2 keyword that are in the RESOLVED, VERIFIED or CLOSED state that changed state between the RC1 and RC2 releases. It is not complete, and probably isn't fully accurate (some changes may have been fixed but no new tarball is available yet), but it gives you an idea of what has changed.
If you are using Xft for font rendering (that is, you set the GDK_USE_XFT environment variable to 1), you can turn on cleartype style rendering. If your LCD panel is in RGB order, you can put the following in your ~/.Xdefaults file:
Xft.rgba: rgb
Or equivalently, in your ~/.xftconfig file:
match edit rgba=rgb;
Doom had tripple head support, IIRC. You set up three computers, and ran a network game, telling the other machines to display left and right views for the player.
Slashdot Mirror
Ubuntu makes a fine server OS. What do you think www.ubuntulinux.org is running on? Remember that Ubuntu is basically a branch of Debian, which many people find okay to run on servers.
Securing it in a networked environment is also pretty easy -- the default install doesn't have any services listening on the network, so the only listening services will be the ones you install.
Actually, the "Human" theme that Ubuntu uses as default is based on Industrial (slightly different colours, and square corners on the windows). This may change in the future though.
Not that I know of. Even if there were, it wouldn't help much -- I doubt many search engines understand CSS ...
It is pretty easy to make rel="nofollow" visible to normal users too in modern web browsers using CSS. You could use something like this:
That will display the given image before any links marked as nofollow.
In many cases, a library will require some other support files at runtime. Unlike dynamic linker dependencies, there isn't a reliable way to find out about these requirements. The common way to handle this is to combine the library and support files into a single package that is installed as a single unit (or include a dependency on the package containing those support files).
Now in the case of a small "libsquat.xx.so.3" being part of a large package, if the library doesn't require all the files in the package, and the library is intended for use by other programs a linux distro will usually package the library separately with only the files it requires, and make the larger package depend on the library package. If there are particular instances where this hasn't happened in your distro, perhaps you could try filing a bug.
As for recursive package removal, it is fairly trivial to find all the leaf nodes on the package dependency tree that could be removed without causing an inconsistency, but it isn't easy to tell whether it is safe to remove said packages. Which leaf packages is the user actually using? The user may be using some packages that may have been installed to satisfy dependencies, so you can't just remove packages that weren't explicitly installed by the user.
Lastly, if "fungame" requires libsquat.xx.so.3, then libsquat.xx.so.4 would _not_ satisfy that dependency. If two libraries have different sonames, then they provide different ABIs (they use different filenames so that you can install them in parallel to satisfy the dependencies).
Overall, the features you've brought up are already available in the current generation of package management systems -- you just want finer grained packaging.
Well, the "System Monitor" app matches up application icons to processes in the process list, so the user should be able to work out the name if they need to. However, they shouldn't need to for a few reasons:
Now as for GConf, it is an abstraction for storing and retrieving preferences, and getting notification of changes to preferences. The gconf-editor program is simply a program that uses the GConf API.
I'm not sure why you thought it necessary to use gconf-editor to change your font though. The fonts control panel is pretty easy to find (it is "Font" under the desktop preferences menu). Was there some other basic preference that you were thinking of?
Sure there might be an executable installed as /usr/bin/gcalctool, but it is exposed in the menus simply as "Calculator". The title bar for the calculator also says "Calculator" as opposed to "Gnome Calculator" or "Gcalctool". The "Gcalctool" name is shown in the about dialog, but that is it.
The user doesn't need to care about what the underlying executable name is. This is what the parent post was probably refering to.
Now if Gnome did install executables with names like /usr/bin/calculator, people would complain because it would make it more difficult to integrate into a distribution because of file name conflicts.
On what basis do you think that a mail client should not be included in the Gnome desktop release?
...
A significant portion of users need a mail client, so it makes sense to include one (in the same way that a web browser, and other utilities are included).
Things are still modular, so you don't need to install Evolution. There isn't anything stopping you from integrating another mail client, and distributors can easily change the defaults if they want a different default mail client.
Also, what would be the benefit of included evolution-data-server without Evolution? A calendar and address book backend is not particularly useful without a way to manipulate them
The component of Evolution that handles storage of calendar and address book data has been split off into a separate evolution-data-server module. This is the module that other programs use for calendar and address book integration.
It would also be possible for other mail clients to make use of e-d-s for address book storage, in which case they would also benefit from the desktop integration.
What Jeff meant is that the cracker didn't seem to be targetting Gnome specifically. They'd have just as likely broken into any other vulnerable box.
widget.gnome.org (the machine that was cracked) has been reinstalled. That's part of the reason why things aren't all up again yet.
The script used to upload files to the master FTP site also mailed MD5 sums to a mailing list hosted on another machine. That script doesn't appear to have been altered (to insert a backdoor, the script would need to repack the tarballs with an exploit on the fly), so the MD5 sums from that mailing list should be reliable.
Gnome 2.4 supports .hidden files, just like MacOS X and KDE.
Is slashdot ever going to switch to use the logo that the Gnome project has been using for over a year? Surely people would be more likely to associate the new logo with the project.
Because that is where we decided to hold it. 2002 was in Brisbane, 2001 was in Sydney and CALU was held in Melbourne. It will be somewhere else next year.
:)
Many Western Australians would have had the same reason for not going to previous conferences, so holding the odd conference over here is a good idea.
It is too bad you can't make it though, because it is going to be a great conference
There is support for the RandR extension in the latest releases of gtk+ (including the version in the beta). I don't know if any apps have been modified to use it though. Probably the only ones that need to care about screen size changinges are the window manager (metacity), the panel and nautilus.
Note that the 0.2 release of fontilus is the second release. There are a number of areas where I can improve and extend it.
Setting it up so that you can configure where fonts are placed when performing DnD font installation is a fairly simple imrpovement.
The GNOME Foundation is not a money laundering operation, like you seem to be implying.
The major way companies like Sun, Ximian and Red Hat help is by employing people to work on GNOME. They don't get a tax deduction for hiring people to work on GNOME.
The GNOME Foundation does not employ any developers (it has one employee: Tim Ney, the executive director, who does a lot of the organisational work). You can find details of what the Foundation does at foundation.gnome.org/.
If you think the main reason most people work on GNOME is to help big business, then you are mistaken. It certainly hasn't been the motivation for my contributions, which started before Sun started working on GNOME, and before any Linux distro was including GNOME (let alone as its default desktop).
On the subject of tax deductability, the GNOME Foundation meets the criteria for section 501(c)(3) (the foundation's work is of public benefit). If you don't feel that it should have tax exempt status, then you should campaign against the law.
You make it sound like the foundation is trying to trick people in to donating. We are being quite open about what the money will be used for, so each person who considers donating can make an informed choice.
I probably wouldn't call the GNOME Foundation as a charity either. However, it is a non profit organisation as recognised by US law (I suppose charities are a subset of non-profits).
If you would prefer to give your spare income to another charity/non-profit, that is your choice. We are being upfront about what the money will be used for.
If you feel that a donation to the GNOME foundation does not deserve a tax deduction (ie. you would prefer to pay tax on the contribution), feel free to not declare the donation.
Xft can handle Type1, TTF and OpenType fonts (and in the version included in CVS XFree86, bitmap PCF fonts as well). Simply add a "dir" line to the XftConfig file for each font directory. No need to create fonts.dir files or anything -- Xft will discover the fonts in that directory itself. One of the nice things you can do is to add ~/fonts to the Xft font path in your local ~/.xftconfig file. Then you can drop fonts in that folder and they become usable to all your Xft using applications.
You should probably still run XFS, so that older applications (such as gtk 1.2 based ones, and most Xt ones) that use core X font rendering still work. Note that the reason most distros are set up to use a font server rather than leaving the X server to render the fonts is that it adds a level of parallelism. If the X server was rendering fonts, it would block while doing so. With the font server rendering fonts, the X server is free to do other stuff while waiting for the fonts to be rendered, which can take a while for CJK fonts, for instance.
First of all, you must enable Xft support (the new font system for X). This is done by defining the GDK_USE_XFT environment variable before running a program. The best way to turn this on for the entire desktop is by defining it in the X startup script (probably ~/.gnomerc, ~/.Xclients or ~/.xinitrc):
After doing this, you may still not see antialiased fonts. For instance, on Red Hat systems, the default /etc/X11/XftConfig file has the following lines:
which turns off antialiasing for fonts with sizes between 8 and 14. By commenting out these lines, AA will be enabled for all fonts. If you have an LCD panel, add a line like the following to /etx/X11/XftConfig or ~/.xftconfig:
This will turn on ClearType style subpixel antialiasing.
You can use bugzilla to find this information.
As an example, here is a list of all bugs with the GNOME2 keyword that are in the RESOLVED, VERIFIED or CLOSED state that changed state between the RC1 and RC2 releases. It is not complete, and probably isn't fully accurate (some changes may have been fixed but no new tarball is available yet), but it gives you an idea of what has changed.
If you are using Xft for font rendering (that is, you set the GDK_USE_XFT environment variable to 1), you can turn on cleartype style rendering. If your LCD panel is in RGB order, you can put the following in your ~/.Xdefaults file:
Xft.rgba: rgb
Or equivalently, in your ~/.xftconfig file:
match edit rgba=rgb;
Doom had tripple head support, IIRC. You set up three computers, and ran a network game, telling the other machines to display left and right views for the player.