``We'll either need to tighten up how architectures execute instructions to make it harder to execute shell code in the first place..''
This has been done. The problem is that popular operating systems and applications don't make use of these techniques.
Shellcode crash course: shellcode is basically code which an attacker feeds to a program, which the program then executes, even though it is not supposed to. Getting the program to execute the shellcode thus relies on exploiting a security vulnerability. The canonical scenario is exploiting a buffer overflow, where the attacker feeds data to the program that is larger than the buffer the program has allocated for it. Programs that don't check for this will happily overwrite their own memory, including the return address of the current function. Overwrite the return address so that it points into the data you fed the program and presto, you now control the machine.
This relies on two things:
1. The program actually overwriting memory outside the buffer when reading data into the buffer 2. The machine actually executing the data as code
1 is dependent on the function used to read the input. C provides several functions that allow buffer overflows, and allows the programmer to write his own. I wrote an essay years ago where I advocated using higher level programming languages for most development specifically to avoid these dangers, and, frankly, I'm baffled that we're still using C so much. Sure, if you program carefully enough, you can avoid the pitfalls, but Real World data shows that this isn't happening. Besides, there are other good reasons for using other languages, for example more powerful abstractions that lead to more productivity. But, for this discussion, what is relevant is that shellcode would not be such a problem if it wasn't for so many programs being written using unsafe constructs in C and C++.
2 is easily prevented on most architectures by marking data as non-executable. There are actually some efforts to do this: OpenBSD has W^X, Linux has PaX, and Windows nowadays has Data Execution Prevention. However, most Linux distributions do not include PaX, and the default setting for DEP in Windows is opt-in, which means that programs that do not explicitly request it don't get it. Besides W^X, there are other mechanisms, such as address space layout randomization. ASLR makes executing shellcode hard by making it hard to predict at which address shellcode and library functions reside. It is enabled by default on OpenBSD. On Linux, it is provided by PaX, which, most distributions don't include. On Windows, it has been enabled by default since Vista, but only in a very limited form.
As far as I am concerned, the ability of an attacker to inject shellcode into a system would be a solved problem, if only the world adopted the solutions.
``You have heard of the concept of functional programming, have you? If functions are first-class citizens in data-type world, there is no separation between functions and data (or algorithms and data structures) anymore. So there is no point in a word like "metaprogramming". What those languages support, is metaprogramming.''
Not quite. Metaprogramming is programs operating on programs. In that sense, there isn't actually a real need for a language to specifically support metaprogramming, because you can always have one program generate the source code for another program.
The thing that metaprogramming lets you do is basically to build your own programming language. This is nothing new; in fact, the first compiler is an example of that.
Now, languages differ in their support for metaprogramming in a single program. Some, like old versions of COBOL, don't allow any of it at all: everything you want your program to do has to be spelled out in the primitives the language provides. Most languages offer at least the ability to define ones own functions as an abstraction mechanism. It's debatable whether that counts as creating a new language, though, and most people I know would agree that it's not.
Beyond functions, there are various mechanisms that allow more powerful abstractions. Function pointers (like C has) are one. Functions as first-class values (which you mention) are even more powerful. Indeed, using first-class functions, you can basically pass around pieces of behavior, which allows very powerful composition and abstraction. It _almost_ allows you to create your own control structures, and in many cases, the results are good enough that people don't feel the need to go any further.
Another abstraction mechanism, and one that allows you to do metaprogramming, is macros such as those found in Common Lisp. These allow one to, basically, run a transformer function for certain patterns in the source code. The transformer function takes program code as input and produces program code as output, which is then used instead of the original code. The power of this lies mostly in the fact that you can define a macro for patterns that would occur often in your program, and let the macro write your code for you. Programs writing programs. Build your own language _inside_ the language you already have.
Yet another construct is letting a running program change its own structure. This is something you can do in Ruby, where you can add and remove methods and variables at run time.
Finally, there are some languages where the actual language implementation is available to and can be modified by your program. Taken to the extreme, this would allow your program to modify everything from how it is read to how it is translated to code to be executed.
Long story short: metaprogramming goes far beyond what functions as first-class values gives you. Does that mean that the things you can do with first-class functions aren't metaprogramming? That's a matter of definition, but I would say that "What those languages support, is metaprogramming" and "there is no point in a word like "metaprogramming"" is a bit of a mischaracterization.
Are MLCs really that bad? I'm finding budget SSDs with MLCs, with warranties of several years. If the drive lasts several years, I'm a satisfied customer. I don't care if an SLC-based drive would have lasted longer, because by that time, I'll be replacing my drive with a larger one, anyway.
``I've gotten to use Python in the last couple of years - it's concise, expressive, whole lot less verbose (compared to Java, C)''
On those issues, Ruby isn't very different. In fact, I think the reason there are so many heated debates about which of Ruby and Python is better is exactly because, all things said and done, the differences don't matter that much and your preference is largely a matter of taste.
``but bit problematic when trying for tighter design with bigger scopes.''
Ruby borrows features from other great languages like Lisp and Smalltalk, which allow it to more naturally express paradigms other than imperative, and classes-and-methods. On the other hand, there is something to be said for Python's "one way to do it", as well.
Comparing Ruby and Python, I find that Python programs tend to have cleaner syntax (fewer hieroglyphs in the code) whereas Ruby programs tend to have cleaner structure (program more closely expresses what is being done because the language is multi-paradigm).
For programming in the large, both languages have about the same advantages and disadvantages: you have metaprogramming, which is a big plus, but no static checking, which is a minus. Personally, I feel like metaprogramming is an integral part of Ruby programming, whereas, in Python, it runs contrary to the spirit of "one way to do it", but Python does support metaprogramming and plenty of people are putting it to good use.
``What are the pluses/minuses of Ruby compared to Python? Has it dumped all its Perlism now? (I looked at Ruby briefly years back).''
Ruby definitely hasn't dumped its Perlisms. That's both a blessing and a curse: on the one hand, it allows for ugly programs, on the other hand, sometimes it's useful to say in a few hieroglyphs what would otherwise require lots of boilerplate code. Again, taste plays a role, but I must note that many languages that forgo Perlisms usually end up adopting regular expressions anyway, only with less power and more leaning toothpick syndrome. Given the choice, I'd rather have first-class regular expressions like Perl, even though they are the worst offenders in making Perl code look like line noise.
Basically, if you like Python for its purity, you'll probably detest Ruby. It's messy. But if you like Python for its expressive power, you may like Ruby because it offers you more of that. If you like Python but want static typing, don't bother with Ruby, because it won't give you that. You might be better off trying OCaml, Haskell, or Common Lisp (with appropriate compiler) in that case. If you're looking for speed, those are better options, too.
I'm glad to see so much work is being done on Ruby, and especially that people are working on compiling Ruby to native code. Ruby is a great language, but there is no denying that the old implementation (MRI 1.8 and before) is dog slow.
The voting machines were vulnerable to more than just eavesdropping, although eavesdropping was the official story from the government and also what most of the press was about.
However, the voting machines have since been banned. The latest elections were held with paper and pencil. It's good that way.
The reason is simple. If users know what they are doing and give due consideration to security, things are fine either way. You can enable whatever insecure settings you want, and I can't stop you, and it's good that way. You can also tighten the security of your system to the extreme, and I won't be able to stop you, and it's good that way. It's your system, you can do as you please.
Now, if users don't know what they're doing or don't give due consideration to security, what is going to happen?
If security is too tight, you are going to notice, because you won't be able to do something you want to be able to do. So you read the manual / ask for help / get somebody to help you / whatever, and get it fixed.
If security is too loose, you aren't going to notice, and you aren't going to do anything about it... right until the point when your system gets hosed and you are in a world of pain.
That's why the more secure option should be the default.
``Remember - it's not trying to brute force the key, just the container password.''
And you don't even have to run through the encryption algorithm for each password, either. You can get a long way by just storing pre-computed results for a lot of common passwords, or even every possible combination of characters that can be typed using the keyboard up to a certain length. It all depends on what is quicker.
Exactly. I may be using 2048 bits keys to protect my data, but I am surely not going to enter a 256-byte password every time I need to authenticate. That makes my passwords clearly the weakest link. And if you consider that I can't even use all possible byte values in my password, the link becomes even weaker...
You are right that the idea is that this only applies to the scenario where there is, essentially, a single user who owns, operates, and physically sits at the PC, and that a lot of people seem to be missing that.
However, if you own, operate, and physically sit at your PC, how onerous would it be to have to enter your password, or even the root password, when you want to do something as disruptive and uncommon as use the package manager to make system wide changes?
And if that is indeed too onerous, how bad would it be to have to change the configuration to allow you to do same without having to enter a password?
In either of those cases, you would have a secure-by-default design. Deviating from that just opens a huge can of worms (no pun intended), as there are suddenly a lot more things you need to worry about - and failing to worry about them gives you an insecure system.
Doing something as unexpected and potentially dangerous as this should NOT have been done without ample discussion, and should definitely have been mentioned in the release notes and during the installation procedure - probably with an option right there to turn it on and off, and probably with the default being off.
The mind boggling WTF here isn't that somebody thought letting users install packages without having to enter a password is a good idea, but rather that the new, disruptive, less secure setting has been made the default without the world, the users, or even the developers knowing about it.
Ah, ok. That wasn't clear to me from the description.
So you're saying that a regular luser can install packages AS ROOT without needing to provide the root password, be a member of a specific group, etc etc? And thus, a regular, otherwise unprivileged user can write to directories normally only accessible to root, install suid root binaries, and overwrite configuration files?
Wow.
Just wow.
And nobody raised a big stink about it before the official release.
How is allowing non-privileged users to install packages any more of a security risk than, say, letting them bring their own binaries to the system, or compiling their own binaries on the system?
At least the packages that are allowed to be installed are signed, which means _someone_ looked at them and approved them.
``What's in this for Samsung ? Are they going to run Enlightenment on their mobile phones ? Their TV's ?''
Possibly. Mobile phones are actually powerful enough these days to get pretty much all the flashy eye candy stuff you might want, but Enlightenment is one of the few products that _both_ run on such "low-end" hardware and provide the eye candy.
Besides mobiles phones and TVs, though, Samsung may also be thinking about notebooks.
I did eventually find skanlite. However, I couldn't set a paper size (other than maybe by selecting it with the mouse). Maybe I didn't look hard enough, but I figured it wasn't worth my time to learn a new program. I already know how to use scanimage, and that gets the job done just fine. I just used to use Kooka because it gave me previews.
``Again, for RHEL, what's the alternative? The whole point of RHEL is to provide long-term stable releases''
And there you have it. It's about stability. If I write software, or a configuration file, or anything else that interfaces with YourSoftware version X, and it works today, I think it is completely reasonable to expect it to also work tomorrow. If you make a new release of YourSoftware tomorrow that doesn't work with my code anymore, it's not YourSoftware version X anymore. It's a different version.
I don't want my distro to be pushing new versions on me that break compatibility.
If you want to introduce new versions, that's fine. In fact, I'm all for it. Just don't replace my working software with the new software that may or may not preserve compatibility. If it doesn't preserve compatibility, I want to have to explicitly upgrade to it. Put it in the next version of the distro. Or put it in a new package which can be installed alongside the old package. But don't put it in the current version of the distro, in the same package, because then you'll have multiple incompatible versions of the same distro with the same version number.
Re:Ubuntu influence on marketing materials
on
Fedora 12 Released
·
· Score: 1
``Mandrake had urpmi and Debian had apt-get years before RedHat had anything comparable.''
Yeah. And as a result of that, there are _still_ people who believe software installation on Linux is hard. That hasn't been true for over 10 years... unless you choose to do it the hard way, or choose to run a distro that doesn't provide an easy way.
Re:Ubuntu influence on marketing materials
on
Fedora 12 Released
·
· Score: 2, Insightful
``Wait, did Fedora even have marketing materials before Ubuntu?''
They didn't need to, because they are the free version of Red Hat and Red Hat _was_ Linux in a lot of people's minds.
But when Ubuntu came around, it quickly got so popular that it scared the big distros into getting their act together. Ubuntu's killer combo was the combination of working package management with ease of use. Nowadays, that's sort of what people have come to expect from a Linux distro, but, before Ubuntu, that was far from given.
Unfortunately, Ubuntu seems to have lost its way. Every new release seems to introduce a lot of breakage, which in my opinion, outright destroys ease of use.
Maybe Fedora is the way to go, these days. They also compile their software with stack smashing protection, right? I think I'm going to give it a go.
``Would you rather have 100 tons of waste annually from a thermal reactor plant, or 2 tons from a breeder reactor? It's radiocative either way.''
Well, there's radioactive, radioactive, and radioactive, so saying "it's radioactive either way" is not very informative. How dangerous is it and how long will it stay that way?
I am sure that virtually everything I will come into contact with during my entire live will be radioactive, but it will probably emit so little radiation that I don't bother even thinking about it. Similarly, a small amount of highly radioactive matter doesn't bother me a lot, either; it will decay in a flash and then life will be back to normal.
What I am bothered by, though, is the idea of creating large amounts of material that will be dangerous long after we are gone. Past generations haven't made my life miserable by making my world a nuclear/toxic/what-have-you waste dump, and I'd like to not do so to the generations that come after me, either.
Although I haven't really used KDE since the 2.x series, there are a couple of KDE applications I used until recently. Among those are Konqueror, Okular, and Kooka.
I switched to KDE 4.3 from KDE 3.5 when replacing my Debian installation with Ubuntu karmic, and while I liked some things, I eventually quit using what few KDE apps I had been using, because there were just too many annoyances. For example, being unable to copy text out of Konqueror, occasional crashes, and Kooka having gone missing altogether.
My question is: Are the problems I've been experiencing problems with KDE 4.3, or are they specific to the Ubuntu version I have been using?
``I'm a happy KDE 3.5 user. They screwed KDE 4 BY DESIGN, so I suppose the bugs they'll fix now again are just some bugs of fancy unneeded things, and not UI problems with important base components... ''
With so many people expressing that sentiment, I'm curious: has KDE 3 seen any significant development since the release of KDE 4? You'd think there would be a lot of people even among the developers who thought they way KDE 4 was handles was a disaster, and continue to improve on KDE 3 instead (perhaps in a differently named fork). Has this actually happened?
Slashdot Mirror
``We'll either need to tighten up how architectures execute instructions to make it harder to execute shell code in the first place..''
This has been done. The problem is that popular operating systems and applications don't make use of these techniques.
Shellcode crash course: shellcode is basically code which an attacker feeds to a program, which the program then executes, even though it is not supposed to. Getting the program to execute the shellcode thus relies on exploiting a security vulnerability. The canonical scenario is exploiting a buffer overflow, where the attacker feeds data to the program that is larger than the buffer the program has allocated for it. Programs that don't check for this will happily overwrite their own memory, including the return address of the current function. Overwrite the return address so that it points into the data you fed the program and presto, you now control the machine.
This relies on two things:
1. The program actually overwriting memory outside the buffer when reading data into the buffer
2. The machine actually executing the data as code
1 is dependent on the function used to read the input. C provides several functions that allow buffer overflows, and allows the programmer to write his own. I wrote an essay years ago where I advocated using higher level programming languages for most development specifically to avoid these dangers, and, frankly, I'm baffled that we're still using C so much. Sure, if you program carefully enough, you can avoid the pitfalls, but Real World data shows that this isn't happening. Besides, there are other good reasons for using other languages, for example more powerful abstractions that lead to more productivity. But, for this discussion, what is relevant is that shellcode would not be such a problem if it wasn't for so many programs being written using unsafe constructs in C and C++.
2 is easily prevented on most architectures by marking data as non-executable. There are actually some efforts to do this: OpenBSD has W^X, Linux has PaX, and Windows nowadays has Data Execution Prevention. However, most Linux distributions do not include PaX, and the default setting for DEP in Windows is opt-in, which means that programs that do not explicitly request it don't get it. Besides W^X, there are other mechanisms, such as address space layout randomization. ASLR makes executing shellcode hard by making it hard to predict at which address shellcode and library functions reside. It is enabled by default on OpenBSD. On Linux, it is provided by PaX, which, most distributions don't include. On Windows, it has been enabled by default since Vista, but only in a very limited form.
As far as I am concerned, the ability of an attacker to inject shellcode into a system would be a solved problem, if only the world adopted the solutions.
``You have heard of the concept of functional programming, have you? If functions are first-class citizens in data-type world, there is no separation between functions and data (or algorithms and data structures) anymore. So there is no point in a word like "metaprogramming". What those languages support, is metaprogramming.''
Not quite. Metaprogramming is programs operating on programs. In that sense, there isn't actually a real need for a language to specifically support metaprogramming, because you can always have one program generate the source code for another program.
The thing that metaprogramming lets you do is basically to build your own programming language. This is nothing new; in fact, the first compiler is an example of that.
Now, languages differ in their support for metaprogramming in a single program. Some, like old versions of COBOL, don't allow any of it at all: everything you want your program to do has to be spelled out in the primitives the language provides. Most languages offer at least the ability to define ones own functions as an abstraction mechanism. It's debatable whether that counts as creating a new language, though, and most people I know would agree that it's not.
Beyond functions, there are various mechanisms that allow more powerful abstractions. Function pointers (like C has) are one. Functions as first-class values (which you mention) are even more powerful. Indeed, using first-class functions, you can basically pass around pieces of behavior, which allows very powerful composition and abstraction. It _almost_ allows you to create your own control structures, and in many cases, the results are good enough that people don't feel the need to go any further.
Another abstraction mechanism, and one that allows you to do metaprogramming, is macros such as those found in Common Lisp. These allow one to, basically, run a transformer function for certain patterns in the source code. The transformer function takes program code as input and produces program code as output, which is then used instead of the original code. The power of this lies mostly in the fact that you can define a macro for patterns that would occur often in your program, and let the macro write your code for you. Programs writing programs. Build your own language _inside_ the language you already have.
Yet another construct is letting a running program change its own structure. This is something you can do in Ruby, where you can add and remove methods and variables at run time.
Finally, there are some languages where the actual language implementation is available to and can be modified by your program. Taken to the extreme, this would allow your program to modify everything from how it is read to how it is translated to code to be executed.
Long story short: metaprogramming goes far beyond what functions as first-class values gives you. Does that mean that the things you can do with first-class functions aren't metaprogramming? That's a matter of definition, but I would say that "What those languages support, is metaprogramming" and "there is no point in a word like "metaprogramming"" is a bit of a mischaracterization.
Are MLCs really that bad? I'm finding budget SSDs with MLCs, with warranties of several years. If the drive lasts several years, I'm a satisfied customer. I don't care if an SLC-based drive would have lasted longer, because by that time, I'll be replacing my drive with a larger one, anyway.
``I've gotten to use Python in the last couple of years - it's concise, expressive, whole lot less verbose (compared to Java, C)''
On those issues, Ruby isn't very different. In fact, I think the reason there are so many heated debates about which of Ruby and Python is better is exactly because, all things said and done, the differences don't matter that much and your preference is largely a matter of taste.
``but bit problematic when trying for tighter design with bigger scopes.''
Ruby borrows features from other great languages like Lisp and Smalltalk, which allow it to more naturally express paradigms other than imperative, and classes-and-methods. On the other hand, there is something to be said for Python's "one way to do it", as well.
Comparing Ruby and Python, I find that Python programs tend to have cleaner syntax (fewer hieroglyphs in the code) whereas Ruby programs tend to have cleaner structure (program more closely expresses what is being done because the language is multi-paradigm).
For programming in the large, both languages have about the same advantages and disadvantages: you have metaprogramming, which is a big plus, but no static checking, which is a minus. Personally, I feel like metaprogramming is an integral part of Ruby programming, whereas, in Python, it runs contrary to the spirit of "one way to do it", but Python does support metaprogramming and plenty of people are putting it to good use.
``What are the pluses/minuses of Ruby compared to Python? Has it dumped all its Perlism now? (I looked at Ruby briefly years back).''
Ruby definitely hasn't dumped its Perlisms. That's both a blessing and a curse: on the one hand, it allows for ugly programs, on the other hand, sometimes it's useful to say in a few hieroglyphs what would otherwise require lots of boilerplate code. Again, taste plays a role, but I must note that many languages that forgo Perlisms usually end up adopting regular expressions anyway, only with less power and more leaning toothpick syndrome. Given the choice, I'd rather have first-class regular expressions like Perl, even though they are the worst offenders in making Perl code look like line noise.
Basically, if you like Python for its purity, you'll probably detest Ruby. It's messy. But if you like Python for its expressive power, you may like Ruby because it offers you more of that. If you like Python but want static typing, don't bother with Ruby, because it won't give you that. You might be better off trying OCaml, Haskell, or Common Lisp (with appropriate compiler) in that case. If you're looking for speed, those are better options, too.
I'm glad to see so much work is being done on Ruby, and especially that people are working on compiling Ruby to native code. Ruby is a great language, but there is no denying that the old implementation (MRI 1.8 and before) is dog slow.
That's only part of the story.
The voting machines were vulnerable to more than just eavesdropping, although eavesdropping was the official story from the government and also what most of the press was about.
However, the voting machines have since been banned. The latest elections were held with paper and pencil. It's good that way.
Now if people would only understand this ...
``Regardless of the pounding Chrome OS is taking, 7 second boot up time with instant access is killer.''
Still, we gotta be able to do better than that.
``It's an email appliance OS that lets you read the web pages people link to in their emails.''
In other words, it's exactly what mom and pop need. Especially if someone can make it work without needing a security expert to keep it working.
Bad security should not be the default.
The reason is simple. If users know what they are doing and give due consideration to security, things are fine either way. You can enable whatever insecure settings you want, and I can't stop you, and it's good that way. You can also tighten the security of your system to the extreme, and I won't be able to stop you, and it's good that way. It's your system, you can do as you please.
Now, if users don't know what they're doing or don't give due consideration to security, what is going to happen?
If security is too tight, you are going to notice, because you won't be able to do something you want to be able to do. So you read the manual / ask for help / get somebody to help you / whatever, and get it fixed.
If security is too loose, you aren't going to notice, and you aren't going to do anything about it ... right until the point when your system gets hosed and you are in a world of pain.
That's why the more secure option should be the default.
I just accidentally 4 million passwords.
``Remember - it's not trying to brute force the key, just the container password.''
And you don't even have to run through the encryption algorithm for each password, either. You can get a long way by just storing pre-computed results for a lot of common passwords, or even every possible combination of characters that can be typed using the keyboard up to a certain length. It all depends on what is quicker.
Exactly. I may be using 2048 bits keys to protect my data, but I am surely not going to enter a 256-byte password every time I need to authenticate. That makes my passwords clearly the weakest link. And if you consider that I can't even use all possible byte values in my password, the link becomes even weaker ...
Wait, Sony released versions of the PS3 that _don't_ allow you to install Linux? Why am I only hearing about this now?
The PS3 _is_ very powerful, and I think somebody just realized how to make good use of that power.
You are right that the idea is that this only applies to the scenario where there is, essentially, a single user who owns, operates, and physically sits at the PC, and that a lot of people seem to be missing that.
However, if you own, operate, and physically sit at your PC, how onerous would it be to have to enter your password, or even the root password, when you want to do something as disruptive and uncommon as use the package manager to make system wide changes?
And if that is indeed too onerous, how bad would it be to have to change the configuration to allow you to do same without having to enter a password?
In either of those cases, you would have a secure-by-default design. Deviating from that just opens a huge can of worms (no pun intended), as there are suddenly a lot more things you need to worry about - and failing to worry about them gives you an insecure system.
Doing something as unexpected and potentially dangerous as this should NOT have been done without ample discussion, and should definitely have been mentioned in the release notes and during the installation procedure - probably with an option right there to turn it on and off, and probably with the default being off.
The mind boggling WTF here isn't that somebody thought letting users install packages without having to enter a password is a good idea, but rather that the new, disruptive, less secure setting has been made the default without the world, the users, or even the developers knowing about it.
Ah, ok. That wasn't clear to me from the description.
So you're saying that a regular luser can install packages AS ROOT without needing to provide the root password, be a member of a specific group, etc etc? And thus, a regular, otherwise unprivileged user can write to directories normally only accessible to root, install suid root binaries, and overwrite configuration files?
Wow.
Just wow.
And nobody raised a big stink about it before the official release.
Incredible.
How is allowing non-privileged users to install packages any more of a security risk than, say, letting them bring their own binaries to the system, or compiling their own binaries on the system?
At least the packages that are allowed to be installed are signed, which means _someone_ looked at them and approved them.
``What's in this for Samsung ? Are they going to run Enlightenment on their mobile phones ? Their TV's ?''
Possibly. Mobile phones are actually powerful enough these days to get pretty much all the flashy eye candy stuff you might want, but Enlightenment is one of the few products that _both_ run on such "low-end" hardware and provide the eye candy.
Besides mobiles phones and TVs, though, Samsung may also be thinking about notebooks.
I did eventually find skanlite. However, I couldn't set a paper size (other than maybe by selecting it with the mouse). Maybe I didn't look hard enough, but I figured it wasn't worth my time to learn a new program. I already know how to use scanimage, and that gets the job done just fine. I just used to use Kooka because it gave me previews.
``Again, for RHEL, what's the alternative? The whole point of RHEL is to provide long-term stable releases''
And there you have it. It's about stability. If I write software, or a configuration file, or anything else that interfaces with YourSoftware version X, and it works today, I think it is completely reasonable to expect it to also work tomorrow. If you make a new release of YourSoftware tomorrow that doesn't work with my code anymore, it's not YourSoftware version X anymore. It's a different version.
I don't want my distro to be pushing new versions on me that break compatibility.
If you want to introduce new versions, that's fine. In fact, I'm all for it. Just don't replace my working software with the new software that may or may not preserve compatibility. If it doesn't preserve compatibility, I want to have to explicitly upgrade to it. Put it in the next version of the distro. Or put it in a new package which can be installed alongside the old package. But don't put it in the current version of the distro, in the same package, because then you'll have multiple incompatible versions of the same distro with the same version number.
``Mandrake had urpmi and Debian had apt-get years before RedHat had anything comparable.''
Yeah. And as a result of that, there are _still_ people who believe software installation on Linux is hard. That hasn't been true for over 10 years ... unless you choose to do it the hard way, or choose to run a distro that doesn't provide an easy way.
``Wait, did Fedora even have marketing materials before Ubuntu?''
They didn't need to, because they are the free version of Red Hat and Red Hat _was_ Linux in a lot of people's minds.
But when Ubuntu came around, it quickly got so popular that it scared the big distros into getting their act together. Ubuntu's killer combo was the combination of working package management with ease of use. Nowadays, that's sort of what people have come to expect from a Linux distro, but, before Ubuntu, that was far from given.
Unfortunately, Ubuntu seems to have lost its way. Every new release seems to introduce a lot of breakage, which in my opinion, outright destroys ease of use.
Maybe Fedora is the way to go, these days. They also compile their software with stack smashing protection, right? I think I'm going to give it a go.
``Would you rather have 100 tons of waste annually from a thermal reactor plant, or 2 tons from a breeder reactor? It's radiocative either way.''
Well, there's radioactive, radioactive, and radioactive, so saying "it's radioactive either way" is not very informative. How dangerous is it and how long will it stay that way?
I am sure that virtually everything I will come into contact with during my entire live will be radioactive, but it will probably emit so little radiation that I don't bother even thinking about it. Similarly, a small amount of highly radioactive matter doesn't bother me a lot, either; it will decay in a flash and then life will be back to normal.
What I am bothered by, though, is the idea of creating large amounts of material that will be dangerous long after we are gone. Past generations haven't made my life miserable by making my world a nuclear/toxic/what-have-you waste dump, and I'd like to not do so to the generations that come after me, either.
Although I haven't really used KDE since the 2.x series, there are a couple of KDE applications I used until recently. Among those are Konqueror, Okular, and Kooka.
I switched to KDE 4.3 from KDE 3.5 when replacing my Debian installation with Ubuntu karmic, and while I liked some things, I eventually quit using what few KDE apps I had been using, because there were just too many annoyances. For example, being unable to copy text out of Konqueror, occasional crashes, and Kooka having gone missing altogether.
My question is: Are the problems I've been experiencing problems with KDE 4.3, or are they specific to the Ubuntu version I have been using?
``I'm a happy KDE 3.5 user. They screwed KDE 4 BY DESIGN, so I suppose the bugs they'll fix now again are just some bugs of fancy unneeded things, and not UI problems with important base components ... ''
With so many people expressing that sentiment, I'm curious: has KDE 3 seen any significant development since the release of KDE 4? You'd think there would be a lot of people even among the developers who thought they way KDE 4 was handles was a disaster, and continue to improve on KDE 3 instead (perhaps in a differently named fork). Has this actually happened?