I use RHEL4 compatible distro called Scientific Linux CERN 4 (SLC4) on my laptop. I need it to run some CERN software (mainly Geant4 and ROOT). These packages mostly work on other systems as well but they work best on SLC4 because they have been thoroughly tested on this platform. On other (newer) distros expecially new GCC4 compiler causes some annoying problems. I really like many things in this distro: stability (both as in "doesn't crash" and "doesn't change insert-name-of-software-package-here version unexpectedly", upgrades generally don't break anything, graphical installation/administration tools are great, etc. etc. etc... There is only one problem: lack of software packages. There is no good way to install new versions of some graphical apps. This is not exclusively Red Hat problem. It exists on all Linux platforms. The problem is that software developers have "works-for-me" attitude: "If I have the latest distro probably everyone else has it too." So they code apps using the latest versions of libraries. Since I use this software on my laptop (which is my primary computer right now) I need both stability of RHEL4 and preferably new desktop software (because new software offers generally better features and usability).
I'm annoyed by this situation because I can't install new tools when I need/want them. This is very inflexible (imagine that: I'm blaming Linux for inflexibility...) The only solution to this problem seems to be virtualization. RHEL 4.5 update (and probably SLC 4.5 as well) is going to have Xen domU support. Maybe it will be then painless to move, say to Fedora 7 or RHEL5 based SLC5 and run SLC4 using virtualization... One can only hope...
Ports and packages are essentially one single system: packages are built from ports. You can do this yourself by going to directory/usr/ports/blahblah/port-version and issuing command: make package. You can use pkg_add -r to install readily available binary packages via FTP. And of course you can also use portinstall and portupgrade to install binary packages (options: -PP install only binary packages, -P install binary if available otherwise build from source)
If you prefer strictly binary packaing system you might want to try OpenBSD. Their ports and packaging tools are actually much more advanced than FreeBSD's (better dependency checking, pkg_add allowing binary updates etc.). The only problem with OpenBSD is that there is not as much software available for it as there is for FreeBSD and Linux.
One good tool for doing large scale data analysis is ROOT which has been developed at CERN. ROOT contains facilities for storing, analyzing and visualizing very large data sets fairly quickly. Online User's Guide contains a nice overview of the ROOT system.
Let's not forget their wonderful documentation! Complete and accurate API documentation is absolutely necessary for writing secure and reliable software. And of course the programmers should actually read the documentation and check all the details of the API calls they are using (return values, etc...)!
Or the coders should really try to learn how to use C/C++ and whatever APIs (libraries) they are using correctly...
Oh, and the people who code the libraries and stuff like that should design, implement and document their APIs properly so that the coders using those libraries actually have complete and accurate documentation available!
I think you have to run Ooo in Linux emulation mode (add kern.emul.linux=1 to/etc/sysctl.conf and pkg_add relevant packages (see OpenBSD FAQ)). This is absolutely the best (and only) way to run Ooo in OBSD for now...
One problem is that Ooo contains lots of bugs, especially those related to memory handling. These bugs cause problems with e.g. OpenBSD's new malloc(3) call. Some porting and bugfixing work has actually been done by some OpenBSD developers but as far as I know that particular port is nowhere near production quality. Apparently more developers/coders/testing guinea pigs (with proper bug reporting skills) are needed. Some information about the OpenBSD port of Ooo is available in this presentation.
They are using Halo 2 to make more users switch to Vista (and to upgrade hardware). I expect more and more games and other apps are going to be for Vista only.
I'm glad I was able to explain at least something clearly. Maybe there is hope for me yet...
It indeed seems that the CMS home page is written for physicists or physics students. It basically tells nothing a non-physicist or non-engineer would like to know. This is quite sad.
The purpose of these experiments and the importance of the results to our understanding of the universe is indeed important to explain... Not only because it might be good for also non-physicists to know something about these things but also because (if told correctly) it is a very intriguing and nice story, that is, very good PR! We foolish physicists are wasting an excellent tool that could be used to increase the public awareness and interest in basic research. And naturally the politicians making decisions about funding are mostly non-physicists too...
Well, I am a physicist and here is some additional information (hopefully not bad PR):
LHC is the biggest and most powerful particle collider ever built. It is a proton-proton collider that collides proton beams together with 14 TeV (tera electronvolts) center-of-mass energy (if memory serves).
CMS (= compact muon solenoid) is actually quite big detector. Its main purpose is to find the so called Higgs boson. The existense of the Higgs boson is required by the Standard Model of particle physics (one good book on the basics of particle physics (for people who already understand quite a bit of physics and math) is: Francis Halzen, Alan D. Martin: Quarks and Leptons: An Introductory Course in Modern Particle Physics). CMS, as most other particle physics experiments has an onion-like structure. The innermost layer is called a tracker which is used to (surprise, surprise) find the tracks of the particles produced in the collision. There is also a magnetic field in the tracker so the curvature of the particle tracks can be used to determine their momenta. The next layers are called electromagnetic and hadronic calorimeters. These are used to measure the energies of the particles. And finally there are the muon chambers that are used to detect the muons (muon is like an electron but only heavier).
There are also other big detectors in the LHC experiment like e.g. ATLAS.
One good source of information on particle physics are CERN summer student lectures available in Real-media format.
Have a look at ROOT. It is an object oriented data analysis framework with a C++ interpreter. It provides you with very powerful tools for doing all kinds of plotting (histograms and stuff), doing fits to data and storing data (so called ROOT files), etc... In addition to that it is free software (the latest version is licensed under the LGPL). It may not seem as easy to use as Matlab, but in the end I think ROOT is a lot more powerful.
On the other hand most secretaries and people like that would not find writing C++ scripts all that fun...
I have never tried running Gnome, KDE or XFCE on any of my alphas. I have two: AlphaStation 500/266 (266 Mhz EV5 (21164), 256MB RAM) and AlphaServer 2000 5/250 (one 250 Mhz EV5, 256MB RAM). The AlphaStation runs NetBSD (no GUI because the graphics card DEC ZLXP-L1 (a huge OpenGL card with 16MB memory) is nowadays only supported by OpenVMS) and the AlphaServer runs real Digital Unix (Tru64 5.1). I have a DU base license (for the AlphaServer, the licenses are tied to the hardware) that is needed to use the thing so I can run real CDE!
Maybe the desktop interface of the future should look like the NeXT UI. Although Gnome has "assimilated" many features from MacOS it would be nice to see also some features of the NeXT system in Gnome. These features include things like NeXT menu system and "spatial interface" (meaning that the windows and tear-off menus stay where the user puts them). Especially lack of the latter feature is a constant annoyance in almost all interfaces.
I think so called object oriented traditional desktop is the best one (at least the best one we can build within the next 10-20 years). The things I expect from desktop UI are simplicity, clean design and "things just work" attitude (no need to configure/adjust dozens of things to make the environment usable). The current Gnome gets many of these things (at least almost) right.
And don't forget WindowMaker + GNUstep combo. If only there were some more apps (e.g. web browser) written using the GNUstep framework it would actually be a very interesting environment to work with. While both Gnome and KDE are nowadays quite good systems I think their developers should learn a few things from GNUstep (or actually OpenStep) GUI (e.g. document based apps, insanely powerful menu system, clean dialogs (Gnome actually already does these almost correctly), windows (and tear-off menus) stay where you put them, etc etc etc).
I totally agree. If I had any mod points I would mod you up.
Re:I'll stick with OpenBSD and Trusted Solaris.
on
Hardening Linux
·
· Score: 3, Insightful
Package management (ports collection) has really been improved in OpenBSD 3.7 and 3.8. Here is one interview with an OpenBSD ports developer. It seems to me that OpenBSD developers actually recommend that users should install binary packages (from the interview: "Most people should only see the binary packages and pkg_add"). One quite nice thing about these OpenBSD ports tree compared to FreeBSD ports is that the OpenBSD ports tree is frozen so you actually get something like Debian stable style system where only maintenance updates are "backported" from ports-current to, say, ports-3.8 branch.
OpenBSD ports/packages system unfortunately does not have automatic update like "apt-get upgrade". You have to know the package names and versions to upgrade them. pkg_add actually has -u switch but it only lists the package names. However a proper automatic update fuctionality is already in CURRENT. From the OpenBSD-CURRENT pkg_add(1) man page:
-u Update the given pkgname(s), and anything it depends upon. With
this option, if no pkgname is given, pkg_add will update all in-
stalled packages. This relies on PKG_PATH to figure out the new
package names.
So this probably means that 3.9 (released in about 6 months) is going to have a real package upgrading system.
Slashdot Mirror
I use RHEL4 compatible distro called Scientific Linux CERN 4 (SLC4) on my laptop. I need it to run some CERN software (mainly Geant4 and ROOT). These packages mostly work on other systems as well but they work best on SLC4 because they have been thoroughly tested on this platform. On other (newer) distros expecially new GCC4 compiler causes some annoying problems. I really like many things in this distro: stability (both as in "doesn't crash" and "doesn't change insert-name-of-software-package-here version unexpectedly", upgrades generally don't break anything, graphical installation/administration tools are great, etc. etc. etc... There is only one problem: lack of software packages. There is no good way to install new versions of some graphical apps. This is not exclusively Red Hat problem. It exists on all Linux platforms. The problem is that software developers have "works-for-me" attitude: "If I have the latest distro probably everyone else has it too." So they code apps using the latest versions of libraries. Since I use this software on my laptop (which is my primary computer right now) I need both stability of RHEL4 and preferably new desktop software (because new software offers generally better features and usability).
I'm annoyed by this situation because I can't install new tools when I need/want them. This is very inflexible (imagine that: I'm blaming Linux for inflexibility...) The only solution to this problem seems to be virtualization. RHEL 4.5 update (and probably SLC 4.5 as well) is going to have Xen domU support. Maybe it will be then painless to move, say to Fedora 7 or RHEL5 based SLC5 and run SLC4 using virtualization... One can only hope...
Ports and packages are essentially one single system: packages are built from ports. You can do this yourself by going to directory /usr/ports/blahblah/port-version and issuing command: make package. You can use pkg_add -r to install readily available binary packages via FTP. And of course you can also use portinstall and portupgrade to install binary packages (options: -PP install only binary packages, -P install binary if available otherwise build from source)
If you prefer strictly binary packaing system you might want to try OpenBSD. Their ports and packaging tools are actually much more advanced than FreeBSD's (better dependency checking, pkg_add allowing binary updates etc.). The only problem with OpenBSD is that there is not as much software available for it as there is for FreeBSD and Linux.
One good tool for doing large scale data analysis is ROOT which has been developed at CERN. ROOT contains facilities for storing, analyzing and visualizing very large data sets fairly quickly. Online User's Guide contains a nice overview of the ROOT system.
Let's not forget their wonderful documentation! Complete and accurate API documentation is absolutely necessary for writing secure and reliable software. And of course the programmers should actually read the documentation and check all the details of the API calls they are using (return values, etc...)!
Or the coders should really try to learn how to use C/C++ and whatever APIs (libraries) they are using correctly...
Oh, and the people who code the libraries and stuff like that should design, implement and document their APIs properly so that the coders using those libraries actually have complete and accurate documentation available!
I think ATI control center is written using .Net framework. It is basically the same as if they had written it using Java...
John Dvorak confirms it: Microsoft is dying.
Yeah, right. But a guy can hope...
I think you have to run Ooo in Linux emulation mode (add kern.emul.linux=1 to /etc/sysctl.conf and pkg_add relevant packages (see OpenBSD FAQ)). This is absolutely the best (and only) way to run Ooo in OBSD for now...
One problem is that Ooo contains lots of bugs, especially those related to memory handling. These bugs cause problems with e.g. OpenBSD's new malloc(3) call. Some porting and bugfixing work has actually been done by some OpenBSD developers but as far as I know that particular port is nowhere near production quality. Apparently more developers/coders/testing guinea pigs (with proper bug reporting skills) are needed. Some information about the OpenBSD port of Ooo is available in this presentation.
Maybe it is just time to switch to FreeBSD.
Oh but they use GCC... Does that mean it is actually GNU/Free(as in freedom)BSD?
They are using Halo 2 to make more users switch to Vista (and to upgrade hardware). I expect more and more games and other apps are going to be for Vista only.
You have an excellent sig btw...
You did fine. ;)
I'm glad I was able to explain at least something clearly. Maybe there is hope for me yet...
It indeed seems that the CMS home page is written for physicists or physics students. It basically tells nothing a non-physicist or non-engineer would like to know. This is quite sad.
The CERN public pages seem to be more newbie-friendly.
The purpose of these experiments and the importance of the results to our understanding of the universe is indeed important to explain... Not only because it might be good for also non-physicists to know something about these things but also because (if told correctly) it is a very intriguing and nice story, that is, very good PR! We foolish physicists are wasting an excellent tool that could be used to increase the public awareness and interest in basic research. And naturally the politicians making decisions about funding are mostly non-physicists too...
Well, I am a physicist and here is some additional information (hopefully not bad PR):
LHC is the biggest and most powerful particle collider ever built. It is a proton-proton collider that collides proton beams together with 14 TeV (tera electronvolts) center-of-mass energy (if memory serves).
CMS (= compact muon solenoid) is actually quite big detector. Its main purpose is to find the so called Higgs boson. The existense of the Higgs boson is required by the Standard Model of particle physics (one good book on the basics of particle physics (for people who already understand quite a bit of physics and math) is: Francis Halzen, Alan D. Martin: Quarks and Leptons: An Introductory Course in Modern Particle Physics). CMS, as most other particle physics experiments has an onion-like structure. The innermost layer is called a tracker which is used to (surprise, surprise) find the tracks of the particles produced in the collision. There is also a magnetic field in the tracker so the curvature of the particle tracks can be used to determine their momenta. The next layers are called electromagnetic and hadronic calorimeters. These are used to measure the energies of the particles. And finally there are the muon chambers that are used to detect the muons (muon is like an electron but only heavier).
There are also other big detectors in the LHC experiment like e.g. ATLAS.
One good source of information on particle physics are CERN summer student lectures available in Real-media format.
And then you are going to fucking bury them.
I don't think there is any kind of WoW replacement. Obviously we need to develop massively multiplayer version of Nethack...
Have a look at ROOT. It is an object oriented data analysis framework with a C++ interpreter. It provides you with very powerful tools for doing all kinds of plotting (histograms and stuff), doing fits to data and storing data (so called ROOT files), etc... In addition to that it is free software (the latest version is licensed under the LGPL). It may not seem as easy to use as Matlab, but in the end I think ROOT is a lot more powerful.
On the other hand most secretaries and people like that would not find writing C++ scripts all that fun...
Obviously the next big thing will be based on punch card techology!
do you really want your representative to be a soulless reptilian creature of infinite evil?
YES!!! No wait... I want to be this soulless creature of infinite 3V1L... (let's leave out that reptilian part)
I have never tried running Gnome, KDE or XFCE on any of my alphas. I have two: AlphaStation 500/266 (266 Mhz EV5 (21164), 256MB RAM) and AlphaServer 2000 5/250 (one 250 Mhz EV5, 256MB RAM). The AlphaStation runs NetBSD (no GUI because the graphics card DEC ZLXP-L1 (a huge OpenGL card with 16MB memory) is nowadays only supported by OpenVMS) and the AlphaServer runs real Digital Unix (Tru64 5.1). I have a DU base license (for the AlphaServer, the licenses are tied to the hardware) that is needed to use the thing so I can run real CDE!
Maybe the desktop interface of the future should look like the NeXT UI. Although Gnome has "assimilated" many features from MacOS it would be nice to see also some features of the NeXT system in Gnome. These features include things like NeXT menu system and "spatial interface" (meaning that the windows and tear-off menus stay where the user puts them). Especially lack of the latter feature is a constant annoyance in almost all interfaces.
I think so called object oriented traditional desktop is the best one (at least the best one we can build within the next 10-20 years). The things I expect from desktop UI are simplicity, clean design and "things just work" attitude (no need to configure/adjust dozens of things to make the environment usable). The current Gnome gets many of these things (at least almost) right.
If memory serves XFCE was a few years back quite similar to CDE. I think you can configure the latest version (at least the panel) to work like CDE.
I used CDE on my DEC Alpha machine quite a lot. That old desktop was indeed surprisingly simple and efficient UI (although maybe a little bit ugly).
And don't forget WindowMaker + GNUstep combo. If only there were some more apps (e.g. web browser) written using the GNUstep framework it would actually be a very interesting environment to work with. While both Gnome and KDE are nowadays quite good systems I think their developers should learn a few things from GNUstep (or actually OpenStep) GUI (e.g. document based apps, insanely powerful menu system, clean dialogs (Gnome actually already does these almost correctly), windows (and tear-off menus) stay where you put them, etc etc etc).
Why not just drink real coffee? I mean something like ristretto. Yum yum.
One thing that should be noted though: Gtk+ and OSX actually have very similar button ordering...
I totally agree. If I had any mod points I would mod you up.
Package management (ports collection) has really been improved in OpenBSD 3.7 and 3.8. Here is one interview with an OpenBSD ports developer. It seems to me that OpenBSD developers actually recommend that users should install binary packages (from the interview: "Most people should only see the binary packages and pkg_add"). One quite nice thing about these OpenBSD ports tree compared to FreeBSD ports is that the OpenBSD ports tree is frozen so you actually get something like Debian stable style system where only maintenance updates are "backported" from ports-current to, say, ports-3.8 branch.
OpenBSD ports/packages system unfortunately does not have automatic update like "apt-get upgrade". You have to know the package names and versions to upgrade them. pkg_add actually has -u switch but it only lists the package names. However a proper automatic update fuctionality is already in CURRENT. From the OpenBSD-CURRENT pkg_add(1) man page:
-u Update the given pkgname(s), and anything it depends upon. With this option, if no pkgname is given, pkg_add will update all in- stalled packages. This relies on PKG_PATH to figure out the new package names.
So this probably means that 3.9 (released in about 6 months) is going to have a real package upgrading system.