I've been using ext3 ever since I upgraded to 2.4.14 a few days ago. Its nice to have the journaled FS... as I have been testing out a lot of
!cough!nvidia!cough! proprietary drivers and bleeding edge software lately, and subsequently crashing. W/ ext3, I can get back to the crashing very
quickly.
Journaling file systems cannot ensure file system consistency after a crash in kernel code. Such failures can lead to severe data corruption. In such cases, relying on a journaling file system is as safe as turning fsck off entirely. Journaling file systems only help with power failures and crashes due to OOM situations and the like.
Floating point performance doesn't tell much about integer performance and vice versa (remember the Itanium). It is well-known that GCC has got its problems with the stack-based x86 floating point unit (especially pre-3.0 versions; some people claim that 3.x is faster).
Since the kernel doesn't use floating point instructions, it's not such a big loss that you can't compile it with icc yet. In addition, compiling the kernel (which is not written in ISO C, let alone ISO C++) might uncover a few bugs in the kernel code and the compiler, and it's not very likely that the kernel folks are able or even willing to help you if you use a strange system configuration with a proprietary compiler.
Linux is a trademark of Linus Torvalds. GNU/Linux is a trademark of nobody. Despite Linus's strident claims to be disinterested, if you want to point at an
official term, it's the one Linus owns.
Only the kernel is called "Linux".
I run cygwin. Does that make it GNU/Windows?
Yes, why not? Microsoft is even selling GNU/Interix.
For what it's worth, here is what I wrote after I read Culp's essay for the first time:
I agree that some aspects of the current computer security community
are quite strange. A few parties have indeed conflicting interests:
They sell products which wrap around other software in order to
enhance its security (from a purely methodological point of few, a
questional practice in itself). In addition, these parties discover
and analyze vulnerabilities (sometimes in very great detail), and they
are clearly benefitting from the recent Microsoft worm craze.
However, a few of Scott Culp's arguments are slightly wrong and do not
reflect reality. For example, he claims,
the publication of exploit details about the vulnerabilities
contributed to their use as weapons.
Is this really true? And if it is, could it have been avoided? After
all, an attacker knows which components are vulnerable (just by
reading the vendor announcement), and he or she can compare the
machine code of the vulnerable and fixed versions. Of course, the
recent worms didn't show a very sophisticated design. But it is
really reasonable to expect that the attackers of the future are
unable to retrieve the necessary information from a few pieces machine
code?
In addition, we should remember that the most visible worms were
targeting closed-source, proprietary systems. By the same argument,
operating systems based on free software would be facing a tremendous
amount of worm-based attacks because it's much easier to write these
worms based on the publicly available information. However, there is
no evidence supporting that, and this is very unlikely that this is
just caused by different market shares.
Furthermore, Culp questions the usefulness of detailed information on
vulnerabilities to administrators:
Providing a recipe for exploiting a vulnerability doesn't aid
administrators in protecting their networks.
I whish this were true, but I have seen circumstances under which
additional information is essential, even for system administrators:
Vendors do not release complete information. Over and over again,
products are not mentioned, either due to neglect or because they
are no longer officially supported.
Vendors release vulnerable versions after a vulnerability has
become known, and after public authorities (such as CERT/CC)
have stated that these vendors do not ship vulnerable versions
of the software.
New vulnerability types might exist in a wide range of software
from different vendors, even though they do not share common code.
If code is shared, some vendors respond faster than other ones.
No vendor information might be available for some products.
This means that responsible system administrators have to check their
system themselves in order to be sure that they are not vulnerable.
Unfortunately, closed, automated tools do not help much in this
context, at least without partly re-introducing the concept of full
disclosure. Past experience suggests that the vulnerability has to be
actually tested in order to minimize the number of false negatives.
Our main concern are remote buffer overflow vulnerabilities, and even
if such a testing tool is closed-source and does not contain any
actual exploit code, it is not too difficult to snoop the network
traffic, insert the appropriate exploit code, and try the result on
some victims. In addition, testing tools require time to write and
distribute, which is unacceptable in most cases. (Usually, the
attacks start after the first advisory has been released, the
Microsoft worms are rather exceptional in this regard.)
But my favorite argument is the following one, which has been rehashed
in many, many different contexts, most of the time suggesting that
software vendors should be exempted from responsibility for the
consequences of using their products:
All non-trivial software contains bugs, and modern software systems
are anything but trivial. Indeed, they are among the most complex
things humanity has ever developed. Security vulnerabilities are here
to stay.
Nearly error-free software exists and is in wide use, but of course
not in the general-purpose computing business. There are no technical
reasons (or even mathematical ones, such as Goedel's Incompleteness
theorem) for software being faulty. There is complex software which
is believed to be close to zero defects, and Donald E. Knuth has shown
with TeX that it is possible to write such software for use on
workstations even if it uses tricky algorithms and it is fairly large.
Poor software quality has different roots, many of them related to
business models which force vendors to continuously release
substantially different software versions, in order to generate a
constant revenue stream from customers upgrading to the newest
version.
In addition, there is no evidence that the security vulnerabilities
exploited by the worms were related in any way to the overall
complexity of the system. If we look at typical buffer overflow
problems in free software (for obvious reasons, we can't do that with
Microsoft software, but there is no indication that Microsoft source
code is entirely different), these problems are local problems in
most cases, which could be caught automatically by using different
software construction tools, often obvious from local code
inspection, and a local fix was usually sufficient. If software
shows buffer overflow problems because of its overall complexity,
something is very wrong.
Indeed, security vulnerabilities will not disappear soon, but not
because of fundamental technical problems. And even if complexity
starts to become an issue, why not reduce complexity, then? Security
vulnerabilities are going to stay simply because too many people
accept them.
(And, by the way, like Windows and Solaris, Linux is a trademark, and
since we aren't talking about the kernel alone, we should probably
call this operating system "GNU/Linux".)
In addition, it seems that you have to connect your Windows XP box to the Internet in order to install security upgrades. Yes, to the Internet, you cannot download the upgrade files on a host which is not vulnerable and then transfer it to the vulnerable one (for example, over your internal network).
I wonder when Microsoft starts shipping security upgrades to their registered customers via snail mail. In the past, when I was young, I did use Microsoft products, and I received a problem notification only once: Microsoft told me not to install some kind of Access update because it would shred my databases (not that I'd used Access for any serious work). Pretty weak, because they advertised the benefits of being a paying, registered customer very aggressively (you would get support, updates, and so on, the usual story).
Microsoft is collecting enormous amounts of data about their customers. Perhaps it's time to use it not just for marketing (and perhaps scaring people off from copying their software), but for notifying customers that there are severe problems with Microsoft programs.
According to Hafner's and Lyon's "Where wizards stay up late" (an interesting read), Paul Baran was the guy who invented packet switching in the ARPANET context (he called packets "message blocks"). But AT&T (the company which eventually had to provide the communication lines) wasn't very happy about this idea, so he stopped working on this issue. About the same time, Davies started his experiments (and so did Kleinrock). Kleinrock might have considered packet switching in his very early theoretical articles on data communication, but it's not that clear that he was the first one to do practical, large-scale experiments (this was Davies, IIRC), or to consider packet switching the ARPANET context (clearly Baran).
Yes, working for an university is certainly interesting. You won't find such huge and partly unmaintained networks anywhere else. And of course, all the operating systems are not only running in test beds, but are in production use, from AIX 3 over IRIX 5.3 to the some ancient VMS version. Til the late 90s, most universities didn't even have a LAN: you just plugged the network cable into your box, and you were on the Internet. No filters, no proxy, just the bare thing. And it was pretty damn fast.
However, this might change in a few years. If security is made an official topic at such organiziations, you're going to see quite a bit of centraliziation. For example, one of the universities in Southern Germany is converting its entire network to private addresses and installing firewalls all over the campus, to split the internal network. I guess we will see more of such activity soon, and as a computer security guy (working at the local univeristy CERT), I think it's positive. However, if security is tightened, I would probably use my job (student workers are not acceptable in this area, and I tend to agree).
On the other hand, at the average university, there's a considerable amount of bureaucracy, and it's sometimes extremely annoying to cope with it. Monetary compensation is not comparable with industry jobs, either.
At the moment, User Mode Linux does separate the processes in a VM from the host system. That's because the kernel image itself is writable for the processes running in a UML virtual machine, which means that processes can break out of the virtual machine pretty easily and gain access to the account running UML on the host system. In addition, even if this is corrected (perhaps it has been during the last few weeks, I haven't checked), the kernel memory would still be read-only for the processes run by it, so different processes in the virtual machine could snoop each other. This means that User Mode Linux is great for testing stuff, but it only moderately increases security.
The patches for compartmentalization which mimic FreeBSD's jail(8) feature are completely different. If they are done properly (and checking this will require some time), they can provide complete separation of the processes running in different compartments. Performance is probably a bit better, too, because only one kernel is running, and not a stack of two.
Again, if you need compartmentalization now, and you have security concerns, you should either use FreeBSD, or GNU/Linux on S/390. This new kernel feature will need a bit of time to settle down and work correctly (from a security point of view).
Of course, this depends on the particular file system implementation. For example, the VFS layer of the Linux kernel does not permit slashes in file names.
Traditionally, people have been super careful about destructive operations and shell expansions. I don't think I've ever seen something
like this written in a 3rd party script before, in fact (let alone from the OS vendor!). This could well be an example of programmers new to
a Unix-like platform still getting used to the Unix way of doing things, and getting bitten as a result.
But even experienced UNIX users have problems to cope with the fact that on a traditional UNIX file system, file names can include all characters except '/' and NUL. For example,
find/some/path -name \*~ | xargs rm
might delete much more than you want, and it's especially dangerous to do this if you are the root user and process directories where unprivileged users have write access.
(Yes, I know, the -print0 and -0 options for find and xargs exists, at least in the GNU versions.)
Anyway, it's quite embarrassing to make such a mistake in an installer. It shows how little testing software gets nowadays before it is released. I can't imagine that this couldn't have been noticed by testing the installer on several internal machines (and not just developer ones).
No, full screen mode seems to be most practical to me, like GNU screen for X11. Perhaps some way to split the screen vertically or horizontally, but this shouldn't be the default.
Or look at GNU Emacs. I think they got the window management right.
I think that's part of the problem: With the 49, HP tried to target the mass market and pissed off their traditional users by its awkward design. There are some claims that the 49 is designed to look nice in the show room,and some features power users want (like the CST menu, which is initially empty and apparently confused buyers) were removed, so that the mass market is not frightend.
Another problem is that they didn't increase the computing power. As far as I can tell, the 49 still uses this old 4-bit SATURN process which has got registers which are 64 bits wide. Of course, you get a longer battery lifetime than with a StrongARM at 200+ MHz, but a little more speed wouldn't be too bad. (I hope HP/Compaq won't kill the iPAQ, too, this devices have the potential of becoming really useful over the time.)
I don't know if it's a good idea to buy a HP calculator now. The keyboard of my HP-48 broke down after a half of a year, and it's uncertain if you got a replacement in six months from now or so. (Perhaps the 49 is more solid, but somehow I doubt it.)
I've learned programming on a 41C and later a 41CX. Not the worst training, I think, at least I got an impression how computers really work. After all, the HP-41 programming language was rather minimal and not too far away from machine language (although, back then, you couldn't implement such an elaborated language in hardware). Synthetic programming was fun indeed.
However, towards the end of 80s, a German computer club released a special module which, unlike the PPC ROM, didn't contain HP-41 programs, but microcode. Somehow, they rewrote parts of the operating system of the calculator, and if you plugged in this module, you could assign the byte snapper just by typing ASN (Gold XEQ, IIRC) ENTER, and entering two decimal numbers. Together with the ON + ENTER soft reset function of the 41CX, synthetic programming didn't require much knowledge anymore.
Of course, in German, you can twist the word order in rather bizarre waus and it's still correct, but the "object, subject, verb" is still extremely rare and only possible in lyrics. Most of the time, it's "subject, verb, object" (main clauses), "subject, object, verb" (subclauses), "verb, subject, object" (questions).
OTOH, Latin offers far much variation, and the "adverbial phrases, objects, verb" pattern (where "verb" implicitly contains the subject) is common in more or less technical texts. However, word order is extremely flexible in Latin and depends on which part of a sentence you want to stress, so Latin can't qualify as a RPN language either.
In my experience, most Windows users no longer know that windows can be resized. They run all applications in full screen mode, and are helpless if they are confronted with window managers such as FVWM 1, and application windows pop up with the wrong size. So the Windows camp is mostly back at Windows 1.0, which lacked overlapping applications windows.
I've never understood the fuss about overlapping windows, or windows at all. For cut-and-paste using the mouse, it might be helpful to see two windows at the same time, and you might want to look at error messages while browsing the file that generated them. Same for reading documentation.
I've looked at new X window managers in the past which perform dynamic resizing of windows and other nifty stuff, but I never found them convincing because when an xterm containing a shell is resized to squelch it onto the screen, it's currently not possible to rewrap the shell output so that it remains readable.
There are other reasons why people do not give away their supported GNAT version.
What are those reasons?
Oops, sorry. Distributing software requires bandwidth and (in the GPL case) personnel to handle requests for source code. It requires consent of your legal department, and of your management.
Of course, this only applies to professional distribution. If you want to know why GNAT 3.14a1 or so hasn't leaked to the public yet, I don't know. However, usually, users respect the wishes of developers. For example, development on GNU Emacs 21 was rather closed over a long time period, too, despite the GPL.
In contrast, ACT is selling support for their GNAT technology. The exact version number of the product does not matter much if you can
contact the vendor in case of a problem, and hours later it has been analyzed, and a solution is proposed.
Do you have some basis for that assertion? In Sleepycat's case, there is a three-to-one ratio in favor of licensing over support
revenue. Do you have some verifiable reason to believe that ACT's revenue model is primarily based on support rather than on selling
software?
Robert Dewar, the CEO of Ada Core technology, happens to be a frequent contributor on comp.lang.ada, and he has explained the business model of ACT more than once over there. ACT is not in the software licensing business (apart from a experimental disgression for XML/Ada, which has already been corrected). All software gets released to the public over time, and in almost all cases, you can develop proprietary software using the public versions.
But very fundamental aspects of a computer program cannot be documented using today's programming languages! And comments are in plain English, usually, not in a programming language.
And if the project exceeds a certain size, it is essential to have proper interface documentation, and try to persuade programmers to look at the documentation before looking at the source code. The current implementation might have additional, undocumented characteristics, and if programmers write code which relies on these, it's suddenly extremely complicated to change the implementation, even if the interface was very well-designed for change in the first place.
Not everyone has got an army of volunteers to modify code affected by a simple implementation change, code affected only because people did not stick to the official interface, but peeked under the hood and discovered a new clever way to solve a problem, which is, however, dependent on the current implementation.
For projects with only limited ressources (commercial or free software without a huge developer base), interface documentation is required, and implementation details should only be examined for debugging (and there they are essential).
I'd like to, but the ACT website is not very forthcoming on the open-source question. It left me with the impression that they'd rather you
didn't know you could get GNAT for free.
Well, they clearly state that GNAT is Free Software on their Services page (in fact it's a selling argument because this means that there aren't any run-time licensing fees).
Don't disincentives to copy stand against the whole free software/open source philosophy?
Many large-scale Free Software users do not act as distributors. What's wrong with that? Of course, you could phone Boeing and beg them to send you a copy of GNAT.;-)
We get back to the issue
that the commercial value of something that can be freely copied is effectively nil.
Do you really assume that the ACT business model is built around the fact their supported customers get access to new GNAT releases 15 month ahead of non-supported customers? This is completely off target. In contrast, ACT is selling support for their GNAT technology. The exact version number of the product does not matter much if you can contact the vendor in case of a problem, and hours later it has been analyzed, and a solution is proposed.
You cannot express Ada semantics in Ada, you need a metalanguage for that. If someone has come up with such a metalanguage, fine for him, but it's not part of the Ada language (both the Ada 83 and Ada 95 don't have such a feature). In addition, I would be very surprised if the formal semantics cover the entire Ada language, since some parts of it are quite hard to formalize.
In standard Ada, there is no way to express that a subprogram has the same effect as another subprogram, at least in the general case.
Yes, but they chose to use this license. As far as I know, the DoD contract didn't enforce it, it required only that the FSF must get a copyright, too. So they could have chosen the GPL without an exception for the run-time library for the public version, and grant supported customers a completely different license.
Incidentally, ACT tried this with XML/Ada in previous versions (which was pure GPL in public versions, and GPL-with-exception in customer versions), but stopped the experiment with the most recent public GNAT release.
Similarly, for ACT, the income stream seems to be based on a similar dual licensing agreement, with the latest and greatest only
available under a proprietary license. If all software were free, they would not have sufficient revenue -- they only make money from
their software by protecting it, not by giving it away.
No, check your facts, even the GNAT version you get when you are a fully supported GNAT customer has the GPL on it (with an exception for the run-time library, but this exception is present in the public version, too). Large parts of the compiler are copyrighted by the FSF anyway (and I'm not sure if this copyright is exclusive; for the machine language backend, this is true, of course).
There are other reasons why people do not give away their supported GNAT version.
Anyway, now that GNAT 5.00w is part of the GCC CVS, we have got a completely new situation.
The commercial versions are GPL (after all, they include the GCC backend, too, which is GPLed). It's true that there isn't a public version of GNAT 3.14, but GNAT 5.00w has been released and committed to the GCC CVS.
It takes quite an amount of work to create a public release, and I can understand that public releases do not have the highest priority for ACT. Delaying the release of the public version does not encourage people to get a support contract. Either you can afford one, or you can't. The audiences for the public and customer versions are just too different.
If I understand the license situation correctly, Sleepycat makes money because others do not want to release there software as Free Software. This is slightly different from true Free Software companies such as Ada Core Technologies (ACT) which usually do not slap different licenses on public and customer versions of a software package.
In fact, Sleepycat's business model stops working if the Free Software revolution has taken place because no one would need a proprietary-compatible license for Sleepycat's software. ACT's business model continues to work because their customers still need support, and still pay for enhancements to the GNAT toolchain.
I guess Sleepycat is just an Open Source company, but not a Free Software Company.;-)
Every language I know includes methods to allow human readability (some, like Python, require them!),
Shall I show you some of my Python code?;-)
I very much doubt that an article describing a new idea about computer programming would pass the review process if it was written in,
say, C.
Then you've never read an article about computer programming. Without exception, every discussion or article of a new algorithm or
programming concept I've read includes source code.
Most of the books on my bookshelf which deal with computer programming issues do not contain much source code, only pseudo code to some extent.
But my point was that it's unusual that ground-breaking ideas or concepts are expressed using programming language constructs. In almost all cases, people nowadays use English to express the ideas behind the code, and not more source code. This is not surprising, most programming languages can't express simple statements like "This code does the same thing as code X, but it's faster in all cases (except a few degenerated ones which result in errors anyway)". You have to use natural language for this kind of stuff.
Try it. Pick a computer language you don't know, find a beginner's reference for it. I guarantee you'll find most of it includes source
code.
That's not the point. A book on a programming language does not deal with generic concepts applicable to many languages, in many situations, at least not if it's a real beginner's book and not an introductory text to computer science (like SICP). Since computer programming is more than just writing syntactically correct source code, it's not
You must be an advanced Perl programmer - it's always looked like machine code to me....
It's usually easier to figure out what a couple of lines of assembler input do than what a few lines of Perl code do.
Personally I prefer Python and coding styles
that enhance readability.
I like Ada a lot, and it is one of the few languages which favor the reader over the writer. Most programmers therefore think Ada is much too verbose and refuse to use it. (There are, of course, numerous other myths surrounding Ada which scare away people.)
True executable computer programs (compiled executables) may be intended primarily for communication with machines, but the primary
goal of many programming languages and the source code written in them is human-human communication, [...]
I whish this were true, but unfortunately, only few programmers share this view of programming. Most programmers, if not controlled tightly by coding guidelines, peer review etc., tend to write code which basically works, but which is quite hard to maintain, and not too few programmers have a show-off attitude, along the lines of "look how well I know C, I can even use multiplication with a logical expression to avoid an if statement".
Back to the topic, I can clearly see that some kind of computer programming merits freedom of expression. But this doesn't mean that computer program source code has to be protected as free speech: typewriters and paint aren't, either.
In my opinion, it's rather the act of programming which merits protection.
By the way, with the invention of literate programming, the distinction between free speech (even literary and art) and programming is not clear at all today, no need to envision a Star-Trekesque future.
Slashdot Mirror
Floating point performance doesn't tell much about integer performance and vice versa (remember the Itanium). It is well-known that GCC has got its problems with the stack-based x86 floating point unit (especially pre-3.0 versions; some people claim that 3.x is faster).
Since the kernel doesn't use floating point instructions, it's not such a big loss that you can't compile it with icc yet. In addition, compiling the kernel (which is not written in ISO C, let alone ISO C++) might uncover a few bugs in the kernel code and the compiler, and it's not very likely that the kernel folks are able or even willing to help you if you use a strange system configuration with a proprietary compiler.
For what it's worth, here is what I wrote after I read Culp's essay for the first time:
I agree that some aspects of the current computer security community are quite strange. A few parties have indeed conflicting interests: They sell products which wrap around other software in order to enhance its security (from a purely methodological point of few, a questional practice in itself). In addition, these parties discover and analyze vulnerabilities (sometimes in very great detail), and they are clearly benefitting from the recent Microsoft worm craze.
However, a few of Scott Culp's arguments are slightly wrong and do not reflect reality. For example, he claims,
Is this really true? And if it is, could it have been avoided? After all, an attacker knows which components are vulnerable (just by reading the vendor announcement), and he or she can compare the machine code of the vulnerable and fixed versions. Of course, the recent worms didn't show a very sophisticated design. But it is really reasonable to expect that the attackers of the future are unable to retrieve the necessary information from a few pieces machine code?In addition, we should remember that the most visible worms were targeting closed-source, proprietary systems. By the same argument, operating systems based on free software would be facing a tremendous amount of worm-based attacks because it's much easier to write these worms based on the publicly available information. However, there is no evidence supporting that, and this is very unlikely that this is just caused by different market shares.
Furthermore, Culp questions the usefulness of detailed information on vulnerabilities to administrators:
I whish this were true, but I have seen circumstances under which additional information is essential, even for system administrators:- Vendors do not release complete information. Over and over again,
products are not mentioned, either due to neglect or because they
are no longer officially supported.
- Vendors release vulnerable versions after a vulnerability has
become known, and after public authorities (such as CERT/CC)
have stated that these vendors do not ship vulnerable versions
of the software.
-
New vulnerability types might exist in a wide range of software
from different vendors, even though they do not share common code.
- If code is shared, some vendors respond faster than other ones.
No vendor information might be available for some products.
This means that responsible system administrators have to check their system themselves in order to be sure that they are not vulnerable.Unfortunately, closed, automated tools do not help much in this context, at least without partly re-introducing the concept of full disclosure. Past experience suggests that the vulnerability has to be actually tested in order to minimize the number of false negatives. Our main concern are remote buffer overflow vulnerabilities, and even if such a testing tool is closed-source and does not contain any actual exploit code, it is not too difficult to snoop the network traffic, insert the appropriate exploit code, and try the result on some victims. In addition, testing tools require time to write and distribute, which is unacceptable in most cases. (Usually, the attacks start after the first advisory has been released, the Microsoft worms are rather exceptional in this regard.)
But my favorite argument is the following one, which has been rehashed in many, many different contexts, most of the time suggesting that software vendors should be exempted from responsibility for the consequences of using their products:
Nearly error-free software exists and is in wide use, but of course not in the general-purpose computing business. There are no technical reasons (or even mathematical ones, such as Goedel's Incompleteness theorem) for software being faulty. There is complex software which is believed to be close to zero defects, and Donald E. Knuth has shown with TeX that it is possible to write such software for use on workstations even if it uses tricky algorithms and it is fairly large. Poor software quality has different roots, many of them related to business models which force vendors to continuously release substantially different software versions, in order to generate a constant revenue stream from customers upgrading to the newest version.In addition, there is no evidence that the security vulnerabilities exploited by the worms were related in any way to the overall complexity of the system. If we look at typical buffer overflow problems in free software (for obvious reasons, we can't do that with Microsoft software, but there is no indication that Microsoft source code is entirely different), these problems are local problems in most cases, which could be caught automatically by using different software construction tools, often obvious from local code inspection, and a local fix was usually sufficient. If software shows buffer overflow problems because of its overall complexity, something is very wrong.
Indeed, security vulnerabilities will not disappear soon, but not because of fundamental technical problems. And even if complexity starts to become an issue, why not reduce complexity, then? Security vulnerabilities are going to stay simply because too many people accept them.
(And, by the way, like Windows and Solaris, Linux is a trademark, and since we aren't talking about the kernel alone, we should probably call this operating system "GNU/Linux".)
In addition, it seems that you have to connect your Windows XP box to the Internet in order to install security upgrades. Yes, to the Internet, you cannot download the upgrade files on a host which is not vulnerable and then transfer it to the vulnerable one (for example, over your internal network).
I wonder when Microsoft starts shipping security upgrades to their registered customers via snail mail. In the past, when I was young, I did use Microsoft products, and I received a problem notification only once: Microsoft told me not to install some kind of Access update because it would shred my databases (not that I'd used Access for any serious work). Pretty weak, because they advertised the benefits of being a paying, registered customer very aggressively (you would get support, updates, and so on, the usual story).
Microsoft is collecting enormous amounts of data about their customers. Perhaps it's time to use it not just for marketing (and perhaps scaring people off from copying their software), but for notifying customers that there are severe problems with Microsoft programs.
According to Hafner's and Lyon's "Where wizards stay up late" (an interesting read), Paul Baran was the guy who invented packet switching in the ARPANET context (he called packets "message blocks"). But AT&T (the company which eventually had to provide the communication lines) wasn't very happy about this idea, so he stopped working on this issue. About the same time, Davies started his experiments (and so did Kleinrock). Kleinrock might have considered packet switching in his very early theoretical articles on data communication, but it's not that clear that he was the first one to do practical, large-scale experiments (this was Davies, IIRC), or to consider packet switching the ARPANET context (clearly Baran).
Yes, working for an university is certainly interesting. You won't find such huge and partly unmaintained networks anywhere else. And of course, all the operating systems are not only running in test beds, but are in production use, from AIX 3 over IRIX 5.3 to the some ancient VMS version. Til the late 90s, most universities didn't even have a LAN: you just plugged the network cable into your box, and you were on the Internet. No filters, no proxy, just the bare thing. And it was pretty damn fast.
However, this might change in a few years. If security is made an official topic at such organiziations, you're going to see quite a bit of centraliziation. For example, one of the universities in Southern Germany is converting its entire network to private addresses and installing firewalls all over the campus, to split the internal network. I guess we will see more of such activity soon, and as a computer security guy (working at the local univeristy CERT), I think it's positive. However, if security is tightened, I would probably use my job (student workers are not acceptable in this area, and I tend to agree).
On the other hand, at the average university, there's a considerable amount of bureaucracy, and it's sometimes extremely annoying to cope with it. Monetary compensation is not comparable with industry jobs, either.
At the moment, User Mode Linux does separate the processes in a VM from the host system. That's because the kernel image itself is writable for the processes running in a UML virtual machine, which means that processes can break out of the virtual machine pretty easily and gain access to the account running UML on the host system. In addition, even if this is corrected (perhaps it has been during the last few weeks, I haven't checked), the kernel memory would still be read-only for the processes run by it, so different processes in the virtual machine could snoop each other. This means that User Mode Linux is great for testing stuff, but it only moderately increases security.
The patches for compartmentalization which mimic FreeBSD's jail(8) feature are completely different. If they are done properly (and checking this will require some time), they can provide complete separation of the processes running in different compartments. Performance is probably a bit better, too, because only one kernel is running, and not a stack of two.
Again, if you need compartmentalization now, and you have security concerns, you should either use FreeBSD, or GNU/Linux on S/390. This new kernel feature will need a bit of time to settle down and work correctly (from a security point of view).
Of course, this depends on the particular file system implementation. For example, the VFS layer of the Linux kernel does not permit slashes in file names.
Anyway, it's quite embarrassing to make such a mistake in an installer. It shows how little testing software gets nowadays before it is released. I can't imagine that this couldn't have been noticed by testing the installer on several internal machines (and not just developer ones).
No, full screen mode seems to be most practical to me, like GNU screen for X11. Perhaps some way to split the screen vertically or horizontally, but this shouldn't be the default.
Or look at GNU Emacs. I think they got the window management right.
Another problem is that they didn't increase the computing power. As far as I can tell, the 49 still uses this old 4-bit SATURN process which has got registers which are 64 bits wide. Of course, you get a longer battery lifetime than with a StrongARM at 200+ MHz, but a little more speed wouldn't be too bad. (I hope HP/Compaq won't kill the iPAQ, too, this devices have the potential of becoming really useful over the time.)
I don't know if it's a good idea to buy a HP calculator now. The keyboard of my HP-48 broke down after a half of a year, and it's uncertain if you got a replacement in six months from now or so. (Perhaps the 49 is more solid, but somehow I doubt it.)
I've learned programming on a 41C and later a 41CX. Not the worst training, I think, at least I got an impression how computers really work. After all, the HP-41 programming language was rather minimal and not too far away from machine language (although, back then, you couldn't implement such an elaborated language in hardware). Synthetic programming was fun indeed.
However, towards the end of 80s, a German computer club released a special module which, unlike the PPC ROM, didn't contain HP-41 programs, but microcode. Somehow, they rewrote parts of the operating system of the calculator, and if you plugged in this module, you could assign the byte snapper just by typing ASN (Gold XEQ, IIRC) ENTER, and entering two decimal numbers. Together with the ON + ENTER soft reset function of the 41CX, synthetic programming didn't require much knowledge anymore.
Of course, in German, you can twist the word order in rather bizarre waus and it's still correct, but the "object, subject, verb" is still extremely rare and only possible in lyrics. Most of the time, it's "subject, verb, object" (main clauses), "subject, object, verb" (subclauses), "verb, subject, object" (questions).
OTOH, Latin offers far much variation, and the "adverbial phrases, objects, verb" pattern (where "verb" implicitly contains the subject) is common in more or less technical texts. However, word order is extremely flexible in Latin and depends on which part of a sentence you want to stress, so Latin can't qualify as a RPN language either.
In my experience, most Windows users no longer know that windows can be resized. They run all applications in full screen mode, and are helpless if they are confronted with window managers such as FVWM 1, and application windows pop up with the wrong size. So the Windows camp is mostly back at Windows 1.0, which lacked overlapping applications windows.
I've never understood the fuss about overlapping windows, or windows at all. For cut-and-paste using the mouse, it might be helpful to see two windows at the same time, and you might want to look at error messages while browsing the file that generated them. Same for reading documentation.
I've looked at new X window managers in the past which perform dynamic resizing of windows and other nifty stuff, but I never found them convincing because when an xterm containing a shell is resized to squelch it onto the screen, it's currently not possible to rewrap the shell output so that it remains readable.
Of course, this only applies to professional distribution. If you want to know why GNAT 3.14a1 or so hasn't leaked to the public yet, I don't know. However, usually, users respect the wishes of developers. For example, development on GNU Emacs 21 was rather closed over a long time period, too, despite the GPL.
Robert Dewar, the CEO of Ada Core technology, happens to be a frequent contributor on comp.lang.ada, and he has explained the business model of ACT more than once over there. ACT is not in the software licensing business (apart from a experimental disgression for XML/Ada, which has already been corrected). All software gets released to the public over time, and in almost all cases, you can develop proprietary software using the public versions.But very fundamental aspects of a computer program cannot be documented using today's programming languages! And comments are in plain English, usually, not in a programming language.
And if the project exceeds a certain size, it is essential to have proper interface documentation, and try to persuade programmers to look at the documentation before looking at the source code. The current implementation might have additional, undocumented characteristics, and if programmers write code which relies on these, it's suddenly extremely complicated to change the implementation, even if the interface was very well-designed for change in the first place.
Not everyone has got an army of volunteers to modify code affected by a simple implementation change, code affected only because people did not stick to the official interface, but peeked under the hood and discovered a new clever way to solve a problem, which is, however, dependent on the current implementation.
For projects with only limited ressources (commercial or free software without a huge developer base), interface documentation is required, and implementation details should only be examined for debugging (and there they are essential).
You cannot express Ada semantics in Ada, you need a metalanguage for that. If someone has come up with such a metalanguage, fine for him, but it's not part of the Ada language (both the Ada 83 and Ada 95 don't have such a feature). In addition, I would be very surprised if the formal semantics cover the entire Ada language, since some parts of it are quite hard to formalize.
In standard Ada, there is no way to express that a subprogram has the same effect as another subprogram, at least in the general case.
Yes, but they chose to use this license. As far as I know, the DoD contract didn't enforce it, it required only that the FSF must get a copyright, too. So they could have chosen the GPL without an exception for the run-time library for the public version, and grant supported customers a completely different license.
Incidentally, ACT tried this with XML/Ada in previous versions (which was pure GPL in public versions, and GPL-with-exception in customer versions), but stopped the experiment with the most recent public GNAT release.
There are other reasons why people do not give away their supported GNAT version.
Anyway, now that GNAT 5.00w is part of the GCC CVS, we have got a completely new situation.
The commercial versions are GPL (after all, they include the GCC backend, too, which is GPLed). It's true that there isn't a public version of GNAT 3.14, but GNAT 5.00w has been released and committed to the GCC CVS.
It takes quite an amount of work to create a public release, and I can understand that public releases do not have the highest priority for ACT. Delaying the release of the public version does not encourage people to get a support contract. Either you can afford one, or you can't. The audiences for the public and customer versions are just too different.
In fact, Sleepycat's business model stops working if the Free Software revolution has taken place because no one would need a proprietary-compatible license for Sleepycat's software. ACT's business model continues to work because their customers still need support, and still pay for enhancements to the GNAT toolchain.
I guess Sleepycat is just an Open Source company, but not a Free Software Company. ;-)
But my point was that it's unusual that ground-breaking ideas or concepts are expressed using programming language constructs. In almost all cases, people nowadays use English to express the ideas behind the code, and not more source code. This is not surprising, most programming languages can't express simple statements like "This code does the same thing as code X, but it's faster in all cases (except a few degenerated ones which result in errors anyway)". You have to use natural language for this kind of stuff.
That's not the point. A book on a programming language does not deal with generic concepts applicable to many languages, in many situations, at least not if it's a real beginner's book and not an introductory text to computer science (like SICP). Since computer programming is more than just writing syntactically correct source code, it's notBack to the topic, I can clearly see that some kind of computer programming merits freedom of expression. But this doesn't mean that computer program source code has to be protected as free speech: typewriters and paint aren't, either. In my opinion, it's rather the act of programming which merits protection.
By the way, with the invention of literate programming, the distinction between free speech (even literary and art) and programming is not clear at all today, no need to envision a Star-Trekesque future.