The thing is, there's nothing particularly to recommend Red Hat. It's an okay GNU/Linux distribution, but so are Debian, Slackware and Mandrake. The main reason to use Red Hat used to be that it was the most popular. If you wanted to make your application available to the largest number of users, or take advantage of applications others had packaged, it was slightly easier to use Red Hat than another distribution. It usually made sense to follow Red Hat's conventions for file locations and GUI standards. If you don't have a strong reason to choose otherwise, go with the de facto market leader.
But now, Red Hat is just one distribution out of many, not necessarily the best, and certainly one of the most expensive. Fedora is okay, but it no longer has the magic touch of being _the_ distribution most commonly supported, from the desktop right up to high-end servers. It too is just another distro.
So while I might have paid $179 for Red Hat back when it was freely downloadable and popular, now that it costs $179 it is no longer worth the money.
Seriously, as an Apple user, I'm glad to see a Linux desktop system copying the MacOS instead of Windows.
Yes, I am glad too, but in this case the project was inspired by RISC OS rather than Mac OS X - they both use a similar system of application directories. I am not sure which came first of RISC OS and NeXT.
Really, I'm glad to copy features from any operating system except Windows (although there must be a few things Windows gets right). It's just a shame that it has to be a small project picking up these ideas, rather than KDE or GNOME.
I like the idea of this, having used the same system on RISC OS - and I really miss being able to install something simply by copying it. It is also neat to have a cache from which things can be deleted at any time and refetched; the only problem is that every app needs to run a quick zero-install-check before it starts to make sure the libs are there.
Package systems like apt and rpm take a stricter approach: if you have the app, then you must need the libraries it depends on. If you remove the libraries then the app would be broken so you ought to remove it too. But you do have to use a special 'remove' operation to uninstall, rather than just deleting.
I would like to see Zero Install get integration with conventional rpm or deb packages, so that the package is fetched off the net and installed into its own directory, and then can be used (as a library or whatever) by Zero Install apps. In other words, a way to automatically wrap legacy packaging formats (and I do not mean the word legacy unkindly). Inventing another package format is doomed; a new easier way of managing the packages that hundreds of people are already building could take off.
With Novell's announcement that YaST is to be distributed under the GPL, is this new SuSE release free, or are there remaining esential non-free parts? (Junk like Acrobat Reader, etc. doesn't count, as long as it is simple to choose not to install it.)
Of course it is possible for the terminal emulator to take C-c as copy and C-v as paste, but personally I would find it damn annoying because those keystrokes are often used by the application. The annoyance of having to use the mouse for cut and paste is smaller.
This is a matter of personal preference, all I can say is that the Putty developers have the same preferences as the Windows command window developers and many other people.
For maintaining an individual machine there may not be much difference in maintainability; the advantage of packages comes when you have several machines to keep in sync. You can easily query the installed packages, perform upgrades according to a centralized configuration, and verify that none of the installed files have been corrupted. With GPG package signing, you can have a reasonably secure mechanism for pushing out only software that you have approved (better than relying on NFS and file permissions).
If you build from source it is very unlikely that you'd build separately on each target machine. You'd build once and then push out the binaries. Package systems give you a few more tools to manage and automate this process.
As others have mentioned, you can make your own source packages and build those, giving the best of both worlds.
You don't want to write a spec file; I could equally argue that I don't have time to write a setup.exe program. Neither argument really applies; there are tools to make a setup.exe so you don't have to write your own, and there are tools to create spec files. Perhaps it would be better to have a pretty GUI to make the spec file rather than writing it in an editor.
I find it hard to believe that the effort involved to learn how to write an rpm spec file (quite simple) is less than that in learning how to use a new GUI package builder such as Installshield. Especially when you factor in the extra effort to install the package automatically on Windows machines and keep it updated. (And yes, I have done these three things.)
On many Linux distributions you can double-click on an RPM package to bring up a GUI package manager; once the program is installed it automatically appears in the main 'start menu' if the package has the necessary menu item incantations.
Requiring root is a good point: in my opinion it is not nearly easy enough to install an RPM in your home directory rather than centrally.
the installer *has* to be a standalone program unless the os itself has a single installation methodology ( such as the msi of windows ).
It does have a single installation method: RPM. For peculiar systems that don't allow to install using RPM (although it is required by the Linux Standard Base) you could make some disgusting shell script to unpack the package using rpm2cpio, or to install first rpm and then the package.
Setup.exe is broken because there's no way to inspect what files a package will install on your system short of running it; no mechanism for code signing and verification (like rpm --checksig); no uniform way to query what packages are installed or to handle dependencies between packages (which can lead either to DLL hell or to kitchen-sinkness and multiple copies of every library); no way to look at a file on the system and say 'what is this, what package did it come from?'; often no way to cleanly and completely uninstall a package. The new MSI packages are much better.
I am thinking more about managing installation on a network of 100 or 1000 machines, rather than grandma wanting to install a single app on her own PC. In many large-scale Windows setups packages can be added and removed only at boot time, and in all cases it is rather a pain to manage them. RPM has its problems but it is bliss by comparison.
On Linux, I am yet to find a free alternative as intuitive as Inno Setup or alike.
% apt-get install my-weird-package
Make an RPM of your program, upload it to an apt repository (or create a local repository), and then people can easily install it with synaptic or other GUI tools, including all dependencies. Yes, you may need two slightly different RPMs for two distributions, but this is not a big deal.
The Windows setup.exe model is somewhat broken, trying to imitate it on Linux is the wrong way to go.
The definition of collision-resistent is that you cannot find ANY inputs x,y st x!=y and H(x) == H(y). None. No exceptions.
In other words, that the function H is injective. But no message digest function producing a fixed-length digest from an arbitrary-length input can have such a property.
Lets say I could easily generate MD5 collisions on 'random-looking' 128-bit strings... Would MD5 be considerd broken?
It depends on how you were doing it 'easily'... if you simply had a great deal of brute force to apply, then you could apply the same brute force to SHA-1 or any other message digest function. Only if you have some way of finding collisions which is better than brute force would this be a weakness in the digest function. (Of course, one can imagine a trivially weak message digest that has only 'A' and 'B' as possible outputs; for that algorithm even a brute force attack is easy enough to worry about, but this isn't the case for MD5 as far as I can tell.)
Looking at the method MD5CRK will be using, it seems they'll just be brute-forcing MD5 by running it in a feedback loop to find a cycle (which must exist). As they say, this could be applied to any function which has finite range and domain (assuming that there is some reasonable mapping from domain back to range: in this case, they can both be treated as strings). Exactly the same technique could be applied to SHA-1. Do they simply mean that SHA-1 has a larger range of output values, so its cycles are probably longer and harder to find?
We aim to disprove one of the fundamental requirements of a secure message digest: No two inputs can be found which produce the same digest - this is also known as a collision.
That is bullshit. Of course two inputs can be found which produce the same message digest. This is the pigeonhole principle. Now the MD5CRK developers seem like smart people, and so it's more likely that they just haven't explained it very well.
They go on to say
To raise awareness we will find at least two strings of printable text that produce an identical MD5 hash.
But I don't see what that would achieve either: two strings of gibberish that happen to have the same MD5 sum. Find a way to produce two documents which both have meaning (perhaps two pieces of source code, or two different school reports) and have the same signature, and that would be impressive.
Exactly the same problem applies: how on earth am I supposed to trust the 'attested' server code, given that those running the server can get control over their own hardware? Perhaps the hardware is supposed to be tamper-proof, but do you want to trust that with your money?
If I said to you 'my gambling program is on the level, and look, here is a certificate from Microsoft to prove it', would you trust that? No thanks.
Surely the valid key can come from a trusted PC you bought earlier. You just need to dump the BIOS image to disk, run it under Bochs, and do whatever fiddling you want.
It's a fair cop. I did RTFA but _after_ posting my comment. Got to get in early...
That's the whole idea of trusted computing (amongst other things), is allowing a trusted remote service to know full well that the computer its talking to is on the level. It's based in hardware, and is drenched in encryption and intelligent process control.
It's been a while since I read up on TC, and that was only from doommongering sites mentioned on Slashdot, but I just don't understand this. If you have control of the hardware, then you can fake up any response to say that your computer is 'on the level'. Ordinary users may not be able to open the lid of their computer (metaphorically speaking) and bypass the TC restrictions, but the bad guys certainly will. What is to stop one from running a 'trusted' operating system inside a simulator such as Bochs, for example? With deus ex machina powers you could bypass any checking built into the OS or BIOS. Ultimately, if you control the hardware you can program a computer to do what you want; this has always been true and I don't see how TC can change it.
Applications like online casinos would also benefit from a magical honesty pill which users could take to prevent them from cheating - but it's not going to happen. The idea of trusted computing is to require a specially restricted client machine, but there's no way this could work and be secure enough for something like online gambling. An important rule of online security is *you cannot trust the client*, and even if the standard Dell PC that grandma buys is locked down with all sorts of nastyware, this will do nothing against a determined attacker who is able to program a computer to do what its he, its owner, wants.
Although trusted computing could never provide real security, it can give a lot of inconvenience to 90% of the population to stop them doing things with their computer that Microsoft would prefer them not to do. Just like other copy-protection measures over the years, its purpose is to keep the majority of users under control, not to stop the real criminals.
It's surprising how many vulnerabilities are found in Ethereal - this report is certainly not the first. And they tend to be root vulnerabilities.
Really, it's amazing that software like Ethereal, intended as a security tool, wasn't written with a bit more care and attention to avoid buffer overflows and similar causes of exploits. Normally one would expect something that needs to run as root and accept arbitrary data from the network interface to be written with extra caution and paranoia.
I think the most important lesson is in how to filter things. Do not have a list of 'bad' content and remove that, because there might always be something you hadn't thought of ( in this case). Instead define what you will allow, and block everything else. Yahoo and Hotmail need to start with the HTML DTD, decide which elements and attributes are considered safe, and write a program to chomp through documents letting only those things through.
That won't protect you if Microsoft decide to give a non-standard and moronic meaning to some existing HTML feature, but it will protect 100% against newly introduced stupid elements and XML weirdy things.
Slashdot Mirror
The thing is, there's nothing particularly to recommend Red Hat. It's an okay GNU/Linux distribution, but so are Debian, Slackware and Mandrake. The main reason to use Red Hat used to be that it was the most popular. If you wanted to make your application available to the largest number of users, or take advantage of applications others had packaged, it was slightly easier to use Red Hat than another distribution. It usually made sense to follow Red Hat's conventions for file locations and GUI standards. If you don't have a strong reason to choose otherwise, go with the de facto market leader.
But now, Red Hat is just one distribution out of many, not necessarily the best, and certainly one of the most expensive. Fedora is okay, but it no longer has the magic touch of being _the_ distribution most commonly supported, from the desktop right up to high-end servers. It too is just another distro.
So while I might have paid $179 for Red Hat back when it was freely downloadable and popular, now that it costs $179 it is no longer worth the money.
Yes, I am glad too, but in this case the project was inspired by RISC OS rather than Mac OS X - they both use a similar system of application directories. I am not sure which came first of RISC OS and NeXT.
Really, I'm glad to copy features from any operating system except Windows (although there must be a few things Windows gets right). It's just a shame that it has to be a small project picking up these ideas, rather than KDE or GNOME.
I meant 'packaging systems like dpkg and rpm' - of course apt is a tool that helps download and manage packages for either of these two systems.
I like the idea of this, having used the same system on RISC OS - and I really miss being able to install something simply by copying it. It is also neat to have a cache from which things can be deleted at any time and refetched; the only problem is that every app needs to run a quick zero-install-check before it starts to make sure the libs are there.
Package systems like apt and rpm take a stricter approach: if you have the app, then you must need the libraries it depends on. If you remove the libraries then the app would be broken so you ought to remove it too. But you do have to use a special 'remove' operation to uninstall, rather than just deleting.
I would like to see Zero Install get integration with conventional rpm or deb packages, so that the package is fetched off the net and installed into its own directory, and then can be used (as a library or whatever) by Zero Install apps. In other words, a way to automatically wrap legacy packaging formats (and I do not mean the word legacy unkindly). Inventing another package format is doomed; a new easier way of managing the packages that hundreds of people are already building could take off.
With Novell's announcement that YaST is to be distributed under the GPL, is this new SuSE release free, or are there remaining esential non-free parts? (Junk like Acrobat Reader, etc. doesn't count, as long as it is simple to choose not to install it.)
Of course it is possible for the terminal emulator to take C-c as copy and C-v as paste, but personally I would find it damn annoying because those keystrokes are often used by the application. The annoyance of having to use the mouse for cut and paste is smaller.
This is a matter of personal preference, all I can say is that the Putty developers have the same preferences as the Windows command window developers and many other people.
No, you can configure Putty either for X-style cut and paste or Windows-style (like the command prompt window).
It can't use C-c and C-v, and neither can Microsoft's own command prompt window, because those keystrokes might be used by the application.
Will it run Linux?
For maintaining an individual machine there may not be much difference in maintainability; the advantage of packages comes when you have several machines to keep in sync. You can easily query the installed packages, perform upgrades according to a centralized configuration, and verify that none of the installed files have been corrupted. With GPG package signing, you can have a reasonably secure mechanism for pushing out only software that you have approved (better than relying on NFS and file permissions).
If you build from source it is very unlikely that you'd build separately on each target machine. You'd build once and then push out the binaries. Package systems give you a few more tools to manage and automate this process.
As others have mentioned, you can make your own source packages and build those, giving the best of both worlds.
The grammar checker in MS Word is moronic, the first thing I do is turn it off. Maybe in Office XP it's a bit better.
You don't want to write a spec file; I could equally argue that I don't have time to write a setup.exe program. Neither argument really applies; there are tools to make a setup.exe so you don't have to write your own, and there are tools to create spec files. Perhaps it would be better to have a pretty GUI to make the spec file rather than writing it in an editor.
I find it hard to believe that the effort involved to learn how to write an rpm spec file (quite simple) is less than that in learning how to use a new GUI package builder such as Installshield. Especially when you factor in the extra effort to install the package automatically on Windows machines and keep it updated. (And yes, I have done these three things.)
On many Linux distributions you can double-click on an RPM package to bring up a GUI package manager; once the program is installed it automatically appears in the main 'start menu' if the package has the necessary menu item incantations.
Requiring root is a good point: in my opinion it is not nearly easy enough to install an RPM in your home directory rather than centrally.
It does have a single installation method: RPM. For peculiar systems that don't allow to install using RPM (although it is required by the Linux Standard Base) you could make some disgusting shell script to unpack the package using rpm2cpio, or to install first rpm and then the package.
Setup.exe is broken because there's no way to inspect what files a package will install on your system short of running it; no mechanism for code signing and verification (like rpm --checksig); no uniform way to query what packages are installed or to handle dependencies between packages (which can lead either to DLL hell or to kitchen-sinkness and multiple copies of every library); no way to look at a file on the system and say 'what is this, what package did it come from?'; often no way to cleanly and completely uninstall a package. The new MSI packages are much better.
I am thinking more about managing installation on a network of 100 or 1000 machines, rather than grandma wanting to install a single app on her own PC. In many large-scale Windows setups packages can be added and removed only at boot time, and in all cases it is rather a pain to manage them. RPM has its problems but it is bliss by comparison.
It is already possible to do prototype-based programming in Python. Also in Perl. But the syntax may be a little awkward.
'It's the wrong trousers Gromit, and they've gone wrong!'
Make an RPM of your program, upload it to an apt repository (or create a local repository), and then people can easily install it with synaptic or other GUI tools, including all dependencies. Yes, you may need two slightly different RPMs for two distributions, but this is not a big deal.
The Windows setup.exe model is somewhat broken, trying to imitate it on Linux is the wrong way to go.
It depends on how you were doing it 'easily'... if you simply had a great deal of brute force to apply, then you could apply the same brute force to SHA-1 or any other message digest function. Only if you have some way of finding collisions which is better than brute force would this be a weakness in the digest function. (Of course, one can imagine a trivially weak message digest that has only 'A' and 'B' as possible outputs; for that algorithm even a brute force attack is easy enough to worry about, but this isn't the case for MD5 as far as I can tell.)
Looking at the method MD5CRK will be using, it seems they'll just be brute-forcing MD5 by running it in a feedback loop to find a cycle (which must exist). As they say, this could be applied to any function which has finite range and domain (assuming that there is some reasonable mapping from domain back to range: in this case, they can both be treated as strings). Exactly the same technique could be applied to SHA-1. Do they simply mean that SHA-1 has a larger range of output values, so its cycles are probably longer and harder to find?
That is bullshit. Of course two inputs can be found which produce the same message digest. This is the pigeonhole principle. Now the MD5CRK developers seem like smart people, and so it's more likely that they just haven't explained it very well.
They go on to say
But I don't see what that would achieve either: two strings of gibberish that happen to have the same MD5 sum. Find a way to produce two documents which both have meaning (perhaps two pieces of source code, or two different school reports) and have the same signature, and that would be impressive.
Exactly the same problem applies: how on earth am I supposed to trust the 'attested' server code, given that those running the server can get control over their own hardware? Perhaps the hardware is supposed to be tamper-proof, but do you want to trust that with your money?
If I said to you 'my gambling program is on the level, and look, here is a certificate from Microsoft to prove it', would you trust that? No thanks.
Surely the valid key can come from a trusted PC you bought earlier. You just need to dump the BIOS image to disk, run it under Bochs, and do whatever fiddling you want.
Re your sig: I think there should be a +1 Troll moderation.
Applications like online casinos would also benefit from a magical honesty pill which users could take to prevent them from cheating - but it's not going to happen. The idea of trusted computing is to require a specially restricted client machine, but there's no way this could work and be secure enough for something like online gambling. An important rule of online security is *you cannot trust the client*, and even if the standard Dell PC that grandma buys is locked down with all sorts of nastyware, this will do nothing against a determined attacker who is able to program a computer to do what its he, its owner, wants.
Although trusted computing could never provide real security, it can give a lot of inconvenience to 90% of the population to stop them doing things with their computer that Microsoft would prefer them not to do. Just like other copy-protection measures over the years, its purpose is to keep the majority of users under control, not to stop the real criminals.
It's surprising how many vulnerabilities are found in Ethereal - this report is certainly not the first. And they tend to be root vulnerabilities.
Really, it's amazing that software like Ethereal, intended as a security tool, wasn't written with a bit more care and attention to avoid buffer overflows and similar causes of exploits. Normally one would expect something that needs to run as root and accept arbitrary data from the network interface to be written with extra caution and paranoia.
I think the most important lesson is in how to filter things. Do not have a list of 'bad' content and remove that, because there might always be something you hadn't thought of ( in this case). Instead define what you will allow, and block everything else. Yahoo and Hotmail need to start with the HTML DTD, decide which elements and attributes are considered safe, and write a program to chomp through documents letting only those things through.
That won't protect you if Microsoft decide to give a non-standard and moronic meaning to some existing HTML feature, but it will protect 100% against newly introduced stupid elements and XML weirdy things.