But the various Laws of Thermodynamics are just a theory. The theory might be wrong. You can't say a perpetual motion machine is impossible, just that it is inconsistent with current theories about how the universe works.
Could it be like posts being moderated up on Slashdot, moving towards the top of the page, and then being moderated further by ignorant moderators who don't bother to view 'newest first'? The theory that many moderators only view the first page of comments (those which are old and high-scoring) explains why earlier posts are more likely to end up +5, and the seeming scarceness of +3 and +4 scores.
But 100% pure distilled water is difficult to get hold of and keep pure. Even skinflakes falling into it from the air would probably add enough salt to make it conduct. The same applies if the toaster falls in while bathing:-(.
I didn't mean 'release stuff before it's ready', I meant 'pick a date and release everything that's ready on that date'. So it might be the case that the kernel version doesn't change from one release to the next, if the new kernel isn't considered ready yet.
As someone who knows nothing about Debian... perhaps they should use a different method for deciding their release schedule. OpenBSD has a regular release every six months, LaTeX every twelve months. Both of these have in common with Debian that they are a collection of packages from different sources. There's no way that Debian can plan and organize XFree86, Linux, gcc, Apache etc etc to all work to a single release cycle - they are completely out of phase with each other. Nothing wrong with that. But given this situation, the best release strategy is surely to pick an arbitrary date and go with whatever is available at that time. Debian does put a lot of effort into finishing each distribution once the deadline is known, but IMHO the release date should be known right from the start, as in 'it's always the fifteenth of August'.
Or even every week - 'It's Friday, it's six o'clock, and it's Debian New Release Time!'. That might be taking it a bit far.
This is also, perhaps, a sign that IBM isn't so interested in the PC / small system market. The big appeal of IBM in the past was that they produced almost all the parts for their systems in-house. So if there was a problem with a particular model of disk or monitor or RAM chip, IBM would know the full history, know who designed it, and have the expertise to support it. Or more importantly, IBM's knowledge of the parts they used helped them put together reliable systems to start with. (There was a time when every IBM upgrade (for the PS/2 line) was guaranteed to work with every other IBM upgrade.)
But since the reorganization of the 1990s, IBM divisions have been encouraged to sell outside the company, even to direct competitors, and make money in their own right. In this context it makes a lot of sense to spin them off.
'Open architectures'? But it's going to be running Intel's proprietary IA-64 family, where the USPTO has even granted patents on certain CPU instructions. H-P's claim would ring more true if they'd gone with IA-32 (which has two competing suppliers, at least) or SPARC (which you can license from some half-baked consortium).
Unfortunately there is no fully open hardware platform at the moment, and closed hardware is less of a problem than closed software, but still this sounds like marketspeak.
Sorry, I was misled by the Slashdot story text: Bezos wants everyone to be 'super-clear' that Amazon.com is supportive of and good
for authors, indicating that Amazon's steep discounting of new titles and royalty-less sales of used books are two examples of how
Amazon helps the book industry and authors..
So what exactly is the Author's Guild's problem with secondhand sales? If they're not seeking to claim royalties on them, would they prefer to ban them altogether? Or is it just an objection to Amazon making it easy for individuals to make legal purchases from each other?
What the article seems to be saying is that there could be a way of producing non-volatile memory which is so cheap, you'll be able to use NVRAM instead of ordinary RAM in your computers. But that depends on no further falls in RAM prices - I wouldn't bet on this technology taking over.
However, a cheap, fast non-volatile memory which can be written and read unlimited times could be a very useful supplement to RAM. Think journalling filesystems for example - put your ext3 journal in a 100Mbyte NVRAM device and you'd hardly need to touch the hard disk for hours at a time, given moderate use. (Eg notebooks could spin down the drive.) This is possible already, but NVRAM devices are relatively expensive and most PCs don't have them.
There are two ways to get vi / emacs / your-favourite-editor embedded into konqueror or kmail or whatever. Either make it into a 'component' which visually sits inside the konqueror window, or write a lightweight component which calls out to a separate editor process. Think about Emacs's 'server mode' where you set $EDITOR to 'emacsclient' and your currently-running Emacs is used as an external editor.
You could have a KDE editor component which just displays the text and a big 'edit' button; the button when pressed launches $EDITOR, which could be Emacs or whatever. It wouldn't look as nice as embedding kvim directly into the app's window, but it should work with all editors, with no special KDEification needed for each one.
Remember the TV series 'Spiderman and his Amazing Friends'? It had three sidekicks for Spiderman IIRC: Ice-Man (ice), Fire-Start (fire) and one other I can't remember. I thought it was great at the time, but I don't think it's considered to be canon. Anyone know more about this?
OK, you got me. I confess. I do have a reasonable amount of Java experience, but not so much C++, and hardly any QBASIC - the reference to which was entirely rhetorical:-). The non-portablility of the JDK: this may be more due to the fact that Sun controls the source than technical issues - but still, things like just-in-time compilers are going to be pretty OS and processor dependent. I wonder whether the free BSDs are able to successfully run Sun's Linux JDK - they can run most other Linux binaries.
About J2EE - I know you can download it free of charge, but subject to a licence agreement that you won't use it commercially. Of course I expect most companies ignore this, but if Sun did decide to start enforcing it a lot of people could get very red faces. I am talking about J2EE, not the JDK or JRE.
The phrase 'vendor-neutral' or 'vendor-independent' does more or less imply free as in speech. At least, it means you can easily get a complete implementation over which Sun has no control. I agree, most Java users don't care about this, they just want free-as-in-beer, but the marketing hype around Java tries to suggest that Java is not tied to a single company, unlike (say) Windows.
I wasn't referring to safety as in garbage collection and not having to manage pointers. That is a good thing, provided you have the ability to go back to fiddling with raw memory when you need it. I meant Java-the-language's decisions not to include things like operator overloading, which Java apologists try to justify on the basis of protecting stupid programmers from themselves. Sorry I didn't make this clear.
You can succesfully prevent coders from being stupid.
By code review and education - yes. By a machine applying an arbitrary set of rules - no, of course not. If it were possible for the language designers to know in advance exactly what 'stupid' consists of for any given programming task, and it were possible to write a compiler to enforce this, then most programmers would be out of a job.
Every language has missing features and programming styles it doesn't directly support, there's nothing wrong with that. But Java is unique in trying to cover up for its deficiencies by claiming that those programming styles are never needed, or only a foolish programmer would try to use them. At least, this is the standard line from many Slashdot posters - the language designers themselves are probably not so arrogant.
What you want from a language is a language that maps well to architectural models so that your architects are making the decisions, not your immature and inexperienced code monkeys.
I can't imagine that such a way of organizing programmers - a separation into 'architects' and 'monkeys' - could ever really work. At my last employer there was something a bit like this, and the architects got cut off from what it was really like to use the product and produced horribly baroque designs, while some of the monkeys wrote code of unusably poor quality. My feeling is that every programmer should be able to do both design and implementation competently. But I don't have enough experience to say for sure that this division won't work - maybe you have experience of successfully programming in such an environment?
FWIW, if you did want a language that mapped well to your chosen 'architecture', it's much more likely to be C++ or even Perl rather than Java. Java supports only a rather simplistic view of the world - your chosen design might naturally require multiple inheritance (or virtual inheritance), for example. And of course the implementation people would appreciate a less cumbersome language to put things into code, without having to resort to circumlocutions like a.plus(55) or manually boxing things into Integers and Chars to store them in containers.
The problem is, novice coders don't generally understand that there are things like non-western calendaring systems, multi-byte character sets, and alternate forms for displaying dates.
The multibyte characters stuff I agree with, of course. But not the weird dates. This was exactly the example that made me think 'what an overengineered crock'. Can you honestly say that the typical application requires support for non-Western calendars? The 80-20 rule would seem to apply strongly in this case. What Sun should have done is include a simple date library for the common case, ideally something like Perl's excellent Date::Manip. Then if it is really needed (which I doubt) another set of classes can be provided for conversion to foreign calendars. Support for the Aztec calendar is cute when it's an extra toy in Emacs, but it shouldn't mean you have to wade through a complex API as part of a standard date library. It's classic design by committee / second-system syndrome / insert favourite phase for excessively complex software. Perhaps caused by a separation of the 'architects' from those who actually have to use the stuff.
Only in a very loose sense. I don't think you can call the development environment like the compiler a 'platform'. You are right that the C standard library, for example, is a platform in its own right, but it's not a heavyweight monster like Java's runtime system.
The difference I am talking about is illustrated by comparing Swing and the wxWindows GUI toolkit. With Swing, Sun defined a set of user interface widgets, from scratch, and some code to laboriously plot them onto the screen. This means you get the same look everywhere (some say this is good, I disagree) and sluggish performance. They defined some bitmaps to emulate the look of existing platforms like Windows, but the code itself is a complete reimplementation - in Java. wxWindows on the other hand tries to use the platform's native GUI as much as possible and wrap it to provide a consistent interface to the programmer. I would say that of these two, wxWindows is making a genuine effort to be cross-platform while Swing is sidestepping the problem by building a new, rather slow GUI on top.
I agree that Java is on the way out. The language is awkward and unexpressive; its main appeal seems to be in preventing stupid programmers from doing things their brains can't understand (like multiple inheritance). But we all know that you cannot prevent the programmer from writing bad code. OK, pointer safety and garbage collection is useful, but c'mon, practically every other language apart from C and C++ has this too, and C++ is pretty safe if you program it carefully and use the STL.
And the libraries: urgh. They all seem to be designed by committee and make QBASIC look elegant. The standard date library for example, or database access.
Java claims to be cross-platform, but it only does this by creating a whole new platform on top which has to be installed first. And the JDK is one of the least portable programs you'll find on a modern system. As for being vendor independent: don't make me laugh. Java is just as dependent on Sun as Windows is on Microsoft. Even other people like IBM who have their own JVMs have to license the code from Sun. The licence for J2EE seems to forbid using it for any purpose whatsoever: I don't know whether you have to 'purchase' the commercial version from Sun, but it can't be cheap. In fact Java is less vendor-neutral than Windows, since the Wine project seems to have done a better job of cloning the Win32 API than the various free Java projects have with the JDK and libraries. (Not to diss the work these projects have done: but there's just so much of it. And every new release brings another set of 'standard' APIs for which the only existing implementation is Sun's.)
Java has succeeded by marketing and not for technical reasons. Microsoft is better than Sun at marketing, so C# will win.
Why water? Why not mineral oil or something that's certain not to conduct electricity? It might not take heat away quite as fast as water does but it should still be a lot better than air.
I wonder whether liquid nitrogen is feasible. That would be a great cooling system for a Beowulf cluster: remove the cases, hard disks etc and just stack motherboards really close together in a big bathtub filled with cold liquid.
If Mac OS X (various personalities layered onto a Mach-derived microkernel) counts as 'Unix', then Linux and the BSDs certainly count as 'Unix' too. People should distinguish more carefully between Unix and UNIX(tm). Although I don't think anyone apart from managers and historians is really bothered about the distinction, UNIX(tm) is just a trademark slapped onto several rather different Unix variants.
Yes, it's amazing that the article doesn't have any mention of whether the browser makers might have some responsibility. From reading articles like this you would get the impression that spyware, viruses, intrusive ads and so on are unavoidable whenever computers are used, and the only answer is some kind of regulation to make websites act 'responsibly'.
If you want to increase your burn rate, the best way would be to buy new offices. Keep buying offices and leaving them empty (maybe hire one or two token people to go in them). If the VC funding later dries up you can sell the real estate and live off the 'fat' for a while. This assumes you don't want to grow as quickly as possible and hire as many people as possible (some companies want to do that, some don't).
It's not security avoidance, it's stupidity avoidance. RFC 3093 and (to some extent) ssh tunnelling are in the same spirit. Until now, being able to do useful Internet communications (other than http) through a firewall has been limited to those geeky enough to set up some kind of tunnel or workaround. Well done to Microsoft for opening it up to the masses.
I feel like predicting that in five years' time _all_ major services (including NFS, etc) will operate over http, that being the only way to make them accessible to most Web users. (Gloomily assuming that IPv6 doesn't take off and ISPs continue on their current path of masquerading and transparent proxying.) Then 'next generation' firewalls will appear which are able to selectively block SOAP packets and other kinds of http requests. But to bypass that, Microsoft will soon switch to https instead, and that will be the end of firewalls. Unless you give your firewall a copy of your servers' private keys so it can snoop on communications.
But the various Laws of Thermodynamics are just a theory. The theory might be wrong. You can't say a perpetual motion machine is impossible, just that it is inconsistent with current theories about how the universe works.
Could it be like posts being moderated up on Slashdot, moving towards the top of the page, and then being moderated further by ignorant moderators who don't bother to view 'newest first'? The theory that many moderators only view the first page of comments (those which are old and high-scoring) explains why earlier posts are more likely to end up +5, and the seeming scarceness of +3 and +4 scores.
But 100% pure distilled water is difficult to get hold of and keep pure. Even skinflakes falling into it from the air would probably add enough salt to make it conduct. The same applies if the toaster falls in while bathing :-(.
I didn't mean 'release stuff before it's ready', I meant 'pick a date and release everything that's ready on that date'. So it might be the case that the kernel version doesn't change from one release to the next, if the new kernel isn't considered ready yet.
As someone who knows nothing about Debian... perhaps they should use a different method for deciding their release schedule. OpenBSD has a regular release every six months, LaTeX every twelve months. Both of these have in common with Debian that they are a collection of packages from different sources. There's no way that Debian can plan and organize XFree86, Linux, gcc, Apache etc etc to all work to a single release cycle - they are completely out of phase with each other. Nothing wrong with that. But given this situation, the best release strategy is surely to pick an arbitrary date and go with whatever is available at that time. Debian does put a lot of effort into finishing each distribution once the deadline is known, but IMHO the release date should be known right from the start, as in 'it's always the fifteenth of August'.
Or even every week - 'It's Friday, it's six o'clock, and it's Debian New Release Time!'. That might be taking it a bit far.
Clearly they were ranked according to the sillyness of their names.
This is also, perhaps, a sign that IBM isn't so interested in the PC / small system market. The big appeal of IBM in the past was that they produced almost all the parts for their systems in-house. So if there was a problem with a particular model of disk or monitor or RAM chip, IBM would know the full history, know who designed it, and have the expertise to support it. Or more importantly, IBM's knowledge of the parts they used helped them put together reliable systems to start with. (There was a time when every IBM upgrade (for the PS/2 line) was guaranteed to work with every other IBM upgrade.)
But since the reorganization of the 1990s, IBM divisions have been encouraged to sell outside the company, even to direct competitors, and make money in their own right. In this context it makes a lot of sense to spin them off.
'Open architectures'? But it's going to be running Intel's proprietary IA-64 family, where the USPTO has even granted patents on certain CPU instructions. H-P's claim would ring more true if they'd gone with IA-32 (which has two competing suppliers, at least) or SPARC (which you can license from some half-baked consortium).
Unfortunately there is no fully open hardware platform at the moment, and closed hardware is less of a problem than closed software, but still this sounds like marketspeak.
Who would have thought that _spammers_ would be the first to make a system passing the Turing Test?
Okay, it's not quite at that level, but the fact that these bots are indistinguishable from real users for a few minutes is quite something.
Sorry, I was misled by the Slashdot story text: Bezos wants everyone to be 'super-clear' that Amazon.com is supportive of and good for authors, indicating that Amazon's steep discounting of new titles and royalty-less sales of used books are two examples of how Amazon helps the book industry and authors..
So what exactly is the Author's Guild's problem with secondhand sales? If they're not seeking to claim royalties on them, would they prefer to ban them altogether? Or is it just an objection to Amazon making it easy for individuals to make legal purchases from each other?
Yes. Why the hell should authors expect to get royalties from second-hand sales? First sale doctrine and all that.
I support Amazon's offering to find secondhand books - I only wish they would do the same for software.
Why do you even bother working on this GNOME thing when KDE is so much better?
What the article seems to be saying is that there could be a way of producing non-volatile memory which is so cheap, you'll be able to use NVRAM instead of ordinary RAM in your computers. But that depends on no further falls in RAM prices - I wouldn't bet on this technology taking over.
However, a cheap, fast non-volatile memory which can be written and read unlimited times could be a very useful supplement to RAM. Think journalling filesystems for example - put your ext3 journal in a 100Mbyte NVRAM device and you'd hardly need to touch the hard disk for hours at a time, given moderate use. (Eg notebooks could spin down the drive.) This is possible already, but NVRAM devices are relatively expensive and most PCs don't have them.
There are two ways to get vi / emacs / your-favourite-editor embedded into konqueror or kmail or whatever. Either make it into a 'component' which visually sits inside the konqueror window, or write a lightweight component which calls out to a separate editor process. Think about Emacs's 'server mode' where you set $EDITOR to 'emacsclient' and your currently-running Emacs is used as an external editor.
You could have a KDE editor component which just displays the text and a big 'edit' button; the button when pressed launches $EDITOR, which could be Emacs or whatever. It wouldn't look as nice as embedding kvim directly into the app's window, but it should work with all editors, with no special KDEification needed for each one.
Remember the TV series 'Spiderman and his Amazing Friends'? It had three sidekicks for Spiderman IIRC: Ice-Man (ice), Fire-Start (fire) and one other I can't remember. I thought it was great at the time, but I don't think it's considered to be canon. Anyone know more about this?
OK, you got me. I confess. I do have a reasonable amount of Java experience, but not so much C++, and hardly any QBASIC - the reference to which was entirely rhetorical :-). The non-portablility of the JDK: this may be more due to the fact that Sun controls the source than technical issues - but still, things like just-in-time compilers are going to be pretty OS and processor dependent. I wonder whether the free BSDs are able to successfully run Sun's Linux JDK - they can run most other Linux binaries.
About J2EE - I know you can download it free of charge, but subject to a licence agreement that you won't use it commercially. Of course I expect most companies ignore this, but if Sun did decide to start enforcing it a lot of people could get very red faces. I am talking about J2EE, not the JDK or JRE.
The phrase 'vendor-neutral' or 'vendor-independent' does more or less imply free as in speech. At least, it means you can easily get a complete implementation over which Sun has no control. I agree, most Java users don't care about this, they just want free-as-in-beer, but the marketing hype around Java tries to suggest that Java is not tied to a single company, unlike (say) Windows.
I wasn't referring to safety as in garbage collection and not having to manage pointers. That is a good thing, provided you have the ability to go back to fiddling with raw memory when you need it. I meant Java-the-language's decisions not to include things like operator overloading, which Java apologists try to justify on the basis of protecting stupid programmers from themselves. Sorry I didn't make this clear.
By code review and education - yes. By a machine applying an arbitrary set of rules - no, of course not. If it were possible for the language designers to know in advance exactly what 'stupid' consists of for any given programming task, and it were possible to write a compiler to enforce this, then most programmers would be out of a job.
Every language has missing features and programming styles it doesn't directly support, there's nothing wrong with that. But Java is unique in trying to cover up for its deficiencies by claiming that those programming styles are never needed, or only a foolish programmer would try to use them. At least, this is the standard line from many Slashdot posters - the language designers themselves are probably not so arrogant.
I can't imagine that such a way of organizing programmers - a separation into 'architects' and 'monkeys' - could ever really work. At my last employer there was something a bit like this, and the architects got cut off from what it was really like to use the product and produced horribly baroque designs, while some of the monkeys wrote code of unusably poor quality. My feeling is that every programmer should be able to do both design and implementation competently. But I don't have enough experience to say for sure that this division won't work - maybe you have experience of successfully programming in such an environment?
FWIW, if you did want a language that mapped well to your chosen 'architecture', it's much more likely to be C++ or even Perl rather than Java. Java supports only a rather simplistic view of the world - your chosen design might naturally require multiple inheritance (or virtual inheritance), for example. And of course the implementation people would appreciate a less cumbersome language to put things into code, without having to resort to circumlocutions like a.plus(55) or manually boxing things into Integers and Chars to store them in containers.
The multibyte characters stuff I agree with, of course. But not the weird dates. This was exactly the example that made me think 'what an overengineered crock'. Can you honestly say that the typical application requires support for non-Western calendars? The 80-20 rule would seem to apply strongly in this case. What Sun should have done is include a simple date library for the common case, ideally something like Perl's excellent Date::Manip. Then if it is really needed (which I doubt) another set of classes can be provided for conversion to foreign calendars. Support for the Aztec calendar is cute when it's an extra toy in Emacs, but it shouldn't mean you have to wade through a complex API as part of a standard date library. It's classic design by committee / second-system syndrome / insert favourite phase for excessively complex software. Perhaps caused by a separation of the 'architects' from those who actually have to use the stuff.
Only in a very loose sense. I don't think you can call the development environment like the compiler a 'platform'. You are right that the C standard library, for example, is a platform in its own right, but it's not a heavyweight monster like Java's runtime system.
The difference I am talking about is illustrated by comparing Swing and the wxWindows GUI toolkit. With Swing, Sun defined a set of user interface widgets, from scratch, and some code to laboriously plot them onto the screen. This means you get the same look everywhere (some say this is good, I disagree) and sluggish performance. They defined some bitmaps to emulate the look of existing platforms like Windows, but the code itself is a complete reimplementation - in Java. wxWindows on the other hand tries to use the platform's native GUI as much as possible and wrap it to provide a consistent interface to the programmer. I would say that of these two, wxWindows is making a genuine effort to be cross-platform while Swing is sidestepping the problem by building a new, rather slow GUI on top.
I agree that Java is on the way out. The language is awkward and unexpressive; its main appeal seems to be in preventing stupid programmers from doing things their brains can't understand (like multiple inheritance). But we all know that you cannot prevent the programmer from writing bad code. OK, pointer safety and garbage collection is useful, but c'mon, practically every other language apart from C and C++ has this too, and C++ is pretty safe if you program it carefully and use the STL.
And the libraries: urgh. They all seem to be designed by committee and make QBASIC look elegant. The standard date library for example, or database access.
Java claims to be cross-platform, but it only does this by creating a whole new platform on top which has to be installed first. And the JDK is one of the least portable programs you'll find on a modern system. As for being vendor independent: don't make me laugh. Java is just as dependent on Sun as Windows is on Microsoft. Even other people like IBM who have their own JVMs have to license the code from Sun. The licence for J2EE seems to forbid using it for any purpose whatsoever: I don't know whether you have to 'purchase' the commercial version from Sun, but it can't be cheap. In fact Java is less vendor-neutral than Windows, since the Wine project seems to have done a better job of cloning the Win32 API than the various free Java projects have with the JDK and libraries. (Not to diss the work these projects have done: but there's just so much of it. And every new release brings another set of 'standard' APIs for which the only existing implementation is Sun's.)
Java has succeeded by marketing and not for technical reasons. Microsoft is better than Sun at marketing, so C# will win.
Why water? Why not mineral oil or something that's certain not to conduct electricity? It might not take heat away quite as fast as water does but it should still be a lot better than air.
I wonder whether liquid nitrogen is feasible. That would be a great cooling system for a Beowulf cluster: remove the cases, hard disks etc and just stack motherboards really close together in a big bathtub filled with cold liquid.
Yes, it's amazing that the article doesn't have any mention of whether the browser makers might have some responsibility. From reading articles like this you would get the impression that spyware, viruses, intrusive ads and so on are unavoidable whenever computers are used, and the only answer is some kind of regulation to make websites act 'responsibly'.
If you want to increase your burn rate, the best way would be to buy new offices. Keep buying offices and leaving them empty (maybe hire one or two token people to go in them). If the VC funding later dries up you can sell the real estate and live off the 'fat' for a while. This assumes you don't want to grow as quickly as possible and hire as many people as possible (some companies want to do that, some don't).
It's not security avoidance, it's stupidity avoidance. RFC 3093 and (to some extent) ssh tunnelling are in the same spirit. Until now, being able to do useful Internet communications (other than http) through a firewall has been limited to those geeky enough to set up some kind of tunnel or workaround. Well done to Microsoft for opening it up to the masses.
I feel like predicting that in five years' time _all_ major services (including NFS, etc) will operate over http, that being the only way to make them accessible to most Web users. (Gloomily assuming that IPv6 doesn't take off and ISPs continue on their current path of masquerading and transparent proxying.) Then 'next generation' firewalls will appear which are able to selectively block SOAP packets and other kinds of http requests. But to bypass that, Microsoft will soon switch to https instead, and that will be the end of firewalls. Unless you give your firewall a copy of your servers' private keys so it can snoop on communications.