Humans have widescreen vision, therefore a widescreen display makes sense.
The bars around a single column on webpages thing is a huge interface design bug. The people who design those webpages should be fired for incompetence.
I can go 24 hours without food with only a bit of discomfort - I'm guessing that this patch will feel about the same as that except without the fall in blood sugar level.
I would further guess that if you tried to go for a week on these patches without food your digestive system would act up pretty bad - at very least you'd wish you had a bottle of tums.
"Food Pills" are a way more complex problem than you'd expect them to be at first glance.
In the food you eat every day, you need to get the following:
Raw calories. Protein. Vitamins and Minerals. Fiber. Eithor sufficient volume to dilute / use your stomach acid or antacids. Various other stuff that's less well known / studied.
Now, food pills would be an interesting and useful line of research, but that research would be best done here on earth where it doesn't cost hundreds of thousands of dollars to give the research subjects an emergency sandwich if a test fails.
Given that software patents would be a relevent issue if the tsunami had not occured - something that I believe is true - the tsunami changes nothing for those not directly effected by it.
Because obviously two things can't both matter at the same time.
I'm not saying that tens of thousands of people dying in a natural disaster isn't very tragic, but it doesn't make the software patent issue any less important.
In fact - because of the tendancy to focus on easily-understood problems - issues like software patents become even more relevent when there's some event to distract from them.
The people died from the tsunami already. Whatever processes are going to rescue surviors and rebuild are already in motion. The issue's getting extensive coverage in all news media. I'd say that here, on slashdot, in this topic, the Patent issue is *far* more important and relevent.
I'm sure the Russians are less putting guns to people's heads and more laughing their ass off that they're owning the USA at space on a fraction of our budget and with technology from the 60's.
It's perfectly possible to use a Mac, or even to use desktop Linux. Heck, I bet the average user would be fine on OpenBSD if it supported their hardware.
What software you use is really your choice, and the security implications of Windows make that choice seem pretty sketchy.
If the only jacket manufacturer offered pickpocket access holes and "steal from me" signs, I'm sure that people would activly consider sweaters and coats instead.
Windows has been a known security hole for almost 10 years now. Until very recently, you could expect to spend $1000+ on a new computer - that's worth the investment of the amount of time it would take to find out that running Windows is dangerous.
You might have had a point 7 years ago when this whole "Windows has a new remote exploit" thing was a little bit more... new and unexpected.
But in late 2004, with almost 10 years of evidence that running Windows is just asking to be exploited, I find it hard to blame anyone but the users.
If you were to travel somewhere known for it's pickpockets during tourist season and kept $1000 in your wallet in the inside pocket of a loose jacket, I'd blame you (not the pickpocket) when you lost your money. The police there would agree with me. Running Windows on the internet is pretty similar, and should be treated as such.
I haven't really seen a desktop Linux system that doesn't have both the Gnome and KDE libraries installed - and given that there's no reason why a KDE app doesn't run fine on Gnome and the reverse.
How would you design the tool that you discribe? Where would it get the path information?
I'm assuming you'd want to be able to say stuff like get_path("apache_log") or even redhat2debian("/usr/share/apache/log"). In that case the translation tool would need to have a database of different file paths - a much more failure-prone and maintnence intensive proposition than my config file solution - especially since distribution package maintainers would (do) populate the packaged config file with appropriate values.
They're both major games that were released targetting computers with Windows on them. Expecting these to work on the current version of Windows is *exactly* as appropriate as expecting software from the same period for Linux to run on a current version of Linux - and with Linux you can get that stuff to run usually just by installing a compatibility package.
If Live Motion 1 works on XP SP2 it's through some sort of downloadable fix/hotpatch - equivilent in annoyance to installing an "old libc compatibility package".
You're seeing a problem that doesn't really exist. "Linux" in this context is a unix-like operating system. Period.
If you're writing a non-desktop app, writing to a unix like operationg system is pretty well covered. Everyone who cares knows the story - it's the same story it's been for a while.
Unix desktops are a little bit less well understood, but they're still pretty simple. There are various different development toolkits and stuff, but it doesn't really matter. It'll take you a couple hours to figure this stuff out as a developer, but that's not a big problem and it's all transparent to the user anyway.
Developing for Linux isn't bad. Depending on how you look at it, it's as easy/easier than developing for Windows.
The development environment is standard with some distros and easily installed for others. There are cross platform GUI toolkits that work excellently and have good documentation (wxWindows and GTK).
The only real problem I see here is that for an experianced Windows programmer it's hard to quickly see which development tools are "real". My easy suggestion would be: If in doubt, target Gnome. Another good plan is wxWindows.
I'm having trouble visualizing a case where your issue would be more than an inconvienence solvable through a config file.
For example: Let's imagine for a second that for Apache, each distro's premade package puts the log files in a different place, none of them the same as where the source package puts them by default. (This is probably true, but I'm not sure.)
So, you right a program to analyze the apache log files. When it goes to find them, it looks in some places where they should be (perhaps "/usr/local/apache/logs" and "/var/log/apache"), and if it doesn't find them it dies with "Error: Can't find Apache logs, please specify their location in the config file at/etc/logscan/config".
So...
Give an example where A.) The list of expected paths + config file solution doesn't work and B.) This is something you'd really be distributing and expecting to work on other people's systems and C.) This isn't distro specific enough anyway that it would be reasonable to have distro-specific versions (i.e. KDE Kontrol Center).
Anal sex doesn't cover the Female - Female case natively. This can be worked around with conversion tools, but it's not as convienent as a case-specific protocal.
In conclusion, your statement ("Saying that Java is nice because it works on all OSes is like saying anal sex is nice because it works on all genders.") seems highly accurate.
To make my point a bit clearer, there's a bunch of different application-but-not-driver compatible "Windows Distributions".
Saying (FreeBSD, Debian GNU/Linux) are a group the same as (Windows XP, Windows 98) are a group is meaningful: FreeBSD and Debian can run the same binaries but need different drivers - the same as Windows XP vs. 98.
I'd write this as "BSD forks need to maintain their own kernel", which sounds more like a disadvantage, but I don't think it's really relevent.
Let's talk about "Desktop Distros of Unix" for a second. We have the following major players:
Solaris, FreeBSD, OpenBSD, NetBSD, Debian GNU/Linux, Slackware Linux, RedHat/Fedora Linux, Mac OS X, (many others)
Then there's non-unix desktop systems: Windows
Now, for some odd reason Windows has the majority of desktop market share even though almost every other system out there is Unix based and mostly-compatible.
Here's the trick: Everything (meaningful) other than Windows that might be on the desktop is Unix. If we can make the Unixes compatible enough, then application developers can target two platforms and get everyone. Targetting 2 platforms for 90% and 9% is fine. Targetting 7 platforms for 90% 4% 2.5% 1% 0.7% 0.5% and 0.3% isn't the plan.
Moving towards two (or three) different target platforms for desktop applications is worthwhile, and (like it or not) FreeBSD is the same platform as Linux and will be helped by any LSB efforts (and should contribute to and comply with them if possible).
Current version of KDE / Gnome (and at this point even previous versions going back a couple years) are realistically about as learnable by exploring as Windows or a Mac.
If you put a random person who is used to a Mac and has never used Windows or Linux before in front of a properly set up Linux machine he'll have no more trouble performing the following tasks than he would if it were a Windows machine - in neither case would I expect that he'd need the documentation:
Surfing the Web, Checking Email, Sending Email, Creating a simple word processor document and printing it, Scanning in a picture / adding a textual caption to it (i.e. With the gimp) / and uploading it to his website by FTP, joining an IRC channel and talking, doing instant messaging
Linux will not get to the desktop until such time as one can walk into a store (or online) and buy SUPERDEEDUPER Tools for Linux for 49.95 and have it work, out of the box on all the major distros (SuSE, Redhat, Fedora, Debian..... ).
Why's this? One of the big advantages of Linux is that anything you'd reasonably expect to find in SUPERDEDUPER TOOLS is prepackaged by your distributor.
In fact, even Windows has moved away from "go to the store and buy random crap" to "go on the net and download random crap". For most of this software, the Windows version is lower quality and shareware compared to Linux's high quality open source app.
The only real quesion is relevent commercial applications. It would be nice if you could go to BestBuy and get Lotus Smart Suite for Linux in a box with some CDs.
But if you think about that for a bit, it's a lot smaller of an issue than you'd think. First, there's no real obstacles to releasing software like that for Linux... Loki Installer works pretty well. Second, with OpenOffice being a free download, you don't really need SmartSuite.
The "Existing Downloadable Tools are Fine" statement makes most boxed software pretty much irrelevent. Antivirus software is not an issue currently for Linux. With standard "Office Suite" stuff, eithor OpenOffice is fine or you want Microsoft Word. With graphics manipulation stuff, eithor The Gimp is fine or you want Photoshop.
We could probably make a short list of commercial software where it not being available boxed for Linux in the store really matters... but I don't think that the lack of boxed software for Linux in general is really a relvent thing holding it back from Desktop usage.
Slashdot Mirror
This is a seperate issue that should probably be solved with some sort of "maximum column width" document style property.
Humans have widescreen vision, therefore a widescreen display makes sense.
The bars around a single column on webpages thing is a huge interface design bug. The people who design those webpages should be fired for incompetence.
I can go 24 hours without food with only a bit of discomfort - I'm guessing that this patch will feel about the same as that except without the fall in blood sugar level.
I would further guess that if you tried to go for a week on these patches without food your digestive system would act up pretty bad - at very least you'd wish you had a bottle of tums.
"Food Pills" are a way more complex problem than you'd expect them to be at first glance.
In the food you eat every day, you need to get the following:
Raw calories. Protein. Vitamins and Minerals. Fiber. Eithor sufficient volume to dilute / use your stomach acid or antacids. Various other stuff that's less well known / studied.
Now, food pills would be an interesting and useful line of research, but that research would be best done here on earth where it doesn't cost hundreds of thousands of dollars to give the research subjects an emergency sandwich if a test fails.
Such an explosion would be potentially visable from Massachussetts. If the observer had binoculars.
How frequently is this going to come up in real situations where it isn't pretty easy to write a logging daemon to handle it?
I'm guessing that bringing another fab online is more likely to decrease prices than increase them - which is exactly what Intel needs to be doing.
Given that software patents would be a relevent issue if the tsunami had not occured - something that I believe is true - the tsunami changes nothing for those not directly effected by it.
Yea, because when someone patents qsort for their embedded system it's a *really* big leap to go after other software implementing the same algorithm.
Because obviously two things can't both matter at the same time.
I'm not saying that tens of thousands of people dying in a natural disaster isn't very tragic, but it doesn't make the software patent issue any less important.
In fact - because of the tendancy to focus on easily-understood problems - issues like software patents become even more relevent when there's some event to distract from them.
The people died from the tsunami already. Whatever processes are going to rescue surviors and rebuild are already in motion. The issue's getting extensive coverage in all news media. I'd say that here, on slashdot, in this topic, the Patent issue is *far* more important and relevent.
I'm sure the Russians are less putting guns to people's heads and more laughing their ass off that they're owning the USA at space on a fraction of our budget and with technology from the 60's.
It's perfectly possible to use a Mac, or even to use desktop Linux. Heck, I bet the average user would be fine on OpenBSD if it supported their hardware.
What software you use is really your choice, and the security implications of Windows make that choice seem pretty sketchy.
If the only jacket manufacturer offered pickpocket access holes and "steal from me" signs, I'm sure that people would activly consider sweaters and coats instead.
Windows has been a known security hole for almost 10 years now. Until very recently, you could expect to spend $1000+ on a new computer - that's worth the investment of the amount of time it would take to find out that running Windows is dangerous.
You might have had a point 7 years ago when this whole "Windows has a new remote exploit" thing was a little bit more... new and unexpected.
But in late 2004, with almost 10 years of evidence that running Windows is just asking to be exploited, I find it hard to blame anyone but the users.
If you were to travel somewhere known for it's pickpockets during tourist season and kept $1000 in your wallet in the inside pocket of a loose jacket, I'd blame you (not the pickpocket) when you lost your money. The police there would agree with me. Running Windows on the internet is pretty similar, and should be treated as such.
I haven't really seen a desktop Linux system that doesn't have both the Gnome and KDE libraries installed - and given that there's no reason why a KDE app doesn't run fine on Gnome and the reverse.
How would you design the tool that you discribe? Where would it get the path information?
I'm assuming you'd want to be able to say stuff like get_path("apache_log") or even redhat2debian("/usr/share/apache/log"). In that case the translation tool would need to have a database of different file paths - a much more failure-prone and maintnence intensive proposition than my config file solution - especially since distribution package maintainers would (do) populate the packaged config file with appropriate values.
They're both major games that were released targetting computers with Windows on them. Expecting these to work on the current version of Windows is *exactly* as appropriate as expecting software from the same period for Linux to run on a current version of Linux - and with Linux you can get that stuff to run usually just by installing a compatibility package.
If Live Motion 1 works on XP SP2 it's through some sort of downloadable fix/hotpatch - equivilent in annoyance to installing an "old libc compatibility package".
You're seeing a problem that doesn't really exist. "Linux" in this context is a unix-like operating system. Period.
If you're writing a non-desktop app, writing to a unix like operationg system is pretty well covered. Everyone who cares knows the story - it's the same story it's been for a while.
Unix desktops are a little bit less well understood, but they're still pretty simple. There are various different development toolkits and stuff, but it doesn't really matter. It'll take you a couple hours to figure this stuff out as a developer, but that's not a big problem and it's all transparent to the user anyway.
Developing for Linux isn't bad. Depending on how you look at it, it's as easy/easier than developing for Windows.
The development environment is standard with some distros and easily installed for others. There are cross platform GUI toolkits that work excellently and have good documentation (wxWindows and GTK).
The only real problem I see here is that for an experianced Windows programmer it's hard to quickly see which development tools are "real". My easy suggestion would be: If in doubt, target Gnome. Another good plan is wxWindows.
I'm having trouble visualizing a case where your issue would be more than an inconvienence solvable through a config file.
/etc/logscan/config".
For example:
Let's imagine for a second that for Apache, each distro's premade package puts the log files in a different place, none of them the same as where the source package puts them by default. (This is probably true, but I'm not sure.)
So, you right a program to analyze the apache log files. When it goes to find them, it looks in some places where they should be (perhaps "/usr/local/apache/logs" and "/var/log/apache"), and if it doesn't find them it dies with "Error: Can't find Apache logs, please specify their location in the config file at
So...
Give an example where A.) The list of expected paths + config file solution doesn't work and B.) This is something you'd really be distributing and expecting to work on other people's systems and C.) This isn't distro specific enough anyway that it would be reasonable to have distro-specific versions (i.e. KDE Kontrol Center).
Anal sex doesn't cover the Female - Female case natively. This can be worked around with conversion tools, but it's not as convienent as a case-specific protocal.
In conclusion, your statement ("Saying that Java is nice because it works on all OSes is like saying anal sex is nice because it works on all genders.") seems highly accurate.
To make my point a bit clearer, there's a bunch of different application-but-not-driver compatible "Windows Distributions".
Saying (FreeBSD, Debian GNU/Linux) are a group the same as (Windows XP, Windows 98) are a group is meaningful:
FreeBSD and Debian can run the same binaries but need different drivers - the same as Windows XP vs. 98.
I'd write this as "BSD forks need to maintain their own kernel", which sounds more like a disadvantage, but I don't think it's really relevent.
Let's talk about "Desktop Distros of Unix" for a second. We have the following major players:
Solaris, FreeBSD, OpenBSD, NetBSD, Debian GNU/Linux, Slackware Linux, RedHat/Fedora Linux, Mac OS X, (many others)
Then there's non-unix desktop systems:
Windows
Now, for some odd reason Windows has the majority of desktop market share even though almost every other system out there is Unix based and mostly-compatible.
Here's the trick: Everything (meaningful) other than Windows that might be on the desktop is Unix. If we can make the Unixes compatible enough, then application developers can target two platforms and get everyone. Targetting 2 platforms for 90% and 9% is fine. Targetting 7 platforms for 90% 4% 2.5% 1% 0.7% 0.5% and 0.3% isn't the plan.
Moving towards two (or three) different target platforms for desktop applications is worthwhile, and (like it or not) FreeBSD is the same platform as Linux and will be helped by any LSB efforts (and should contribute to and comply with them if possible).
Not true.
Current version of KDE / Gnome (and at this point even previous versions going back a couple years) are realistically about as learnable by exploring as Windows or a Mac.
If you put a random person who is used to a Mac and has never used Windows or Linux before in front of a properly set up Linux machine he'll have no more trouble performing the following tasks than he would if it were a Windows machine - in neither case would I expect that he'd need the documentation:
Surfing the Web, Checking Email, Sending Email, Creating a simple word processor document and printing it, Scanning in a picture / adding a textual caption to it (i.e. With the gimp) / and uploading it to his website by FTP, joining an IRC channel and talking, doing instant messaging
Why's this? One of the big advantages of Linux is that anything you'd reasonably expect to find in SUPERDEDUPER TOOLS is prepackaged by your distributor.
In fact, even Windows has moved away from "go to the store and buy random crap" to "go on the net and download random crap". For most of this software, the Windows version is lower quality and shareware compared to Linux's high quality open source app.
The only real quesion is relevent commercial applications. It would be nice if you could go to BestBuy and get Lotus Smart Suite for Linux in a box with some CDs.
But if you think about that for a bit, it's a lot smaller of an issue than you'd think. First, there's no real obstacles to releasing software like that for Linux... Loki Installer works pretty well. Second, with OpenOffice being a free download, you don't really need SmartSuite.
The "Existing Downloadable Tools are Fine" statement makes most boxed software pretty much irrelevent. Antivirus software is not an issue currently for Linux. With standard "Office Suite" stuff, eithor OpenOffice is fine or you want Microsoft Word. With graphics manipulation stuff, eithor The Gimp is fine or you want Photoshop.
We could probably make a short list of commercial software where it not being available boxed for Linux in the store really matters... but I don't think that the lack of boxed software for Linux in general is really a relvent thing holding it back from Desktop usage.