And especially when almost any site work well with IE, and a few have problems with Mozilla. IE has won the browser war, it's a sad fact, but even I am not going to switch just to be politically correct. I use IE under windows as long as it works best, and is still a free download.
There isn't a single open source product out there that doesn't exist a better commercial version of.
Oh yes, there are. Linux, FreeBSD, NetBSD, OpenBSD, XFree86, Emacs, gcc, Apache, Perl, Python, Tcl/Tk, (La)Tex, are just some examples. I am sure there are many more within the scientific communities for more specialized tasks.
Well, it was an ok idea at the time. But we all know it didn't work now. By the time netscape should start earning money on their webservers, everyone was already happy with their open source equivalents...
Well, except for the fact that he wasn't trolling, but actually had something to say. If someone were to write a thesis on Nazis and their relationship towards homesexuality, would he be trolling then?
Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 2
what happens is THE ABSOLUTE PATHS TO THE LIBRARIES GET HARD-CODED INTO THE EXECUTABLES (can you tell I hate 'ld -rpath' with a vengeance?). If you decide to move the package somewhere else, all executables will break.
I agree. This is bad.
Shouldn't binaries and libraries be installed in read-only directories, so that only root could slip in a substitute libc.so?
No, how would you add a new binary to a read-only directory then? But more seriosly, I would hate to have to be root just to load another libc.so during development.
but is this really a big enough risk to justify the torture of typing./foo all the time?
Maybe not. You are free to add . to your path if you want to (and at the end of the path is a lot safer). This is often useful during development, and developers know how to do that. Users will mostly use binaries in/bin and/usr/bin, and there is little reason to make things more unsafe by default. Add ~/bin to your path as well, and most problems go away.
I like the idea of designating a 'core' set of libraries (libc, libpthreads, etc) and binaries (ls, cp, mv, etc) that could never be over-ridden...
Why? It makes no sense to me. It would be a big hassle for developers, and it doesn't help security much, because there will always be new "standard" shared libraries (Gnome, KDE, X11, etc...). So it wouldn't really help security except in those few cases where a "standard" shared library was involved (this is like microsoft plugging just *that* security hole, leaving everything else open). But you are free to add a this as a configuration file to ld.so. There is a possibility that someone would like it. Shells with builtin "mv", "cp", "ls", etc.. already exists (albeit for a different purpose).
I don't understand why people treat "the UNIX way" as some holy order that can't evolve into anything better. UNIX is just one system some guys at Bell Labs hacked out in the 60's.
Because otherwise things will break. We like it this way, it works, it has proven itself, and we care about source compatibility with other unices as well as international standards like posix. And we care about the flexibility unix offers to replace parts we don't like.
And while I am all for improvement, having a conservative attitude towards "fixing" means that fixes that breaks more than it fixes will rightfully not be allowed to break things. On the other hand, if the fixes are truly better in every aspect, and they can emulate old behaviour if necessary, then you are not going to see many oppose them (at least not in the linux community).
Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 2
I do agree with Windows' conventions on DLL use - '.' is always in the DLL search path, and it's conventional when starting GUI programs to chdir() to their "bin" directory...
Yes, this is more user-friendly. However, it is also an enormous security risk. If someone were to put a libc.so in your current directory (which quite often is not your home directory), then the system would use that instead of standard libc.
Now, you could try to patch things up the microsoft way, fixing one hole at a time, but a better solution is to simply fix the underlying architecture, and not have . in your LD_LIBRARY_PATH.
In order to get this effect on Linux, you have to stick a boilerplate script in/usr/bin that sets LD_LIBRARY_PATH, PATH, etc
And what exactly is wrong with such a boilerplate script? It is simple to write (as you mentioned, it's all boilerplate code). It is simple to understand and modify for nonstandard installations. It is reasonably efficient (at least for anything large enough to have been modularized into separate loadable libraries). And it is a lot safer than the approach you mentioned...
I think one avenue of attack no one has considered yet is modifying/bin/sh. Instead of using a pre-set PATH, perhaps the shell should take it upon itself to search for packages with/bin/ directories, and set LD_LIBRARY_PATH to the corresponding/lib/ directory automatically...
And the reason for that is because linux is intended to be a unix. Changing the semantics of/bin/sh this much would make it into something else. (And remember, we would also have to "fix"/bin/csh,/bin/zsh,/bin/ksh, and any other shell-like program people would use. You could just as well change the semantics of the exec() syscall.)
The only problem this is going to "fix" is that of removing say 3-100 lines of simple/bin/sh code from large projects like mozilla, at the cost of increased complexity, reduced flexibility, and less security in the overall system.
The alternative of some simple boilerplate shellscript for larger programs is much better.
You have to start to think of/usr/bin not as the directory where all your executables go, but simply a directory of command names that are accessible to the shell...
And surprisingly, here we seem to agree. I don't really see the purpose of putting everything in/usr/bin, and/usr/lib. Large packages/projects/subsystems/whatever should live in their own package directory (and whether it would be/usr/foo,/opt/foo,/usr/pkg/foo, or something else I don't care about, as long as package maintainers agree on it).
Shellscripts can be used to set up the execution environment (current working directory, library load path, path for executables unlikely to be of interest to end-users, etc). Symlinks can be used for everything else (manpages, etc...)
The best way to learn is to do a project that is somewhat "bigger" than the usual small assignments.
My favourite is to have them implement a simple recursive-descent parser for a minimalist computer language. This is not hard at all, and given that you can limit the scope sufficiently (e.g: a command-line calculator), it should be possible to have as a four-week assignment (assuming you have already teached them about ifs, while-loops, and recursion).
Another great example is a small computer game. You could either choose the silly variant (paper-rock-scissor), or a more advanced variant (tetris, snake, asteroids, space invaders, pacman) using simple graphics. Write the graphics-routines yourself, and have them put in the game-code.
A simple trick for making your students do larger projects, but limit the work, is to write everything yourself first, and then delete the lines you think they should be able to do, and replace them with a comment about what they should insert there. It's very efficient for learning.
Well, I found lclint too much hassle for what it was worth.
But that might be because I only use C for nasty low-level code. E.g. to implement a reference-counted pointer scheme, I would have to fight with lint on all kinds of "who owns this pointer" issues. And this would appear anywhere I used them in the program. I think this corresponds mostly to the third paragraph in section 4.5 of the linked to paper.
I don't think static checking is useless, in fact I am very interested in the issue, and I'd love to be proven wrong!
Do you know of some examples where lclint/plint has been used with reasonable effort to find interesting bugs (bugs that wouldn't easily show up in non-static checkers) in complex pointer-handling code (i.e. something akin to the Boehm GC, or equally awful)
This is one thing that C++ did right -- templated code is a Good Thing for maintainers, much easier to read than code that uses function pointers or first-order functions.
Funny, I would tend to say exactly the opposite. Aside from syntax issues and verbose compiler errors, template'd code is hard to step through in a debugger, it doesn't work too well with separate compilation, and most C++ compilers are quite buggy, biting your ass if you try something too fancy.
That doesn't mean I don't find C++ templates useful or interesting. Eventually these issues will get sorted out, maybe with a new language, or maybe just with new and better tools. But so far, they have rightfully proven themselves as a nightmare for the maintenance programmer (at least in my book).
Well, compiling a 50MB source tree with purify doesn't exactly make the resulting program a speed demon either. But I agree it works better then ElectricFence.
On the other hand, ElectricFence is very unintrusive. For small to medium-sized programs and/or libraries, you can use it in every compile, saving you the trouble of fixing those bugs later.
I would recommend them both. Always use ElectricFence, then use Purify to find those additional nasty bugs...
Given the security off IE, Outlook, and IIS, I wouldn't be very surprised if they own large amounts of stock in some of the AV companies. But then again, that might be considered paranoid.
At least it's obvious that Microsoft doesn't worry much about their credibility when it comes to technical issues such as this, and experience shows that the customers doesn't care (at least not with the part of the brain controlling the wallet)
Internet Explorer has a so completely inadequate security model, that it is far from unlikely that anything as bad will show up anywhere else (such as linux). While you can probably write malicious code for executing arbitrary code in almost any networked application, that doesn't mean it's especially easy, or even realistic. With Outlook, Outlook Express, Internet Explorer and Internet Information Server however, it is.
Now, if someone sends me a virus to an email account I read my unix machine, my email-client is not likely to execute the virus with full rights, just to give me a nice preview. Outlook and Outlook Express, on the other hand, is.
The sad fact is that writing a world-devastating email virus is patently simple, and anyone with basic knowledge of windows scripting can do it. So far, developers for Unix has been smarter to build in at least some form of basic rudimentary security (while they might not lock the door entirely, at least there is a door there).
I am not saying that linux-viruses of this kind can never exist. All it takes is (1) a bunch of stupid programmers writing an equally stupid email-program for unix as Outlook Express. Then you need (2) some equally stupid packagers for a major distribution such as redhat, making this silly email-program the default. Then you need (3) lots of gullible users to trust RedHat. And then you need (4) enough of those gullible users for the virus to spread as effectively as a typical Outlook virus.
Scenario (3) is very likely. (4) is not likely in the short term. (2) is very unlikely, and even (1) is unlikely given that most people pondering about writing email-clients have learned something from the failures of microsoft.
I am not sure what you think gcc has to do with this.
Thompson's hack would work just as well with gcc as any other compiler. I don't think there's any practical way of being completely sure of not being attacked in this way.
As someone who has worked with a lot of programming languages, I can tell you that source code conversion is no easy job. And pattern matching is certainly not going to make it (believe me). And just making a parse tree from the 4GL code, and unparse it in java syntax is also a doomed approach. You also need to simulate the underlying execution model of your 4GL language. (PS: Whether they use Rexx or some other language, and whether they use OO, procedural, functional or rule-based programming is beside the point, they could all be made to work well).
And of course, the politics in the situation is a real problem. You obviously have the wrong contract, if they can keep going on without even rudimentary simple regression tests. And if you hired them to make a converter instead of converting your code, you are also doomed (unless you can really afford to pay up until their converter is finished, which it will never be).
First of all, you should stop paying them. You can also consider suing them for incompetence (although that is unfortunately not possible in most countries, so you should consult your lawiers and try to find a contractual break instead).
Then you should consider your options.
Convert manually. This is fail-safe, but likely to be expensive, boring, and take a lot of time.
Fully automated conversion. This is likely to be very expensive, but it should be possible to sell the service later on.
Half-automated conversion (what you are doing now. It's likely to be a mess, but with proper care it is possible to be finished sometime, although a schedule is hard to come up with, and as you know by now, a contract is hard to write if you decide to outsource it (remember: proper care!))
Don't convert at all, keep using old code (that would be best)
Use binary linking (JNI) to access stuff in old code, so you can use it from java (depending on source language, this can be pretty easily done in a half-automated manner. It is not very safe, but if you can limit yourself to a relatively small interface, it could work well).
Use CORBA or some other (COM,DCOM,RMI) technology instead of binary linking to do the same thing. This would probably be better, but it depends on a lot of different factors.
Make a partial or complete implementation of the entire 4GL programming environment in J2EE and use the old source code unchanged (or with minor manual changes). This could be simpler than code-conversion, and like option 2, it can be sold later on.
Don't reuse, write a completely new system in J2EE, but while that will take some time, make sure you keep maintaining the old system all the way through.
Personally, I would recommend option 4. If you use option 8, it can be combined with option 5 and/or 6 in the initial stages, you might be happy with the result. I would believe option 7 would be easier than option 2 or 3, and a partial solution would also be easier to maintain. But I would prefer both 3 and 1 to option 2.
But anyway, this is a high-risk project, and with high-risk projects, you don't put all your eggs in one basket. Whatever you do, make sure that you maintain and keep using the original implementation, untill you have something you are happy with (or at least think you can see the light at the end of the tunnel). Try different options to see what is likely to work before you put a lot of money into it. And if you already spend a lot in something that is likely to fail, stop doing that untill you are sure you want to pursue this direction at the cost of abandoning the others.
I can. There's not that many using Perl 4 now, is there? (Well, there are some, and so there will be with Perl 5 when Perl 6 comes out, but I hardly think the community will not move to Perl 6.
And in case you need backward compatibility, I would be very surprised if you can't import a "perl5" module to get back to something more similar to perl5 syntax and semantics.
All fine and dandy, but does it have the nifty card-reader feature where you bring your desktop along to the next machine?
Let's make it better than the sun box though:
- Hard Drive [computernirvana.com]: $65.
- Floppy Drive [computernirvana.com]: $9.
- CD Burner [computernirvana.com]: $67.
Total: $512 and this does far more than the Sunray.
Yes, it now has a harddisk that can fail, a useless floppy drive, and a cd-burner allowing employees to spend time maintaining their music collection instead of actual work. But does it still have the nifty features of Sun Ray?
More video performance is always needed with age, vendors obsolete proprietary old hardware by not providing necessary software upgrades, network standards change, people spill coffee into them, people stuff postit notes in silly places, people destroy the buttons, they stack telephone books on them, stack books to block the fan, stop the fan with pens when its too noisy, open them to "fix" them -- there's way more, but I'm not interested in reliving the pain.:-)
Yes, but there are fewer parts to destroy with a Sun Ray. Anyway, people who deliberately damage the fan should probably pay for repair themselves.
BTW: Speaking as someone who has worked as computer support staff for a college with over 1000 terminals, I can tell you that software is one of the least worries. Computers, even though most parts don't move, do "wear out" -- parts either fail or stupid people beat the crap out of the computers.
Yes, and that's why it's worth a little more to get something without moving parts.
It isn't about license, it is about the origins of the code. GPL is a license, GNU is a project to make an operating system (GNU's not Unix - remember?)
Mainly, linux is built and made possible with GNU tools, and it achieves it's usefullness with GNU tools. It seems pretty obvious that tools such as gcc, libc, binutils, fileutils, and bash was more important to linux initial success than XFree86, *BSD, Gnome, KDE, Perl, Python, Apache, Mozilla or OpenOffice.
In fact, it can be argued that the GNU toolchain is an even more important part of the linux system then the kernel itself (which could be replaced with Hurd, *BSD, or one of the other millions of OS kernels in existence).
On the other hand, to believe that people are going to say "GNU/Linux" instead of the much simpler "linux" just for political reasons, even if they agree with the politics is pretty stupid.
Had he instead tried to get people to pronounce it as "gnulix", "gnulux", "gnilix" or "gnilux" he might have been more successfull. But of course, a better idea would be to simply let people call it whatever they already are.
Well, if you really interpret "logical" as "has familiar-sounding and easy to guess names for basic commands", then I would agree with you.
But in this context it would be more appropriate to interpret "logical" as "coherent, fitting together, making sense as a whole", and in that respect, unix seems to be way ahead of VMS.
But really, is "TYPE/PAGE" more logical than "cat | more"? In unix, all you need to know about is that there exists a program called "cat" and one called "more", and that plumbing can put them together. And you can use this knowledge for other programs than "cat", such as "ls". In VMS you will have to consult the manual for "TYPE" to find out that it has the option "/PAGE". Now, it might be a common convention, but are you really sure every program has a "/PAGE" option? The same can be said about many unix features, such as the shell parsing wild-cards, backticks, xargs, etc...
Small tools fitting well together strikes me as something more fitting for the label of "logical", than something that is user-friendly only for beginners, and becomes a mess for more advanced users.
But then again, I've never really used VMS (although I did read a manual once), so I might be totally wrong after all:-)
If you own the work, you should probably not share it with others. There are perfectly ok ways to protect files from others while still have access to them as yourself remotely. Most common file-transfer software has such things as password-protection (e.g. ftp, smb,...)
On the other hand, if you downloaded it from a file-sharing network, then you can just pretend to be ignorant. ("Oh, is this file copyrighted? Sorry, I'll delete it at once!")
Well, if it's like a 20 page nested if/switch-statement, then comments like that are not superflous, even if you use a good editor. Of course, I don't think 20 page nested if/switch-statements are a good thing, but I have encountered them before. (I had to use indent, a printer and a ruler to see the program-flow). And sometimes you don't have the time or energy to refactor it all (although I would refactor the things I was working on). In that case, adding a few comments like that can really help the people who have to look at the code after you (now you just have to hope that people will not invalidate those comments when they are adding more cruft, because there is hardly a more confusing thing then comments out of date, or simply misleading comments).
DOVARK? I guess you mean dvorak? It was designed for typewriters as well. (although it is newer, and has been quite succesfull at creating a myth of it's superiority, despite the lack of any good scientific studies to back this claim).
I will help speed up your typing, if you are using an alphabet with more than 26 characters, which most languages except english do.
Typically, in european languages, the new letters would be accented and diacriticated (is that a word?) versions of the normal letters. So T9 technology would help finding the correct version of the letter with the help of a dictionary. I imagine this would help non-latin alphabets as well, such as hebrew, cyrillic, etc...
Also, it will reduce the number of guesses T9 would have to do. For short words, there are often several candidates, where each letter can be one of three letters (or more). So you have to scroll through a list to find the correct one. If your input is more accurate to begin with, the list of candidate words will be shorter.
...and you don't really need anymore than "good enough"...
...then WHY DON'T YOU JUST PICK ONE?
If all you want to do is display simple "good-enough" 2D-animation, any 2D-toolkit would do. If you want zooming, etc, you will probably have to write that yourself, I can't imagine what features a 2D-toolkit could offer, that would avoid you having to write the actual code for display.
Slashdot Mirror
And especially when almost any site work well with IE, and a few have problems with Mozilla. IE has won the browser war, it's a sad fact, but even I am not going to switch just to be politically correct. I use IE under windows as long as it works best, and is still a free download.
Oh yes, there are. Linux, FreeBSD, NetBSD, OpenBSD, XFree86, Emacs, gcc, Apache, Perl, Python, Tcl/Tk, (La)Tex, are just some examples. I am sure there are many more within the scientific communities for more specialized tasks.
Well, it was an ok idea at the time. But we all know it didn't work now. By the time netscape should start earning money on their webservers, everyone was already happy with their open source equivalents...
Well, except for the fact that he wasn't trolling, but actually had something to say. If someone were to write a thesis on Nazis and their relationship towards homesexuality, would he be trolling then?
I agree. This is bad.
Shouldn't binaries and libraries be installed in read-only directories, so that only root could slip in a substitute libc.so?
No, how would you add a new binary to a read-only directory then? But more seriosly, I would hate to have to be root just to load another libc.so during development.
but is this really a big enough risk to justify the torture of typing ./foo all the time?
Maybe not. You are free to add . to your path if you want to (and at the end of the path is a lot safer). This is often useful during development, and developers know how to do that. Users will mostly use binaries in /bin and /usr/bin, and there is little reason to make things more unsafe by default. Add ~/bin to your path as well, and most problems go away.
I like the idea of designating a 'core' set of libraries (libc, libpthreads, etc) and binaries (ls, cp, mv, etc) that could never be over-ridden...
Why? It makes no sense to me. It would be a big hassle for developers, and it doesn't help security much, because there will always be new "standard" shared libraries (Gnome, KDE, X11, etc...). So it wouldn't really help security except in those few cases where a "standard" shared library was involved (this is like microsoft plugging just *that* security hole, leaving everything else open). But you are free to add a this as a configuration file to ld.so. There is a possibility that someone would like it. Shells with builtin "mv", "cp", "ls", etc.. already exists (albeit for a different purpose).
I don't understand why people treat "the UNIX way" as some holy order that can't evolve into anything better. UNIX is just one system some guys at Bell Labs hacked out in the 60's.
Because otherwise things will break. We like it this way, it works, it has proven itself, and we care about source compatibility with other unices as well as international standards like posix. And we care about the flexibility unix offers to replace parts we don't like.
And while I am all for improvement, having a conservative attitude towards "fixing" means that fixes that breaks more than it fixes will rightfully not be allowed to break things. On the other hand, if the fixes are truly better in every aspect, and they can emulate old behaviour if necessary, then you are not going to see many oppose them (at least not in the linux community).
Yes, this is more user-friendly. However, it is also an enormous security risk. If someone were to put a libc.so in your current directory (which quite often is not your home directory), then the system would use that instead of standard libc.
Now, you could try to patch things up the microsoft way, fixing one hole at a time, but a better solution is to simply fix the underlying architecture, and not have . in your LD_LIBRARY_PATH.
In order to get this effect on Linux, you have to stick a boilerplate script in /usr/bin that sets LD_LIBRARY_PATH, PATH, etc
And what exactly is wrong with such a boilerplate script? It is simple to write (as you mentioned, it's all boilerplate code). It is simple to understand and modify for nonstandard installations. It is reasonably efficient (at least for anything large enough to have been modularized into separate loadable libraries). And it is a lot safer than the approach you mentioned...
I think one avenue of attack no one has considered yet is modifying /bin/sh. Instead of using a pre-set PATH, perhaps the shell should take it upon itself to search for packages with /bin/ directories, and set LD_LIBRARY_PATH to the corresponding /lib/ directory automatically...
And the reason for that is because linux is intended to be a unix. Changing the semantics of /bin/sh this much would make it into something else. (And remember, we would also have to "fix" /bin/csh, /bin/zsh, /bin/ksh, and any other shell-like program people would use. You could just as well change the semantics of the exec() syscall.)
The only problem this is going to "fix" is that of removing say 3-100 lines of simple /bin/sh code from large projects like mozilla, at the cost of increased complexity, reduced flexibility, and less security in the overall system.
The alternative of some simple boilerplate shellscript for larger programs is much better.
You have to start to think of /usr/bin not as the directory where all your executables go, but simply a directory of command names that are accessible to the shell...
And surprisingly, here we seem to agree. I don't really see the purpose of putting everything in /usr/bin, and /usr/lib. Large packages/projects/subsystems/whatever should live in their own package directory (and whether it would be /usr/foo, /opt/foo, /usr/pkg/foo, or something else I don't care about, as long as package maintainers agree on it).
Shellscripts can be used to set up the execution environment (current working directory, library load path, path for executables unlikely to be of interest to end-users, etc). Symlinks can be used for everything else (manpages, etc...)
My favourite is to have them implement a simple recursive-descent parser for a minimalist computer language. This is not hard at all, and given that you can limit the scope sufficiently (e.g: a command-line calculator), it should be possible to have as a four-week assignment (assuming you have already teached them about ifs, while-loops, and recursion).
Another great example is a small computer game. You could either choose the silly variant (paper-rock-scissor), or a more advanced variant (tetris, snake, asteroids, space invaders, pacman) using simple graphics. Write the graphics-routines yourself, and have them put in the game-code.
A simple trick for making your students do larger projects, but limit the work, is to write everything yourself first, and then delete the lines you think they should be able to do, and replace them with a comment about what they should insert there. It's very efficient for learning.
But that might be because I only use C for nasty low-level code. E.g. to implement a reference-counted pointer scheme, I would have to fight with lint on all kinds of "who owns this pointer" issues. And this would appear anywhere I used them in the program. I think this corresponds mostly to the third paragraph in section 4.5 of the linked to paper.
I don't think static checking is useless, in fact I am very interested in the issue, and I'd love to be proven wrong!
Do you know of some examples where lclint/plint has been used with reasonable effort to find interesting bugs (bugs that wouldn't easily show up in non-static checkers) in complex pointer-handling code (i.e. something akin to the Boehm GC, or equally awful)
Funny, I would tend to say exactly the opposite. Aside from syntax issues and verbose compiler errors, template'd code is hard to step through in a debugger, it doesn't work too well with separate compilation, and most C++ compilers are quite buggy, biting your ass if you try something too fancy.
That doesn't mean I don't find C++ templates useful or interesting. Eventually these issues will get sorted out, maybe with a new language, or maybe just with new and better tools. But so far, they have rightfully proven themselves as a nightmare for the maintenance programmer (at least in my book).
On the other hand, ElectricFence is very unintrusive. For small to medium-sized programs and/or libraries, you can use it in every compile, saving you the trouble of fixing those bugs later.
I would recommend them both. Always use ElectricFence, then use Purify to find those additional nasty bugs...
At least it's obvious that Microsoft doesn't worry much about their credibility when it comes to technical issues such as this, and experience shows that the customers doesn't care (at least not with the part of the brain controlling the wallet)
It is probably a typo. Read suid instead of chroot, and you'll be happy.
Internet Explorer has a so completely inadequate security model, that it is far from unlikely that anything as bad will show up anywhere else (such as linux). While you can probably write malicious code for executing arbitrary code in almost any networked application, that doesn't mean it's especially easy, or even realistic. With Outlook, Outlook Express, Internet Explorer and Internet Information Server however, it is.
Now, if someone sends me a virus to an email account I read my unix machine, my email-client is not likely to execute the virus with full rights, just to give me a nice preview. Outlook and Outlook Express, on the other hand, is.
The sad fact is that writing a world-devastating email virus is patently simple, and anyone with basic knowledge of windows scripting can do it. So far, developers for Unix has been smarter to build in at least some form of basic rudimentary security (while they might not lock the door entirely, at least there is a door there).
I am not saying that linux-viruses of this kind can never exist. All it takes is (1) a bunch of stupid programmers writing an equally stupid email-program for unix as Outlook Express. Then you need (2) some equally stupid packagers for a major distribution such as redhat, making this silly email-program the default. Then you need (3) lots of gullible users to trust RedHat. And then you need (4) enough of those gullible users for the virus to spread as effectively as a typical Outlook virus.
Scenario (3) is very likely. (4) is not likely in the short term. (2) is very unlikely, and even (1) is unlikely given that most people pondering about writing email-clients have learned something from the failures of microsoft.
Thompson's hack would work just as well with gcc as any other compiler. I don't think there's any practical way of being completely sure of not being attacked in this way.
And of course, the politics in the situation is a real problem. You obviously have the wrong contract, if they can keep going on without even rudimentary simple regression tests. And if you hired them to make a converter instead of converting your code, you are also doomed (unless you can really afford to pay up until their converter is finished, which it will never be).
First of all, you should stop paying them. You can also consider suing them for incompetence (although that is unfortunately not possible in most countries, so you should consult your lawiers and try to find a contractual break instead).
Then you should consider your options.
Personally, I would recommend option 4. If you use option 8, it can be combined with option 5 and/or 6 in the initial stages, you might be happy with the result. I would believe option 7 would be easier than option 2 or 3, and a partial solution would also be easier to maintain. But I would prefer both 3 and 1 to option 2.
But anyway, this is a high-risk project, and with high-risk projects, you don't put all your eggs in one basket. Whatever you do, make sure that you maintain and keep using the original implementation, untill you have something you are happy with (or at least think you can see the light at the end of the tunnel). Try different options to see what is likely to work before you put a lot of money into it. And if you already spend a lot in something that is likely to fail, stop doing that untill you are sure you want to pursue this direction at the cost of abandoning the others.
And in case you need backward compatibility, I would be very surprised if you can't import a "perl5" module to get back to something more similar to perl5 syntax and semantics.
You may not have noticed, but Apple has done exactly this.
All fine and dandy, but does it have the nifty card-reader feature where you bring your desktop along to the next machine?
Let's make it better than the sun box though:
Total: $512 and this does far more than the Sunray.
Yes, it now has a harddisk that can fail, a useless floppy drive, and a cd-burner allowing employees to spend time maintaining their music collection instead of actual work. But does it still have the nifty features of Sun Ray?
More video performance is always needed with age, vendors obsolete proprietary old hardware by not providing necessary software upgrades, network standards change, people spill coffee into them, people stuff postit notes in silly places, people destroy the buttons, they stack telephone books on them, stack books to block the fan, stop the fan with pens when its too noisy, open them to "fix" them -- there's way more, but I'm not interested in reliving the pain. :-)
Yes, but there are fewer parts to destroy with a Sun Ray. Anyway, people who deliberately damage the fan should probably pay for repair themselves.
BTW: Speaking as someone who has worked as computer support staff for a college with over 1000 terminals, I can tell you that software is one of the least worries. Computers, even though most parts don't move, do "wear out" -- parts either fail or stupid people beat the crap out of the computers.
Yes, and that's why it's worth a little more to get something without moving parts.
It isn't about license, it is about the origins of the code. GPL is a license, GNU is a project to make an operating system (GNU's not Unix - remember?)
Mainly, linux is built and made possible with GNU tools, and it achieves it's usefullness with GNU tools. It seems pretty obvious that tools such as gcc, libc, binutils, fileutils, and bash was more important to linux initial success than XFree86, *BSD, Gnome, KDE, Perl, Python, Apache, Mozilla or OpenOffice.
In fact, it can be argued that the GNU toolchain is an even more important part of the linux system then the kernel itself (which could be replaced with Hurd, *BSD, or one of the other millions of OS kernels in existence).
On the other hand, to believe that people are going to say "GNU/Linux" instead of the much simpler "linux" just for political reasons, even if they agree with the politics is pretty stupid.
Had he instead tried to get people to pronounce it as "gnulix", "gnulux", "gnilix" or "gnilux" he might have been more successfull. But of course, a better idea would be to simply let people call it whatever they already are.
But in this context it would be more appropriate to interpret "logical" as "coherent, fitting together, making sense as a whole", and in that respect, unix seems to be way ahead of VMS.
But really, is "TYPE /PAGE" more logical than "cat | more"? In unix, all you need to know about is that there exists a program called "cat" and one called "more", and that plumbing can put them together. And you can use this knowledge for other programs than "cat", such as "ls". In VMS you will have to consult the manual for "TYPE" to find out that it has the option "/PAGE". Now, it might be a common convention, but are you really sure every program has a "/PAGE" option? The same can be said about many unix features, such as the shell parsing wild-cards, backticks, xargs, etc...
Small tools fitting well together strikes me as something more fitting for the label of "logical", than something that is user-friendly only for beginners, and becomes a mess for more advanced users.
But then again, I've never really used VMS (although I did read a manual once), so I might be totally wrong after all :-)
On the other hand, if you downloaded it from a file-sharing network, then you can just pretend to be ignorant. ("Oh, is this file copyrighted? Sorry, I'll delete it at once!")
Well, if it's like a 20 page nested if/switch-statement, then comments like that are not superflous, even if you use a good editor. Of course, I don't think 20 page nested if/switch-statements are a good thing, but I have encountered them before. (I had to use indent, a printer and a ruler to see the program-flow). And sometimes you don't have the time or energy to refactor it all (although I would refactor the things I was working on). In that case, adding a few comments like that can really help the people who have to look at the code after you (now you just have to hope that people will not invalidate those comments when they are adding more cruft, because there is hardly a more confusing thing then comments out of date, or simply misleading comments).
DOVARK? I guess you mean dvorak? It was designed for typewriters as well. (although it is newer, and has been quite succesfull at creating a myth of it's superiority, despite the lack of any good scientific studies to back this claim).
Typically, in european languages, the new letters would be accented and diacriticated (is that a word?) versions of the normal letters. So T9 technology would help finding the correct version of the letter with the help of a dictionary. I imagine this would help non-latin alphabets as well, such as hebrew, cyrillic, etc...
Also, it will reduce the number of guesses T9 would have to do. For short words, there are often several candidates, where each letter can be one of three letters (or more). So you have to scroll through a list to find the correct one. If your input is more accurate to begin with, the list of candidate words will be shorter.
...then WHY DON'T YOU JUST PICK ONE?
If all you want to do is display simple "good-enough" 2D-animation, any 2D-toolkit would do. If you want zooming, etc, you will probably have to write that yourself, I can't imagine what features a 2D-toolkit could offer, that would avoid you having to write the actual code for display.