If you force convergence towards a single set of APIs for everything, you destroy any usefulness that the study of computer science and its related fields can offer.
How so? The API (the interface) does not prescribe how its implemented. Implementation can always vary.
Furthermore, new APIs can be considered at any time. However, a standard interface never changes in a way that breaks compatibility.
Having said that, we already have a set of standard APIs for threading and most OS-level operations. It's called POSIX.:) Does every *nix support all of it? No. But they all support it better than Win32 does.
POSIX conformance is not just a matter of supporting a specific function, but also if the function behaves according to the standard. On GNU, Linux, et al., this is still being worked on.
Not so long ago, Linux provided a poor implementation of the POSIX standards (especially regarding threads, signals, and asynchronous I/O), and was far behind BSD, Solaris and AIX. Solaris too suffered from many problems. For some years, AIX was the only UNIX-like OS that I've seen that provided a reasonable implementation of these features. BSD also seemed pretty good when I used it for some years. Gladly for us developers, Linux has been catching up in the past years, however. Manual pages have been cleaned up to provide less misleading information also, a good development.
The POSIX subsystem of Windows is (like Windows) of poor quality, and is not fully installed by default. I still remember the times when fork() didn't work (don't know if they fixed it). Methinks, Microsoft should throw out their proprietary kernels and use a UNIX-like kernel (a BSD, Linux, or Mach kernel). The Windows program loader and task scheduler still have some serious defects (as of Windows Vista). Like, it's not possible to terminate a process cleanly from the outside (disrupts DLL reference counters, for instance), programs are loaded in whole (leading to catastrophic performance during startup), and the task scheduler often switches away from a process for a long time (often with 50 ms delay whereas on Linux it's below the 1 ms granularity level), which makes it difficult to write timing sensitive applications on Windows.
Finally, we've had a standard windowing system (and associated GUI toolkit) since late 1987. It's called X11. I don't understand why Apple and MSFT decided to reinvent the wheel.;)
Me neither!;)
Microsoft made some grave mistakes during the 80ies, which are still affecting us today. Like, a virtual machine (while slow at that time), could have provided 32-bit environments already on 16-bit CPUs (a lesson learnt decades ago, in the 60ies, from the computers that existed back then: in a resource-constrained environment, provide a virtual environment circumventing the constraints). At least a 32-bit DOS could have been developed (Microsoft made an alliance with IBM on OS/2 but neglected its DOS). Thus, a number of incompatible DOS-extenders emerged, providing at least 32-bit addressing on 32-bit CPUs. Thus, Windows 1.x-3.x had to support 16-bit, and thus were written mostly with 16-bit environments in mind. There existed a 32-bit extension, called Win32s, but it was hardly used, for, at the time, 32-bit OSes had already been available from Microsoft. The idiocy goes on and on...
A UNIX-like Windows could have saved the industry trillions of dollars, and hundreds of thousands of businesses would not have gone bankrupt due to costs related to Windows problems.
What API are you talking about? (...) are you talking about the numerous sanity and feature-presence checks that cmake and autotools much do due to differing APIs and software loads between various platforms and sites?
Exactly that. Hundreds of thousands up to millions of different API functions exported by ten thousands of libraries in their many (often incompatible) versions.
There must be a consolidation of some sort someday, a convergence towards a predictable set of APIs. This is already happening, but at the current pace it will take years or decades to complete.
There's an easy way to deal with that... target a single platform and software load.
That's not an option if a program must be portable.
I haven't seen this. The apps on my system are written in one of: C, Python, Perl, C++, Ruby, Java. (I have exactly one Java application on my systems: Azureus (nee Vuze).)
Then you've missed out on the recent software industry trend towards C# even on Unix platforms (through Mono, a.NET clone).
Regardless, how does moving away from C/C++ to Java resolve this "standard API" issue that you're talking about? Perhaps a more specific definition of "standard API" would be helpful.
API = application programming interface
Standard API = standard application programming interface
As of now, there are a few select development environments that meet these criteria to some extent: Shell scripts (KSH et al), Perl, PHP, JavaScript (in web browsers), Java, and C#. This is because the languages and their libraries are more or less standardized, varying only little between versions (but even that can be a portability hurdle).
The C and C++ have been standardized too late a point in time, and the shock waves are still perceivable. Only in the past few years, compilers like GCC reached halfways compliance with C and C++ standards. Especially on UNIX-like systems, adoption of standards has been slow. Add to that the ineptitude of the standards comittees to provide standard libraries for vital aspects of real-world programming like multithreading and graphical user interfaces. Merely C/C++ bindings to existing standards in these parts would have been sufficient, perhaps with a reference implementation.
I've been working with C since 1986 and with C++ since 1992, and I have seen plenty of changes. It is funny how slow things can evolve in this fast-paced industry.
Thanks. I'll see to it. Tools like CMake cannot solve the underlying problem however: The non-existence of a standard API that is upward compatible to previous versions. The GNU build system encouraged proliferation of incompatible interfaces. I only need to look at the size of such tools like CMake to know the extent of the problem. Many UNIX applications are written in Java and C# nowadays to circumvent the problem a little, but even there it exists. Doth man ever learn from the past?
p.s.: OS/2 also supported DOS applications. On the other hand, Windows NT supported DOS, Windows 3.x, and OS/2 1.x applications in addition to POSIX applications (I don't know if that's still available in Vista, but on XP at least all of that still worked). Windows 95/98/ME were hybrid 16/32 Bit systems that had good support for DOS and Windows 3.1 apps.
Yeah, SFU is notoriously undersupported. Better than the Cygwin junk in any case. Come to think of it, Microsoft wasted a grand chance to integrate some UNIX basics into Windows. Imagine for example, if we were able to run X apps right out of the box. Windows is such a waste!
The difference between the BSD ports system and the Linux package management systems is that BSD ports are compiled natively. After using FreeBSD and OpenBSD for years, I found that the ports system does have its uses. Precompiled packages have the advantage that they can be installed right away. The ports system has the disadvantage that the default options selected for a package might not be the best choice. I often found myself editing some file before compiling a port. But the clear advantage of the solution is that options that do exist are often unavailable on systems that depend on prepackaging (like most Linux distros). The BSD package managers are OK, but they do indeed lack some features often found in Linux package managers (like auto-deletion of related packages). It is in any case advisable to read the FreeBSD manual chapters for the ports collection and the package management system. Both have their uses, advantages and disadvantages. The BSDs have become a lot simpler to use in the past years, and progress is being made everywhere just like in the Linux world. But if you want a "real UNIX", BSD is a much better choice. At least it doesn't claim it's not UNIX, like GNU does!;-) Once you get OpenBSD to run to your liking, for instance, you'll know this system will run forever, and you'll know exactly which files to modify to get what you want. For instance, OpenBSD uses XDM which is easy to write session scripts for. I have written a couple of small programs that allow me to choose the window or desktop manager after logging in. It's fun!;-)
GCC and the whole configure/automake crap are a nightmare to deal with (not to mention that there still is no decent documentation for the whole configure/automake process). A replacement for GCC would be a good start. BTW, for portability efforts, one should take a look at the work of Dr. Martin Richards from the university of Cambridge UK. He invented BCPL, the - more or less - direct ancestor of C, and had a system for portability called INTCODE already in 1967, that - if used in this or similar form nowadays - would be a millionfold more simple and effective than the current GNU build mechanism. Sun reinvented the wheel and called it "JVM"... INTCODE was grand. I once had a runtime system built on it that I moved from Amiga to Windows to OS/2 within minutes... the INTCODE interpreter being just a small ANSI C program... the runtime system being modules based on INTCODE that just had to be COPIED. Man, just thinking about it is sort of comical...
What's the problem with typing "man ls" to read the manual? The BSDs at least come with all necessary manpages preinstalled. No searching for manpage packages. Every package you install automatically includes the manpages. And graphical manpage browsers like the good old "xman" have some use as well, especially when browsing for system calls...
The point with PCs is, that higher chipset and mainboard integration has led to less reliable hardware. Old 8-bit computers like the VIC-20 still run today without any problems (after more than 25 years). Systems like the Amiga were already more prone to failure (I have an A-1000 that died after more than 20 years). Old PCs like the old AT bus (ISA) 386/486/Pentium machines do still work (if the CMOS backup battery can be replaced). High-speed Pentium 4 boxes often have a mainboard failure within five years. Of course this depends on how well the system is protected from the elements like heat, etc. But definitely nowadays you can't plug just anything together and expect it to work for 20 years.
IBM offers i-Series servers (OS/400) for business applications which should have a long life as well. p-Series (AIX) servers aren't bad either. In any case, IBM hardware should be more reliable than PC hardware. I'm sure they offer spare part storage as a service as well (if it's not already included in the price). But IBM has a reputation for abandoning its products. I don't know if a proper contract can protect a customer from that.
If the hardware is still running, there's technically no need to purchase new computers. You could replace the 500 MB drives with up to 4 GB ones (Win95 can handle that much). Do an inventory of all applications installed on the machines, and reinstall them after setting up fresh Windows 95. Or use a tool that can copy a smaller drive to a larger one. If the software works and everything, it should be best left as is. A new system might offer more speed and storage space, and reliability, but the custom application might not run anymore. There are solutions like virtualization, but you could also use Linux running DOSBox (which are both free). DOS applications are very picky when it comes to their runtime environment, so you should test your solution with your father's programs and data on a separate machine first. For durability, I have no idea what to recommend you. PC hardware has become a bit less reliable in the past years. You might try a PowerPC solution (which requires less powerful hardware), and run OpenBSD or something on it. DOSBox or QEmu might be suitable for running DOS apps on BSD. OpenBSD has the advantage that it never changes until you change it, there's no update ever until you do it manually. Another solution might be FreeBSD, which should also work very reliably. For longevity, I would abstain from all things Windows. Recent Windows platforms like XP or Vista that require activation may fail to be reactivated when Microsoft switches off its servers. Also, Windows Updates for a particular platform might be no longer available at some point. So, using a UNIX-like system might be the best idea. If you use Linux, switch off the automatic update feature to avoid breaking the system by update (does happen sometimes). I would use OpenBSD or FreeBSD for a system that needs to last for a long time.
Well, I must admit RMS personally influenced me on this. He told me in a 1995 e-mail to say "GNU/Linux", not "Linux". I'll read up on the controversy, thanks for the link.
it is also an echo of the "infectious licence giving away control" bullshit
No. To me, GNU is one community, and not many unrelated splinter groups. Of course, every group within the community has their own identity, goals, etc., but ultimately, they're contributing to one big goal. It's just a, say, unifying approach.
Their costs may drop but are we going to see a reduction in price?
The featured article talks about exactly that. HP currently develops a technology to print the backplane and E-Ink film. This will drop the prices in the long run below those of LCDs, and we'll get flexible plastic displays with E-Ink technology.
Does it run Linux? Yes, it does!:)
The developer kit for E-Ink comes with a display and Linux. There's also an X driver for the new E-Ink GPU already.
Color displays are also in the make, but that might take another 2 years or so.
Well, any project is free to choose its licenses, its build tools and so on. As long as GNU is involved, its part of the GNU "project". The purpose of GNU is not "ownership", it is to provide a unified UNIX-like platform for applications to run on. In a sense it is like Java, except GNU has that convoluted build process that requires compiling. And GNU does not protect one from platform dependencies (like when an application is using Linux/BSD/Hurd system calls directly). At least, all "GNU" applications (those that use the GPL, the build process, etc.), share one common thing: They're free open-source software. Thus, the scope of GNU is far bigger than just a handful of people working directly for GNU. It encompasses all developers contributing to the GNU infrastructure. It's huge, it's swift, and it will kill Windows.
In addition to my other reply, one can regard every application running on GNU as part of the GNU infrastructure, as every application running on Windows is part of the Windows infrastructure. Insofar is it possible to consider GNU as the operating system and Linux as the kernel of the operating system. Furthermore, most GPL-ed applications use the GNU build process (and build tools), the GNU libraries and the GNU compilers. Even on systems like BSD (where GNU is sometimes considered as encumbering), GNU tools and applications using GNU are everywhere. If you want to be GNU-free, you have to create your own C/C++ compiler, linker, shells, shell tools, runtime libraries in addition to the kernel. Also, if you wish not to be associated with the FSF, perhaps you shouldn't use a license with a FSF copyright in it. But that's just my opinion right, who am I to talk to you wisecrack.
Well, I'm not a lawyer, but the GPL affiliates anyone who uses it with the FSF and the GNU project. But that's only my opinion, and as a developer using that license, I don't care about it.
Everything under a GPL license is part of the GNU project. That includes Xorg, GNOME, etc. Have a look at the GNU Packages page. GNOME is called the "GNU Desktop".
What if they offered Linus Torvalds a billion dollars for the trademark and the copyright to his code?
The Linux kernel is only a part of a GNU/Linux system. Almost everything, including the kernel, has been published under the GNU General Public License (cf. GNU).
Linus Torvalds is still the figurehead of Linux kernel development, but even if Microsoft would manage to purchase all rights to the Linux kernel, that would have little impact, because the Linux kernel has already been published under the GPL, which makes it legal to modify it and keep it under the GPL forever, no matter if there also would be a proprietary version.
The GNU project (which contains all free Linux software including the Linux kernel) also develops their own Mach-based kernel, called "Hurd" (the OS would be called GNU/Hurd then).
Even if Microsoft would manage to purchase Richard Stallman, the head of GNU, it would have little impact on free software development, since all code that already exists can be forked away before any proprietary branches would emerge.
goodness knows what else is going on, but it's very very powerful but unfortunately with that power and flexibility of design comes a whopping great overhead. and no you can't cache the results very much because someone might revoke a user's right to CREATE_PROCESS and they'd get a bit unhappy about that not being obeyed.
That's sort of dumb to go through all this overhead every time, instead of just distributing all changes asynchronously to the affected entities. How about a subscriber/subscription based security event model? No wonder that Windows is so slow, if it is so dumb. It's called "optimization strategies".
Maybe you should be looking for Linux support instead. That, or maybe you should just accept that you have no legal path to watch Blu-Ray, and that you either need to boycott Blu-Ray, or accept that you will be committing an act of civil disobedience every time you watch a movie.
There's a 32 bit version of PowerDVD for Ubuntu Linux in the Canonical store. Quite legally so, if you ask me.:)
Let's hope they'll make Debian version someday (I went to Debian 5 today, haven't tried to install any of my commercial Ubuntu apps yet).
Some software manufacturers make Linux software that runs on many Linux distros. Like, Renoise and Nero seem to run anywhere.
I gladly pay for commercial Linux software if I can, often those products are even considerably more affordable than their Windows versions.
There *IS* a market for Linux software, and it is evolving. Many software companies are hiring Linux staff already.
will there ever be a way to watch blue-ray movies legally on a Linux computer?
Yup, there already is a version of PowerDVD for Linux that can play Blu-Ray disks. Available in the Canonical Store (Ubuntu Linux, 32 Bit only).
Debian 5 is apparently (haven't tried this yet) one step ahead of Ubuntu in a related area however: It natively supports Blu-ray data disks (like, for backups, and so on). On Ubuntu, you have to use either some command-line tools or get Nero 3 for Linux.
You see, there's some stuff if you're looking!;)
BTW, I'm posting this from Debian 5. Yay! As a developer, I welcome the fully functional version of the Anjuta IDE, and some other fun stuff!:)
Strange... can't you simply remove the hard drive (or other medium), put in a new one, and then install the OS? Or is the problem some chip on a hardware level?
No idea what you want to say, but if you want to install Ubuntu Linux, check out their website. You can get rid of any other Linux or Windows on your box, if you really want to. To remove an operating system, you don't need an installation disk. You simply wipe the disk, and install a different OS. The OS installer normally provides an option to format your installation medium. Of course, you need to save all your data before you do that, otherwise, it's gone.
Slashdot Mirror
If you force convergence towards a single set of APIs for everything, you destroy any usefulness that the study of computer science and its related fields can offer.
How so? The API (the interface) does not prescribe how its implemented. Implementation can always vary.
Furthermore, new APIs can be considered at any time. However, a standard interface never changes in a way that breaks compatibility.
Having said that, we already have a set of standard APIs for threading and most OS-level operations. It's called POSIX. :) Does every *nix support all of it? No. But they all support it better than Win32 does.
POSIX conformance is not just a matter of supporting a specific function, but also if the function behaves according to the standard. On GNU, Linux, et al., this is still being worked on.
Not so long ago, Linux provided a poor implementation of the POSIX standards (especially regarding threads, signals, and asynchronous I/O), and was far behind BSD, Solaris and AIX. Solaris too suffered from many problems. For some years, AIX was the only UNIX-like OS that I've seen that provided a reasonable implementation of these features. BSD also seemed pretty good when I used it for some years. Gladly for us developers, Linux has been catching up in the past years, however. Manual pages have been cleaned up to provide less misleading information also, a good development.
The POSIX subsystem of Windows is (like Windows) of poor quality, and is not fully installed by default. I still remember the times when fork() didn't work (don't know if they fixed it). Methinks, Microsoft should throw out their proprietary kernels and use a UNIX-like kernel (a BSD, Linux, or Mach kernel). The Windows program loader and task scheduler still have some serious defects (as of Windows Vista). Like, it's not possible to terminate a process cleanly from the outside (disrupts DLL reference counters, for instance), programs are loaded in whole (leading to catastrophic performance during startup), and the task scheduler often switches away from a process for a long time (often with 50 ms delay whereas on Linux it's below the 1 ms granularity level), which makes it difficult to write timing sensitive applications on Windows.
Finally, we've had a standard windowing system (and associated GUI toolkit) since late 1987. It's called X11. I don't understand why Apple and MSFT decided to reinvent the wheel. ;)
Me neither! ;)
...
Microsoft made some grave mistakes during the 80ies, which are still affecting us today. Like, a virtual machine (while slow at that time), could have provided 32-bit environments already on 16-bit CPUs (a lesson learnt decades ago, in the 60ies, from the computers that existed back then: in a resource-constrained environment, provide a virtual environment circumventing the constraints). At least a 32-bit DOS could have been developed (Microsoft made an alliance with IBM on OS/2 but neglected its DOS). Thus, a number of incompatible DOS-extenders emerged, providing at least 32-bit addressing on 32-bit CPUs. Thus, Windows 1.x-3.x had to support 16-bit, and thus were written mostly with 16-bit environments in mind. There existed a 32-bit extension, called Win32s, but it was hardly used, for, at the time, 32-bit OSes had already been available from Microsoft. The idiocy goes on and on
A UNIX-like Windows could have saved the industry trillions of dollars, and hundreds of thousands of businesses would not have gone bankrupt due to costs related to Windows problems.
What API are you talking about? (...) are you talking about the numerous sanity and feature-presence checks that cmake and autotools much do due to differing APIs and software loads between various platforms and sites?
Exactly that. Hundreds of thousands up to millions of different API functions exported by ten thousands of libraries in their many (often incompatible) versions. There must be a consolidation of some sort someday, a convergence towards a predictable set of APIs. This is already happening, but at the current pace it will take years or decades to complete.
There's an easy way to deal with that... target a single platform and software load.
That's not an option if a program must be portable.
I haven't seen this. The apps on my system are written in one of: C, Python, Perl, C++, Ruby, Java. (I have exactly one Java application on my systems: Azureus (nee Vuze).)
Then you've missed out on the recent software industry trend towards C# even on Unix platforms (through Mono, a .NET clone).
Regardless, how does moving away from C/C++ to Java resolve this "standard API" issue that you're talking about? Perhaps a more specific definition of "standard API" would be helpful.
API = application programming interface
Standard API = standard application programming interface
As of now, there are a few select development environments that meet these criteria to some extent: Shell scripts (KSH et al), Perl, PHP, JavaScript (in web browsers), Java, and C#. This is because the languages and their libraries are more or less standardized, varying only little between versions (but even that can be a portability hurdle).
The C and C++ have been standardized too late a point in time, and the shock waves are still perceivable. Only in the past few years, compilers like GCC reached halfways compliance with C and C++ standards. Especially on UNIX-like systems, adoption of standards has been slow. Add to that the ineptitude of the standards comittees to provide standard libraries for vital aspects of real-world programming like multithreading and graphical user interfaces. Merely C/C++ bindings to existing standards in these parts would have been sufficient, perhaps with a reference implementation.
I've been working with C since 1986 and with C++ since 1992, and I have seen plenty of changes. It is funny how slow things can evolve in this fast-paced industry.
Thanks. I'll see to it. Tools like CMake cannot solve the underlying problem however: The non-existence of a standard API that is upward compatible to previous versions. The GNU build system encouraged proliferation of incompatible interfaces. I only need to look at the size of such tools like CMake to know the extent of the problem. Many UNIX applications are written in Java and C# nowadays to circumvent the problem a little, but even there it exists. Doth man ever learn from the past?
p.s.: OS/2 also supported DOS applications. On the other hand, Windows NT supported DOS, Windows 3.x, and OS/2 1.x applications in addition to POSIX applications (I don't know if that's still available in Vista, but on XP at least all of that still worked). Windows 95/98/ME were hybrid 16/32 Bit systems that had good support for DOS and Windows 3.1 apps.
OS/2 did have native 16-bit support, both for OS/2 and Windows 3.x applications.
Yeah, SFU is notoriously undersupported. Better than the Cygwin junk in any case. Come to think of it, Microsoft wasted a grand chance to integrate some UNIX basics into Windows. Imagine for example, if we were able to run X apps right out of the box. Windows is such a waste!
The difference between the BSD ports system and the Linux package management systems is that BSD ports are compiled natively. After using FreeBSD and OpenBSD for years, I found that the ports system does have its uses. Precompiled packages have the advantage that they can be installed right away. The ports system has the disadvantage that the default options selected for a package might not be the best choice. I often found myself editing some file before compiling a port. But the clear advantage of the solution is that options that do exist are often unavailable on systems that depend on prepackaging (like most Linux distros). The BSD package managers are OK, but they do indeed lack some features often found in Linux package managers (like auto-deletion of related packages). It is in any case advisable to read the FreeBSD manual chapters for the ports collection and the package management system. Both have their uses, advantages and disadvantages. The BSDs have become a lot simpler to use in the past years, and progress is being made everywhere just like in the Linux world. But if you want a "real UNIX", BSD is a much better choice. At least it doesn't claim it's not UNIX, like GNU does! ;-) Once you get OpenBSD to run to your liking, for instance, you'll know this system will run forever, and you'll know exactly which files to modify to get what you want. For instance, OpenBSD uses XDM which is easy to write session scripts for. I have written a couple of small programs that allow me to choose the window or desktop manager after logging in. It's fun! ;-)
GCC and the whole configure/automake crap are a nightmare to deal with (not to mention that there still is no decent documentation for the whole configure/automake process). A replacement for GCC would be a good start. BTW, for portability efforts, one should take a look at the work of Dr. Martin Richards from the university of Cambridge UK. He invented BCPL, the - more or less - direct ancestor of C, and had a system for portability called INTCODE already in 1967, that - if used in this or similar form nowadays - would be a millionfold more simple and effective than the current GNU build mechanism. Sun reinvented the wheel and called it "JVM" ... INTCODE was grand. I once had a runtime system built on it that I moved from Amiga to Windows to OS/2 within minutes ... the INTCODE interpreter being just a small ANSI C program ... the runtime system being modules based on INTCODE that just had to be COPIED. Man, just thinking about it is sort of comical ...
What's the problem with typing "man ls" to read the manual? The BSDs at least come with all necessary manpages preinstalled. No searching for manpage packages. Every package you install automatically includes the manpages. And graphical manpage browsers like the good old "xman" have some use as well, especially when browsing for system calls ...
The point with PCs is, that higher chipset and mainboard integration has led to less reliable hardware. Old 8-bit computers like the VIC-20 still run today without any problems (after more than 25 years). Systems like the Amiga were already more prone to failure (I have an A-1000 that died after more than 20 years). Old PCs like the old AT bus (ISA) 386/486/Pentium machines do still work (if the CMOS backup battery can be replaced). High-speed Pentium 4 boxes often have a mainboard failure within five years. Of course this depends on how well the system is protected from the elements like heat, etc. But definitely nowadays you can't plug just anything together and expect it to work for 20 years.
IBM offers i-Series servers (OS/400) for business applications which should have a long life as well. p-Series (AIX) servers aren't bad either. In any case, IBM hardware should be more reliable than PC hardware. I'm sure they offer spare part storage as a service as well (if it's not already included in the price). But IBM has a reputation for abandoning its products. I don't know if a proper contract can protect a customer from that.
If the hardware is still running, there's technically no need to purchase new computers. You could replace the 500 MB drives with up to 4 GB ones (Win95 can handle that much). Do an inventory of all applications installed on the machines, and reinstall them after setting up fresh Windows 95. Or use a tool that can copy a smaller drive to a larger one. If the software works and everything, it should be best left as is. A new system might offer more speed and storage space, and reliability, but the custom application might not run anymore. There are solutions like virtualization, but you could also use Linux running DOSBox (which are both free). DOS applications are very picky when it comes to their runtime environment, so you should test your solution with your father's programs and data on a separate machine first. For durability, I have no idea what to recommend you. PC hardware has become a bit less reliable in the past years. You might try a PowerPC solution (which requires less powerful hardware), and run OpenBSD or something on it. DOSBox or QEmu might be suitable for running DOS apps on BSD. OpenBSD has the advantage that it never changes until you change it, there's no update ever until you do it manually. Another solution might be FreeBSD, which should also work very reliably. For longevity, I would abstain from all things Windows. Recent Windows platforms like XP or Vista that require activation may fail to be reactivated when Microsoft switches off its servers. Also, Windows Updates for a particular platform might be no longer available at some point. So, using a UNIX-like system might be the best idea. If you use Linux, switch off the automatic update feature to avoid breaking the system by update (does happen sometimes). I would use OpenBSD or FreeBSD for a system that needs to last for a long time.
Well, I must admit RMS personally influenced me on this. He told me in a 1995 e-mail to say "GNU/Linux", not "Linux". I'll read up on the controversy, thanks for the link.
it is also an echo of the "infectious licence giving away control" bullshit
No. To me, GNU is one community, and not many unrelated splinter groups. Of course, every group within the community has their own identity, goals, etc., but ultimately, they're contributing to one big goal. It's just a, say, unifying approach.
Their costs may drop but are we going to see a reduction in price?
The featured article talks about exactly that. HP currently develops a technology to print the backplane and E-Ink film. This will drop the prices in the long run below those of LCDs, and we'll get flexible plastic displays with E-Ink technology.
:)
Does it run Linux? Yes, it does!
The developer kit for E-Ink comes with a display and Linux. There's also an X driver for the new E-Ink GPU already.
Color displays are also in the make, but that might take another 2 years or so.
Well, any project is free to choose its licenses, its build tools and so on. As long as GNU is involved, its part of the GNU "project". The purpose of GNU is not "ownership", it is to provide a unified UNIX-like platform for applications to run on. In a sense it is like Java, except GNU has that convoluted build process that requires compiling. And GNU does not protect one from platform dependencies (like when an application is using Linux/BSD/Hurd system calls directly). At least, all "GNU" applications (those that use the GPL, the build process, etc.), share one common thing: They're free open-source software. Thus, the scope of GNU is far bigger than just a handful of people working directly for GNU. It encompasses all developers contributing to the GNU infrastructure. It's huge, it's swift, and it will kill Windows.
In addition to my other reply, one can regard every application running on GNU as part of the GNU infrastructure, as every application running on Windows is part of the Windows infrastructure. Insofar is it possible to consider GNU as the operating system and Linux as the kernel of the operating system. Furthermore, most GPL-ed applications use the GNU build process (and build tools), the GNU libraries and the GNU compilers. Even on systems like BSD (where GNU is sometimes considered as encumbering), GNU tools and applications using GNU are everywhere. If you want to be GNU-free, you have to create your own C/C++ compiler, linker, shells, shell tools, runtime libraries in addition to the kernel. Also, if you wish not to be associated with the FSF, perhaps you shouldn't use a license with a FSF copyright in it. But that's just my opinion right, who am I to talk to you wisecrack.
Well, I'm not a lawyer, but the GPL affiliates anyone who uses it with the FSF and the GNU project. But that's only my opinion, and as a developer using that license, I don't care about it.
Everything under a GPL license is part of the GNU project. That includes Xorg, GNOME, etc. Have a look at the GNU Packages page. GNOME is called the "GNU Desktop".
What if they offered Linus Torvalds a billion dollars for the trademark and the copyright to his code?
The Linux kernel is only a part of a GNU/Linux system. Almost everything, including the kernel, has been published under the GNU General Public License (cf. GNU).
Linus Torvalds is still the figurehead of Linux kernel development, but even if Microsoft would manage to purchase all rights to the Linux kernel, that would have little impact, because the Linux kernel has already been published under the GPL, which makes it legal to modify it and keep it under the GPL forever, no matter if there also would be a proprietary version.
The GNU project (which contains all free Linux software including the Linux kernel) also develops their own Mach-based kernel, called "Hurd" (the OS would be called GNU/Hurd then).
Even if Microsoft would manage to purchase Richard Stallman, the head of GNU, it would have little impact on free software development, since all code that already exists can be forked away before any proprietary branches would emerge.
goodness knows what else is going on, but it's very very powerful but unfortunately with that power and flexibility of design comes a whopping great overhead. and no you can't cache the results very much because someone might revoke a user's right to CREATE_PROCESS and they'd get a bit unhappy about that not being obeyed.
That's sort of dumb to go through all this overhead every time, instead of just distributing all changes asynchronously to the affected entities. How about a subscriber/subscription based security event model? No wonder that Windows is so slow, if it is so dumb. It's called "optimization strategies".
Maybe you should be looking for Linux support instead. That, or maybe you should just accept that you have no legal path to watch Blu-Ray, and that you either need to boycott Blu-Ray, or accept that you will be committing an act of civil disobedience every time you watch a movie.
There's a 32 bit version of PowerDVD for Ubuntu Linux in the Canonical store. Quite legally so, if you ask me. :)
Let's hope they'll make Debian version someday (I went to Debian 5 today, haven't tried to install any of my commercial Ubuntu apps yet).
Some software manufacturers make Linux software that runs on many Linux distros. Like, Renoise and Nero seem to run anywhere.
I gladly pay for commercial Linux software if I can, often those products are even considerably more affordable than their Windows versions.
There *IS* a market for Linux software, and it is evolving. Many software companies are hiring Linux staff already.
will there ever be a way to watch blue-ray movies legally on a Linux computer?
Yup, there already is a version of PowerDVD for Linux that can play Blu-Ray disks. Available in the Canonical Store (Ubuntu Linux, 32 Bit only).
;)
:)
Debian 5 is apparently (haven't tried this yet) one step ahead of Ubuntu in a related area however: It natively supports Blu-ray data disks (like, for backups, and so on). On Ubuntu, you have to use either some command-line tools or get Nero 3 for Linux.
You see, there's some stuff if you're looking!
BTW, I'm posting this from Debian 5. Yay! As a developer, I welcome the fully functional version of the Anjuta IDE, and some other fun stuff!
Me too! :)
Strange ... can't you simply remove the hard drive (or other medium), put in a new one, and then install the OS? Or is the problem some chip on a hardware level?
No idea what you want to say, but if you want to install Ubuntu Linux, check out their website. You can get rid of any other Linux or Windows on your box, if you really want to. To remove an operating system, you don't need an installation disk. You simply wipe the disk, and install a different OS. The OS installer normally provides an option to format your installation medium. Of course, you need to save all your data before you do that, otherwise, it's gone.