Put the PC in the trunk: it's more protected there and there is more room for all the things you might want to plug in. What should go into the dashboard is the user interface--a touch screen or an LCD and some buttons. A Bluetooth or WiFi-capable touch screen in an in-dash form factor, now that would be something useful.
Until then, you might be best off just sticking a Palm or PPC to your dashboard and having it talk wirelessly to your PC.
there is no need for an online voting system. Remember the rule, "if it isn't broken, don't fix it " ?
But it is broken: voting is too labor intensive, counties don't have the money, and, as Florida shows, consistency is also lacking.
I think the solution is to use paper-based electronic voting: ballots are simple, nation-wide standardized, machine-readable pages of letter-sized paper, and they are scanned and verified on the spot, in the presence of the voter. If everything is OK, the ballot gets dropped into an archival box, if not it gets destroyed and the voter gets to try again. That approach is cheap, it's easy to use, and it's auditable. It also avoids the traditional problems with paper ballots, that people may make ambiguous marks, because those get rejected by the reader right away. Hardware costs per station are under $1000, and software development is pretty simple.
The solution to this problem is well-known: use one-time passwords. You can travel with a printed list of passwords, each to be used only once. There are probably some packages for Linux that support this.
A more sophisticated version are challenge-response systems or time-based systems like SecurID, but they require extra hardware and don't give you any extra security.
If the bank thought they could save money by upgrading ATMs, they would do so, and pocket the extra money. Obviously they don't think so.
That is all very true, but that doesn't make it any better. To the bank, an occasional $2000 fraud isn't a big deal--it's a little money added on to some fees, maybe they lose the customer that was defrauded, and putting a secure ATM infrastructure in place would indeed be much more expensive. But to the person losing $2000 and spending hours on the phone trying to get the money back and trying to restore their good name, the loss is much bigger than the financial loss to the bank. That is what makes the bank's attitude so callous. In fact, banks should face stiff penalties when fraud does occur so that their financial objectives are brought in line with the harm they cause; then, they would fix ATMs.
For voting machines, the situation is even worse: there is little or no auditing or verification possible, either for individuals or auditors, and nobody loses money from misregistered votes. So, if the ATM vendors reason the same way for on-line voting as they do for banking, the kind of reasoning you applied, then they really don't care at all about security. And that's just what we are seeing. And that is exactly the reason why ATM vendors are completely unsuitable to handle these things: they have already demonstrated that they will optimize for profit, not for security. For creating on-line voting systems, we need organizations that are dedicated to security, not profit maximization.
I think voting by touch screen is wrong. Electronic voting should be paper based. That is, ballots should be simple pieces of paper that are marked clearly by pen and immediately stuck into a reading machine. The reading machine complains if there are any inconsistencies with the ballot so that the voter can go back to correct them. The paper itself is retained to allow auditing and, in narrow elections, recounting.
Paper-based electronic voting is easy to use for voters, requires far less equipment than other electronic voting, is fully auditable, and is less prone to user error than either traditional paper-based voting or touch-screen voting (neither of which really provides a double-check of the votes).
We have already known for a long time that ATMs are badly flawed as well when it comes to security. Even the basic technology is completely outdated and insecure: magnetic strips with four digit pins are just an abomination when it comes to security. The solution has been for banks to deny the problem, blame customers, and pass on any losses that result from fraud that they can't blame on customers to other customers.
So, does it come as a surprise that companies that can't produce minimally secure ATMs can't produce minimally secure voting machines either? Blaming Floridians for "hanging chads" (talk about a broken user interfaces) clearly was only the beginning.
If we want secure voting machines, ATM manufacturers are the last people to go to because they already have proven to be incapable of handling computer security. The only thing they seem to be able to do is make big, heavy metal boxes and pretend that that constitutes "security".
But I think a chunkload of built-in flash-memory wouldn't be such a bad idea Ideal for storing documents, MP3 files, whatnot. I might want to use the SD slot for other purposes.
The new Sony Clie has internal flash. But a better choice is probably to have dual expansion slots. The Zaurus and a few other handhelds do.
completely robotic fast food restaurants in 2030 (which then unemploy 3.5 million people),
It's easy to reduce labor in fast food restaurants to almost nothing already--fast-food restaurants in many countries do. The fact that fast food is labor intensive in the US has a very simple reason: unskilled labor is plentiful and cheap in the US. Smarter robots aren't going to change that equation.
BT support in Windows is pretty awful--hard to install, hard to configure, and some USB dongles don't work. But once you find a USB dongle that does work (I'm using a blue-gene.com dongle), hotsync over Bluetooth works like a charm.
BT support in OS X looked more limited but claims to support hotsyncing and appeared easier to install.
Since BT emulates serial lines, you should also be able to hotsync with Linux over BT, but I haven't tried that since it requires a more recent kernel.
How come those devices always are so cheap on internal memory? I mean, get a least 128 MB in the cheapest of MP3 players these days. So what's the problem?
The T2 "memory" is RAM, your MP3 "memory" is flash storage. The T2 doesn't come with any flash storage built-in (but you can put hundreds of megabytes of flash storage into its expansion slot).
Furthermore, until recently, PalmOS couldn't even cope with more than 16M of RAM (although it could address more flash storage).
I have had enough of your continued insinuations that I should somehow be unable to divine the true meaning of your words just because I don't agree with them
There is nothing to "divine". Terms like "undefined behavior" have a standard meaning in programming language definitions. Throwing an exception in Java does not result in "undefined behavior", while an index error in C/C++ does result in "undefined behavior".
I might as well note at this point that the way you keep obsessing over minor implementation details such as pointer and index errors just goes to show what a lousy programmer you are and how little systems programming experience you really have. If you can't even keep track of an index variable I fail to see how you could ever successfully deploy a large heterogenous system.
After nearly 30 years of programming in a dozen languages, I'm experienced to know that I cannot reliably keep track of an index variable, neither in my own code, nor in enormous amounts of third party code that I use. It is frightening for me to think that there are practicing programmers that think they can. It's still that old macho programmer ethics. Nor, frankly, even if I could, I wouldn't want to: programming languages are here to make my life easier, and if a language simplifies testing, debugging, and fault-tolerant computing, why in the world would I not use it?
That aside, and apart for the fact that you've repeatedly chosen to ignore the points I made about the primacy of prevention over protection
I haven't ignored it. Quite to the contrary: I keep pointing out that prevention obviously isn't working. You have to look no further than the Linux kernel, OpenOffice, Gnome, KDE, Mozilla, IIS, and all those other C/C++ applications that mangle data and crash with regularity.
I shall bow out at this point to leave the final word to you.
I like to see Microsoft cut down to size in court just as much as most Slashdot geeks, but this is not good. Microsoft is right: InterTrust's patents are vague. One might also add that they are pretty obvious, like InterTrust's patent Systems and methods using cryptography to protect secure computing environments, for example.
The basic problem with the "we'll all benefit" arguments relating to globalization is that they are utopian.
Did you even bother to read what I wrote? I didn't make a "we'll all benefit" argument. Quite to the contrary: I said that the US and Europe will stagnate or even suffer.
Globalization is a result of transportation and communications technologies; there is little governments can do to stop the mobility of ideas, people, information, or goods. We can't go back to protectionism or colonialism without hurting ourselves even more. The only choice we have is to make the best out of what is happening, and that means helping the poor nations catch up as fast as possible.
Now, there is one form of globalization that we can do something about: the US and Europe try to beat poor nations over the head with "free trade requirements" and all that, often to protect inefficient and outdated industries like farming and textiles at home. That is something we very much can stop. The laissez-faire approach to globalization pushed by right-wing economists where there is a level playing field won't work: developing nations just can't compete in a level playing field. One of the best things we could probably do for the long term is to drop our agricultural subsidies and import duties while, at the same time, give developing nations free reign in setting up whatever trade barriers they believe are good for their economies against our goods.
Apparently they're not teaching critical thinking or even basic common sense in the gilded MBA schools these days.
I don't know about "gilded MBA schools", but perhaps you yourself should brush up on your basic reading skills.
Since it is impossible to know what may or may not have been relinquished and what conditions may or may not have been met, at the application (or perhaps system is a better word) level, the state of the system as a whole, that is, as a situated entity with a well-defined purpose, is undefined.
Look, just because you are using "undefined" in another sense doesn't change the facts, and the facts are that at the language and runtime level, languages like Java make guarantees that C/C++ simply doesn't make.
If you don't know how to take advantage of those guarantees, so that for you undefined-at-the-language-level is the same as undefined-at-the-application-level, that's your problem. I do, however, know how to take advantage of those guarantees, as do many other programmers.
Exactly. It's not the language or the runtime per se which are responsible for horrible software.
The use of C/C++ is, of course, responsible for the bloat and flakiness in the case of OpenOffice. It is simply impossible to implement Java-like object models well in C/C++: it doesn't matter how much work you do, it doesn't matter how smart you are, C/C++ just doesn't support it. Software engineering cannot compensate for error checking that simply does not exist in the C/C++ compiler or runtime.
A good language and runtime doesn't guarantee reliable software, but an unsuitable language and runtime pretty much guarantees that you will have to spend enormous amounts of time testing and still not end up with something that you can really trust. And that is exactly what we are seeing with large C/C++-based software systems.
While Ogg is a cool thing, and I have hope that it catches on, currently it's supported by almost no consumer devices.
Ogg works on just about every PDA, meaning there are millions of consumer Ogg players out there. If companies like Apple and Creative aren't catching on, that's their problem.
AAC, on the other hand, is supported by the most popular MP3 player (iPod).
That's if you want an iPod and if you are willing to pay for it.
And why doesn't the iPod support Ogg anyway? The source for an embedded integer-based decoder is freely available. It should be trivial to create a plug-in for the iPod. The only logical explanation I see is that Apple doesn't make Ogg available for iPod for business reasons: they want to push a proprietary audio codec and DRM. Why would I want to do business with a company like that?
You can, of course, easily convert the AAC music into WAV files by "burning" them to a disk image (i.e. no reason to actually burn a CD), and re-import them as MP3's. All legal. Just don't share them!:-)
Yes, at an additional loss of quality. That was my point.
That's a spurious example. If a resource is acquired inside the plugin and never relinquished because of an unexpected error, the state of the application is undefined.
If the plugin acquires a resource and doesn't release it, at worst, that resource would be unavailable to the rest of the application; that doesn't make the state of the application "undefined".
But actually, even that doesn't happen, because resources are accessed through objects with finalizers and will get cleaned up at the latest when the garbage collector runs again.
Note, incidentally, that "undefined state" doesn't refer to some lack of knowledge the programmer may have about what happened in a module, we are talking about what the language spec guarantees. If a Java module crashes somewhere internally with an array index error, as far as the language is concerned, the program is still in a well-defined state; whether the programmer has enough knowledge to be able to recover from that is a matter of how the program was designed. If a C program makes an index error anywhere (detected or undetected), all bets are off; there is no safe way to recover from that no matter how carefully the program was designed. And, as it turns out, in languages like Java, it is fairly straightforward to design programs that can recover reliably even from completely unexpected errors, but most C programmers don't understand that because in C it is intrinsically impossible.
But I know that OpenOffice is a slow bug-riddled pig.
My point exactly. And what is OpenOffice written in? C and C++. If it were written in a more suitable language, it would be both faster and a lot simpler.
In fact, a large part of OpenOffice is just implementing in user code what something like a Java runtime implements much more efficiently: COM-like objects.
(Incidentally, while I give Java as an example, I don't recommend using Java: it's proprietary and Sun's implementation of it isn't very good. Mono is somewhat better, as are Eiffel, Modula-3, gcj, and many other languages.)
Besides which, AAC itself isn't synonymous with DRM. I can encode my own AAC files without any restrictions. Many say the quality is better than MP3 so I can get away with a smaller file size. If true, why would I use MP3 (for example)?
As I was saying, the main reasons not to use AAC are: it's not as good as Ogg at the same bitrate, and it's patented, so your choice of players is far more limited.
That's in addition to the fact that most music in AAC comes from iMusic and hence is DRM'ed.
So if you have, say, an MP3 and you want to convert it to another compressed format you lose nothing right?
Of course, you lose something if you convert from MP3 to another compressed format. But I don't have to convert MP3 or Ogg to anything else because there are lots of players and because MP3 and Ogg files aren't subject to DRM.
Here's one point you missed: the only music downloading service that is a) legal, b) involves terms that don't treat you like an outright criminal, and c) has top-shelf popular music uses AAC exclusively.
iMusic does treat me like a criminal by imposing DRM, was my point. If I were to buy from iMusic, I'd either have to break DRM (illegal), or I have to convert the AAC file to something else through analog (probably legal since there is no circumvention). And since iMusic, so far is the only reason to use AAC, I don't see any reason to use AAC at all.
It converts to AIFF just fine with no loss of quality.
But most people need to keep their files in compressed form, and if you get stuff in AAC and transcode it to something else at the same bitrate, you will usually lose quality relative to having encoded the audio in the other format in the first place.
The point is: there is no point to AAC for users; there are better, open standards out there. Whether one AAC codec is better or worse than another just doesn't make any difference: don't use any of them.
People keep whining about how jobs move out of the US and how living standards are decreasing in the US. Yes, they do, and yes they are. And so what? What is wrong with that?
The US and Europe have been incredibly lucky, being able to build very high standards of living on the basis of cheap labor and cheap raw materials from third world nations. But those third world nations are waking up and they want their fair share. That means our standards of living will probably stagnate or go down until those nations catch up.
And that's not something we can stop anyway. Colonialism is impractical--we don't have the resources anymore to conquer and suppress large numbers of third world nations. If we oppose globalization, our economies will nose-dive. That leaves embracing globalization. But we don't have a lot of competitive advantages anymore: folks in India are smart and well-educated, and they have lower costs of living, so of course they are going to be successful and compete with us.
Overall, this means our standard of living will stagnate or even go down until the rest of the world catches up. The best thing we can do is embrace this trend and help other nations improve their standard of living quickly.
why should a bunch of people from all over the world be able to clone expensive microsoft software and give it away for free ?
Because that's the way our economy works: Microsoft didn't invent any of that stuff themselves either, they cloned Apple, AT&T, Xerox, and IBM, among many others. Products in the real world work by imitation and modification (kind of like evolution works in biology).
(What your point has to do with paying taxes, I don't get.)
So one company has the best implementation of a mediocre, DRM-crippled, patented audio codec. So, why do I care?
And even if I gave in and were to buy AAC audio on-line and even if I could use the best AAC implementation and even if that were better than some other codec, I'd lose that quality anyway when converting that AAC audio format into a more usable format.
Which is largely irrelevant in determining the state of the application as a whole. Were all transactions properly closed? Were all privileges relinquished?
In a properly written program in a well-designed high-level language, yes, transactions will be properly closed and privileges will be relinquished. Consider:
When the code reaches "after", I can know with certainty that the privilege has been relinquished, no matter what happened in the plug-in.
And the whole point of transactions is that if you don't complete them, the world won't change, so there is nothing to "close"; the resources associated with the transaction will be freed through the usual cleanup actions in a language like C# or Java.
Generally when you encounter an unexpected error the only sensible thing to do is to terminate the application. Regardless of language.
For C, that is true, for other languages, it is just false.
We're much better off addressing them at the kernel level through orthogonal persistance and a more powerful process abstraction. Some hardware assistance wouldn't hurt either.
People have tried for decades to address them at the kernel level and at the hardware level and it hasn't worked out: trying to do fine-grained fault isolation at the OS or hardware level is far, far too inefficient. Fault isolation at the language level yields much more efficient software (there are a bunch of papers you can dig up on the subject).
Note also that just because a language provides fault isolation doesn't mean that you can't disable it selectively--in well-tested code. For example, in something like C# or Modula-3, you might turn off index checking in the inner loop of a BLAS implementation. Then, you can focus your testing on only those bits of unsafe code. Furthermore, software that loads components can determine whether the components it tries to load are fault-isolated or not and make decisions accordingly.
Software is slow enough as it is.
Software is slow because it is written in unsafe languages: unsafe languages require clumsy and inefficient fault isolation mechanisms (processes, IPC), and they greatly interfere with the ability of programmers to optimize and design for performance.
When a particular programming practice makes it hard to rule out errors, the answer is not to design a fault-tolerant language; the answer is to avoid the practice.
There are no fault-tolerant languages. But there is fault-tolerant programming and languages that support fault-tolerant programming. C does not support fault tolerant programming, and that is exactly the problem with C.
That's obviously what I'm referring to: it's a 100M of binary code corresponding probably to millions of lines of messy C source code. And the notion that a 100M binary install is "lean" is itself absurd.
Also, the overhead of an interpreted language is inappropriate for the kind of command that's expected to be ran often and not take up too much time (like most of the applications found in various toolchains on unix)
That's silly: most of the stuff in a base OS install either is not performance critical at all, or it is I/O bound. You could rewrite init, cron, ps, sendmail, ftpd, apcid, lpd, rpc.mountd, xinit, and almost all other of the programs in a base install in an interpreted language, and system performance would probably improve (because of much better VM sharing) and install size would decrease.
C is used extensively throughout the base operating system, in nearly all applications it's faster, it's proven over the course of decades, and it's very widely understood. Why switch to perl?
The notion that "C [...] is faster" is ridiculous; most C programs are probably a lot slower than they would be if an equivalent amount of time had been spent writing them in a decent high-level language because C makes it so much work to build complex data structures or try different implementations and because C debugging and testing takes so much time compared to high-level languages. The BSD and Linux kernels, as well as many of those "efficient" C programs you area thinking of are full of linear search over potentially large data structures because it's so much more work to do anything better in C. And mostly what has been proven about C is that just about any significant C program has serious pointer and memory management bugs.
C has shown to be particularly unsuitable to building component based software: software built from a framework with dynamically loadable components really needs to be robust against buggy components. What are examples of component based software? The Linux kernel, MS Office, the Gimp, OpenOffice, Mozilla, and lots more. That's why Microsoft is betting on C#--the only way to build large, reliable, component-based systems is to use a language with fault isolation, reliable error detection, and reflection.
My general point is: much more stuff should be in interpreted languages in UNIX/Linux/BSD systems, in a decent, high-level interpreted language. An all-C/shell base install is just the wrong direction. Whether that language is Perl or something else, I don't really care. Perl is probably technically the worst language you could pick, but it is also the most commonly used one.
And, in fact, large parts of systems like the Gnome desktop are written in interpreted high-level languages, so it's not even a question of whether it's happening. It's only some misguided notion of "minimalism" that causes the "base installs" to buck the trend. Of course, again, the notion that there is anything "lean" about a 100M binary install anyway is just laughable.
Yeah, Perl is icky, but everybody else manages to ship it, so why not FreeBSD?
In any case, Python, Ruby, whatever, would be fine, too. But/bin/sh with ANSI C is not fine.
This is bare, and I like it that way.
The notion that 100 megs of ANSI C code is "bare" strikes me as absurd. Just because you don't see the incredible mess that's under the covers because you don't install sources doesn't mean the mess isn't there.
Perl was just being used in fewer and fewer places...
Yes, and that's the problem. Operating systems should use more VHLLs, not less. Whether that VHLL Perl or something else, I really don't care.
Slashdot Mirror
Put the PC in the trunk: it's more protected there and there is more room for all the things you might want to plug in. What should go into the dashboard is the user interface--a touch screen or an LCD and some buttons. A Bluetooth or WiFi-capable touch screen in an in-dash form factor, now that would be something useful.
Until then, you might be best off just sticking a Palm or PPC to your dashboard and having it talk wirelessly to your PC.
there is no need for an online voting system. Remember the rule, "if it isn't broken, don't fix it " ?
But it is broken: voting is too labor intensive, counties don't have the money, and, as Florida shows, consistency is also lacking.
I think the solution is to use paper-based electronic voting: ballots are simple, nation-wide standardized, machine-readable pages of letter-sized paper, and they are scanned and verified on the spot, in the presence of the voter. If everything is OK, the ballot gets dropped into an archival box, if not it gets destroyed and the voter gets to try again. That approach is cheap, it's easy to use, and it's auditable. It also avoids the traditional problems with paper ballots, that people may make ambiguous marks, because those get rejected by the reader right away. Hardware costs per station are under $1000, and software development is pretty simple.
The solution to this problem is well-known: use one-time passwords. You can travel with a printed list of passwords, each to be used only once. There are probably some packages for Linux that support this.
A more sophisticated version are challenge-response systems or time-based systems like SecurID, but they require extra hardware and don't give you any extra security.
If the bank thought they could save money by upgrading ATMs, they would do so, and pocket the extra money. Obviously they don't think so.
That is all very true, but that doesn't make it any better. To the bank, an occasional $2000 fraud isn't a big deal--it's a little money added on to some fees, maybe they lose the customer that was defrauded, and putting a secure ATM infrastructure in place would indeed be much more expensive. But to the person losing $2000 and spending hours on the phone trying to get the money back and trying to restore their good name, the loss is much bigger than the financial loss to the bank. That is what makes the bank's attitude so callous. In fact, banks should face stiff penalties when fraud does occur so that their financial objectives are brought in line with the harm they cause; then, they would fix ATMs.
For voting machines, the situation is even worse: there is little or no auditing or verification possible, either for individuals or auditors, and nobody loses money from misregistered votes. So, if the ATM vendors reason the same way for on-line voting as they do for banking, the kind of reasoning you applied, then they really don't care at all about security. And that's just what we are seeing. And that is exactly the reason why ATM vendors are completely unsuitable to handle these things: they have already demonstrated that they will optimize for profit, not for security. For creating on-line voting systems, we need organizations that are dedicated to security, not profit maximization.
I think voting by touch screen is wrong. Electronic voting should be paper based. That is, ballots should be simple pieces of paper that are marked clearly by pen and immediately stuck into a reading machine. The reading machine complains if there are any inconsistencies with the ballot so that the voter can go back to correct them. The paper itself is retained to allow auditing and, in narrow elections, recounting.
Paper-based electronic voting is easy to use for voters, requires far less equipment than other electronic voting, is fully auditable, and is less prone to user error than either traditional paper-based voting or touch-screen voting (neither of which really provides a double-check of the votes).
We have already known for a long time that ATMs are badly flawed as well when it comes to security. Even the basic technology is completely outdated and insecure: magnetic strips with four digit pins are just an abomination when it comes to security. The solution has been for banks to deny the problem, blame customers, and pass on any losses that result from fraud that they can't blame on customers to other customers.
So, does it come as a surprise that companies that can't produce minimally secure ATMs can't produce minimally secure voting machines either? Blaming Floridians for "hanging chads" (talk about a broken user interfaces) clearly was only the beginning.
If we want secure voting machines, ATM manufacturers are the last people to go to because they already have proven to be incapable of handling computer security. The only thing they seem to be able to do is make big, heavy metal boxes and pretend that that constitutes "security".
But I think a chunkload of built-in flash-memory wouldn't be such a bad idea Ideal for storing documents, MP3 files, whatnot. I might want to use the SD slot for other purposes.
The new Sony Clie has internal flash. But a better choice is probably to have dual expansion slots. The Zaurus and a few other handhelds do.
completely robotic fast food restaurants in 2030 (which then unemploy 3.5 million people),
It's easy to reduce labor in fast food restaurants to almost nothing already--fast-food restaurants in many countries do. The fact that fast food is labor intensive in the US has a very simple reason: unskilled labor is plentiful and cheap in the US. Smarter robots aren't going to change that equation.
Bluetooth synchronization works fine.
BT support in Windows is pretty awful--hard to install, hard to configure, and some USB dongles don't work. But once you find a USB dongle that does work (I'm using a blue-gene.com dongle), hotsync over Bluetooth works like a charm.
BT support in OS X looked more limited but claims to support hotsyncing and appeared easier to install.
Since BT emulates serial lines, you should also be able to hotsync with Linux over BT, but I haven't tried that since it requires a more recent kernel.
Why does palm insist on using a lower capacity, less adaptable expansion slot?
To which one might add: SD is proprietary and not publicly documented.
Why do they do it? Because SD is much smaller than CF.
Note that there are SD expansion devices, although the SD "card" in that case becomes little more than a connector.
How come those devices always are so cheap on internal memory? I mean, get a least 128 MB in the cheapest of MP3 players these days. So what's the problem?
The T2 "memory" is RAM, your MP3 "memory" is flash storage. The T2 doesn't come with any flash storage built-in (but you can put hundreds of megabytes of flash storage into its expansion slot).
Furthermore, until recently, PalmOS couldn't even cope with more than 16M of RAM (although it could address more flash storage).
I have had enough of your continued insinuations that I should somehow be unable to divine the true meaning of your words just because I don't agree with them
There is nothing to "divine". Terms like "undefined behavior" have a standard meaning in programming language definitions. Throwing an exception in Java does not result in "undefined behavior", while an index error in C/C++ does result in "undefined behavior".
I might as well note at this point that the way you keep obsessing over minor implementation details such as pointer and index errors just goes to show what a lousy programmer you are and how little systems programming experience you really have. If you can't even keep track of an index variable I fail to see how you could ever successfully deploy a large heterogenous system.
After nearly 30 years of programming in a dozen languages, I'm experienced to know that I cannot reliably keep track of an index variable, neither in my own code, nor in enormous amounts of third party code that I use. It is frightening for me to think that there are practicing programmers that think they can. It's still that old macho programmer ethics. Nor, frankly, even if I could, I wouldn't want to: programming languages are here to make my life easier, and if a language simplifies testing, debugging, and fault-tolerant computing, why in the world would I not use it?
That aside, and apart for the fact that you've repeatedly chosen to ignore the points I made about the primacy of prevention over protection
I haven't ignored it. Quite to the contrary: I keep pointing out that prevention obviously isn't working. You have to look no further than the Linux kernel, OpenOffice, Gnome, KDE, Mozilla, IIS, and all those other C/C++ applications that mangle data and crash with regularity.
I shall bow out at this point to leave the final word to you.
Thank you.
I like to see Microsoft cut down to size in court just as much as most Slashdot geeks, but this is not good. Microsoft is right: InterTrust's patents are vague. One might also add that they are pretty obvious, like InterTrust's patent Systems and methods using cryptography to protect secure computing environments, for example.
The basic problem with the "we'll all benefit" arguments relating to globalization is that they are utopian.
Did you even bother to read what I wrote? I didn't make a "we'll all benefit" argument. Quite to the contrary: I said that the US and Europe will stagnate or even suffer.
Globalization is a result of transportation and communications technologies; there is little governments can do to stop the mobility of ideas, people, information, or goods. We can't go back to protectionism or colonialism without hurting ourselves even more. The only choice we have is to make the best out of what is happening, and that means helping the poor nations catch up as fast as possible.
Now, there is one form of globalization that we can do something about: the US and Europe try to beat poor nations over the head with "free trade requirements" and all that, often to protect inefficient and outdated industries like farming and textiles at home. That is something we very much can stop. The laissez-faire approach to globalization pushed by right-wing economists where there is a level playing field won't work: developing nations just can't compete in a level playing field. One of the best things we could probably do for the long term is to drop our agricultural subsidies and import duties while, at the same time, give developing nations free reign in setting up whatever trade barriers they believe are good for their economies against our goods.
Apparently they're not teaching critical thinking or even basic common sense in the gilded MBA schools these days.
I don't know about "gilded MBA schools", but perhaps you yourself should brush up on your basic reading skills.
Since it is impossible to know what may or may not have been relinquished and what conditions may or may not have been met, at the application (or perhaps system is a better word) level, the state of the system as a whole, that is, as a situated entity with a well-defined purpose, is undefined.
Look, just because you are using "undefined" in another sense doesn't change the facts, and the facts are that at the language and runtime level, languages like Java make guarantees that C/C++ simply doesn't make.
If you don't know how to take advantage of those guarantees, so that for you undefined-at-the-language-level is the same as undefined-at-the-application-level, that's your problem. I do, however, know how to take advantage of those guarantees, as do many other programmers.
Exactly. It's not the language or the runtime per se which are responsible for horrible software.
The use of C/C++ is, of course, responsible for the bloat and flakiness in the case of OpenOffice. It is simply impossible to implement Java-like object models well in C/C++: it doesn't matter how much work you do, it doesn't matter how smart you are, C/C++ just doesn't support it. Software engineering cannot compensate for error checking that simply does not exist in the C/C++ compiler or runtime.
A good language and runtime doesn't guarantee reliable software, but an unsuitable language and runtime pretty much guarantees that you will have to spend enormous amounts of time testing and still not end up with something that you can really trust. And that is exactly what we are seeing with large C/C++-based software systems.
While Ogg is a cool thing, and I have hope that it catches on, currently it's supported by almost no consumer devices.
:-)
Ogg works on just about every PDA, meaning there are millions of consumer Ogg players out there. If companies like Apple and Creative aren't catching on, that's their problem.
AAC, on the other hand, is supported by the most popular MP3 player (iPod).
That's if you want an iPod and if you are willing to pay for it.
And why doesn't the iPod support Ogg anyway? The source for an embedded integer-based decoder is freely available. It should be trivial to create a plug-in for the iPod. The only logical explanation I see is that Apple doesn't make Ogg available for iPod for business reasons: they want to push a proprietary audio codec and DRM. Why would I want to do business with a company like that?
You can, of course, easily convert the AAC music into WAV files by "burning" them to a disk image (i.e. no reason to actually burn a CD), and re-import them as MP3's. All legal. Just don't share them!
Yes, at an additional loss of quality. That was my point.
That's a spurious example. If a resource is acquired inside the plugin and never relinquished because of an unexpected error, the state of the application is undefined.
If the plugin acquires a resource and doesn't release it, at worst, that resource would be unavailable to the rest of the application; that doesn't make the state of the application "undefined".
But actually, even that doesn't happen, because resources are accessed through objects with finalizers and will get cleaned up at the latest when the garbage collector runs again.
Note, incidentally, that "undefined state" doesn't refer to some lack of knowledge the programmer may have about what happened in a module, we are talking about what the language spec guarantees. If a Java module crashes somewhere internally with an array index error, as far as the language is concerned, the program is still in a well-defined state; whether the programmer has enough knowledge to be able to recover from that is a matter of how the program was designed. If a C program makes an index error anywhere (detected or undetected), all bets are off; there is no safe way to recover from that no matter how carefully the program was designed. And, as it turns out, in languages like Java, it is fairly straightforward to design programs that can recover reliably even from completely unexpected errors, but most C programmers don't understand that because in C it is intrinsically impossible.
But I know that OpenOffice is a slow bug-riddled pig.
My point exactly. And what is OpenOffice written in? C and C++. If it were written in a more suitable language, it would be both faster and a lot simpler.
In fact, a large part of OpenOffice is just implementing in user code what something like a Java runtime implements much more efficiently: COM-like objects.
(Incidentally, while I give Java as an example, I don't recommend using Java: it's proprietary and Sun's implementation of it isn't very good. Mono is somewhat better, as are Eiffel, Modula-3, gcj, and many other languages.)
Besides which, AAC itself isn't synonymous with DRM. I can encode my own AAC files without any restrictions. Many say the quality is better than MP3 so I can get away with a smaller file size. If true, why would I use MP3 (for example)?
As I was saying, the main reasons not to use AAC are: it's not as good as Ogg at the same bitrate, and it's patented, so your choice of players is far more limited.
That's in addition to the fact that most music in AAC comes from iMusic and hence is DRM'ed.
So if you have, say, an MP3 and you want to convert it to another compressed format you lose nothing right?
Of course, you lose something if you convert from MP3 to another compressed format. But I don't have to convert MP3 or Ogg to anything else because there are lots of players and because MP3 and Ogg files aren't subject to DRM.
Here's one point you missed: the only music downloading service that is a) legal, b) involves terms that don't treat you like an outright criminal, and c) has top-shelf popular music uses AAC exclusively.
iMusic does treat me like a criminal by imposing DRM, was my point. If I were to buy from iMusic, I'd either have to break DRM (illegal), or I have to convert the AAC file to something else through analog (probably legal since there is no circumvention). And since iMusic, so far is the only reason to use AAC, I don't see any reason to use AAC at all.
It converts to AIFF just fine with no loss of quality.
But most people need to keep their files in compressed form, and if you get stuff in AAC and transcode it to something else at the same bitrate, you will usually lose quality relative to having encoded the audio in the other format in the first place.
The point is: there is no point to AAC for users; there are better, open standards out there. Whether one AAC codec is better or worse than another just doesn't make any difference: don't use any of them.
People keep whining about how jobs move out of the US and how living standards are decreasing in the US. Yes, they do, and yes they are. And so what? What is wrong with that?
The US and Europe have been incredibly lucky, being able to build very high standards of living on the basis of cheap labor and cheap raw materials from third world nations. But those third world nations are waking up and they want their fair share. That means our standards of living will probably stagnate or go down until those nations catch up.
And that's not something we can stop anyway. Colonialism is impractical--we don't have the resources anymore to conquer and suppress large numbers of third world nations. If we oppose globalization, our economies will nose-dive. That leaves embracing globalization. But we don't have a lot of competitive advantages anymore: folks in India are smart and well-educated, and they have lower costs of living, so of course they are going to be successful and compete with us.
Overall, this means our standard of living will stagnate or even go down until the rest of the world catches up. The best thing we can do is embrace this trend and help other nations improve their standard of living quickly.
why should a bunch of people from all over the world be able to clone expensive microsoft software and give it away for free ?
Because that's the way our economy works: Microsoft didn't invent any of that stuff themselves either, they cloned Apple, AT&T, Xerox, and IBM, among many others. Products in the real world work by imitation and modification (kind of like evolution works in biology).
(What your point has to do with paying taxes, I don't get.)
So one company has the best implementation of a mediocre, DRM-crippled, patented audio codec. So, why do I care?
And even if I gave in and were to buy AAC audio on-line and even if I could use the best AAC implementation and even if that were better than some other codec, I'd lose that quality anyway when converting that AAC audio format into a more usable format.
In a properly written program in a well-designed high-level language, yes, transactions will be properly closed and privileges will be relinquished. Consider:When the code reaches "after", I can know with certainty that the privilege has been relinquished, no matter what happened in the plug-in.
And the whole point of transactions is that if you don't complete them, the world won't change, so there is nothing to "close"; the resources associated with the transaction will be freed through the usual cleanup actions in a language like C# or Java.
Generally when you encounter an unexpected error the only sensible thing to do is to terminate the application. Regardless of language.
For C, that is true, for other languages, it is just false.
We're much better off addressing them at the kernel level through orthogonal persistance and a more powerful process abstraction. Some hardware assistance wouldn't hurt either.
People have tried for decades to address them at the kernel level and at the hardware level and it hasn't worked out: trying to do fine-grained fault isolation at the OS or hardware level is far, far too inefficient. Fault isolation at the language level yields much more efficient software (there are a bunch of papers you can dig up on the subject).
Note also that just because a language provides fault isolation doesn't mean that you can't disable it selectively--in well-tested code. For example, in something like C# or Modula-3, you might turn off index checking in the inner loop of a BLAS implementation. Then, you can focus your testing on only those bits of unsafe code. Furthermore, software that loads components can determine whether the components it tries to load are fault-isolated or not and make decisions accordingly.
Software is slow enough as it is.
Software is slow because it is written in unsafe languages: unsafe languages require clumsy and inefficient fault isolation mechanisms (processes, IPC), and they greatly interfere with the ability of programmers to optimize and design for performance.
When a particular programming practice makes it hard to rule out errors, the answer is not to design a fault-tolerant language; the answer is to avoid the practice.
There are no fault-tolerant languages. But there is fault-tolerant programming and languages that support fault-tolerant programming. C does not support fault tolerant programming, and that is exactly the problem with C.
It's 100 megs of compiled code, not C.
That's obviously what I'm referring to: it's a 100M of binary code corresponding probably to millions of lines of messy C source code. And the notion that a 100M binary install is "lean" is itself absurd.
Also, the overhead of an interpreted language is inappropriate for the kind of command that's expected to be ran often and not take up too much time (like most of the applications found in various toolchains on unix)
That's silly: most of the stuff in a base OS install either is not performance critical at all, or it is I/O bound. You could rewrite init, cron, ps, sendmail, ftpd, apcid, lpd, rpc.mountd, xinit, and almost all other of the programs in a base install in an interpreted language, and system performance would probably improve (because of much better VM sharing) and install size would decrease.
C is used extensively throughout the base operating system, in nearly all applications it's faster, it's proven over the course of decades, and it's very widely understood. Why switch to perl?
The notion that "C [...] is faster" is ridiculous; most C programs are probably a lot slower than they would be if an equivalent amount of time had been spent writing them in a decent high-level language because C makes it so much work to build complex data structures or try different implementations and because C debugging and testing takes so much time compared to high-level languages. The BSD and Linux kernels, as well as many of those "efficient" C programs you area thinking of are full of linear search over potentially large data structures because it's so much more work to do anything better in C. And mostly what has been proven about C is that just about any significant C program has serious pointer and memory management bugs.
C has shown to be particularly unsuitable to building component based software: software built from a framework with dynamically loadable components really needs to be robust against buggy components. What are examples of component based software? The Linux kernel, MS Office, the Gimp, OpenOffice, Mozilla, and lots more. That's why Microsoft is betting on C#--the only way to build large, reliable, component-based systems is to use a language with fault isolation, reliable error detection, and reflection.
My general point is: much more stuff should be in interpreted languages in UNIX/Linux/BSD systems, in a decent, high-level interpreted language. An all-C/shell base install is just the wrong direction. Whether that language is Perl or something else, I don't really care. Perl is probably technically the worst language you could pick, but it is also the most commonly used one.
And, in fact, large parts of systems like the Gnome desktop are written in interpreted high-level languages, so it's not even a question of whether it's happening. It's only some misguided notion of "minimalism" that causes the "base installs" to buck the trend. Of course, again, the notion that there is anything "lean" about a 100M binary install anyway is just laughable.
Perl is icky to have for a few reasons.
/bin/sh with ANSI C is not fine.
Yeah, Perl is icky, but everybody else manages to ship it, so why not FreeBSD?
In any case, Python, Ruby, whatever, would be fine, too. But
This is bare, and I like it that way.
The notion that 100 megs of ANSI C code is "bare" strikes me as absurd. Just because you don't see the incredible mess that's under the covers because you don't install sources doesn't mean the mess isn't there.
Perl was just being used in fewer and fewer places...
Yes, and that's the problem. Operating systems should use more VHLLs, not less. Whether that VHLL Perl or something else, I really don't care.