Not terribly surprising, but still disappointing. It will be interesting to see how gambling evolves, as casinos take ever more stringent steps to avoid giving out more money to someone than they paid in. Here's an interesting little exhibit from the UK dealing with the rigging of fruit machines.
It would seem to me that the sheer number of moving parts in a kilometre or so of walkway must make the chances of frequent failures pretty high compared to other public transport methods. How fault-tolerant is it? Any French Slashdotters able to answer?
Life imitates Neal Stephenson. This reads exactly like something out of Snow Crash.
Great Train Robbery fact-based
on
Prey
·
· Score: 1
Probably one of the most famous crimes in Britain last century was the Great Train Robbery in 1963, which formed the factual underpinning for the film and book. Most of the 15 men involved in the heist were caught; one of them, Ronnie Biggs, escaped from jail in a rather daring manner and became something of a celebrity as a result. Last year he returned from Brazil, aged 71, to give himself up. A Google for Biggs and the great train robbery should give you a wealth of information, but here's a link to get started:
Don't know if anyone noticed, but the funding is given as approximately £100,000 (that is, $156,000 or so, American readers). With tiny sums of money like that, you won't have many people working on it nor much money for experimenting with different equipment. British funding for research is pathetically low compared to many neighbouring countries with far poorer economies; the phone company Nokia spends more on research than the whole of Scotland.
It's something of a miracle that any kind of useful research comes out of Britain at all, given governmental reluctance to give academia useful amounts of money.
You could describe the court system almost exactly like that, you know; a panel containing individuals with a known bias. There's a prosecuting lawyer, and a defending lawyer, and a judge and jury. The funny thing is that it works much better than not having prosecuting or defending lawyers at all; the jury knows where the lawyers' bias lies, and relies on the lawyers to sort the wealth of information about the case into arguments for and against convicting the accused.
Given that there will be open source advocates and Microsoft advocates on the panel, there's the same balance as in a court of law. And if we were looking at the scientific evidence supporting the theory of evolution, damn right I'd want creationists on the panel as well as hard-core evolution supporters like yourself. I might or might not find their arguments unconvincing, but I'd be positive that those making them had put in a lot of effort to find the best arguments they could opposing the theory. And personally, I don't find them any more ridiculous than those who treat evolution as an unchallengeable religion in itself. When people stop looking at things scientifically and resort to dogma, whether it be evolution or creation, championing Microsoft or Linux, they pretty well forfeit any chance of my taking them seriously; I like to hope I'm not the only one that feels that way.
This is a regular straw man attack. The original, informative post didn't claim viruses were living organisms (in fact, it specifically said that viruses were 20-50x less complex than the simplest forms of life), and it called Penrose a physicist. So how is this response relevant in any way?
Hate to be disagreeable, but Microsoft doesn't pay taxes in Britain to the best of my knowledge, and those of us who do pay taxes in Britain pay them in pounds sterling, rather than dollars.
The university in Cambridge being mentioned is the rather famous British one.. as in "Oxford and Cambridge".
[Usenet] Since Usenet first got off the ground in 1980-81, it has grown exponentially, approximately doubling in size every year. On the other hand, most people feel the signal-to-noise ratio of Usenet has dropped steadily. These trends led, as far back as mid-1983, to predictions of the imminent collapse (or death) of the net. Ten years and numerous doublings later, enough of these gloomy prognostications have been confounded that the phrase "Imminent Death Of The Net Predicted!" has become a running joke, hauled out any time someone grumbles about the S/N ratio or the huge and steadily increasing volume, or the possible loss of a key node or link, or the potential for lawsuits when ignoramuses post copyrighted material, etc., etc., etc.
My question would be whether the take-up of applications such as Outlook Express and Internet Explorer is greatly hindered by their having security holes. I'm sure some people will refuse to use Outlook on security grounds, but I've the suspicion far more people will choose to use it on its features, and it will be the feature set that keeps them with Outlook as an email client. From a marketing perspective, then, there would be no point in directing a high proportion of development effort into ensuring security when it will only affect product adoption minorly. Now given that Microsoft's chief strength is in desktop apps, I'd be tempted to think that they've been applying the same marketing mentality that they have for the debug/add feature work split on desktop apps to server app development.
The concept here doesn't look like revolutionary thinking; I'm fairly certain I've seen descriptions of similar devices in sci-fi, and the idea of painting input from the other side onto the output from the other is a pretty obvious way to take a stab at "invisibility". I'm hoping that the patent is based on having at least a semi-working prototype rather than being a pure concept patent.
In any case, if you're using it on irregular shapes like clothing, you'll run into interesting texture-mapping/scaling problems trying to map the input to the output; you'll need to be able to work out the exact locations of your receptors on some kind of internal co-ordinate system to make things work. This means that, for clothing, you'd need to work out exact body orientation and movement. For this you'd need to first build a superbly accurate body suit that tracks motion with very low error margins... which we're not all that close to at present. And that's assuming nice tight clothing without those horrid hard-to-calculate folds.
Bottom line: Can't see an invisibility cloak, or any invisibility clothing lines any time soon. Would consider it *possibly* feasible with current technology to build a static regular shell (perhaps hemispherical) which could conceal what's under it.
> 2. It's an awful lot easier to write software in high level languages, SML being a good example
Not really; you're comparing a totally different programming paradigm, which is admittedly easier for some things, but a hell of a lot harder in others.
> 3. SML is actually very fast. Maybe you used it a long while ago, or were confused by the interactive system (where compilation is part of running your program), but it is fast, I promise.
Um, a few points about these "benchmarks"... take a look at the actual CPU time spent over a few individual benchmarks, rather than the somewhat dubious points system. SML is coming in at something like half the speed of C at best on almost all of them, and in most cases far far worse than that. Admittedly, adopting some of the worse mistakes of C++ can slow you down by similar factors, but as C++ is essentially pretty close to a C superset there's no need to use these "features" in a performance-intensive app.
Additionally, some of the algorithms used to minimise code length in non-C languages (such as the Fibonacci sequence) are frighteningly, horrendously inefficient. Compare the Fibonacci sequence algorithm given with the speed of a straightforward C loop with 3 variables (translating directly into registers). Not to mention the actual time spent in calculation pales into insignificance besides the time spent in printf - slightly over half a dozen assembly instructions are all that is needed to cope with the calculation part in C, but printf runs to thousands of lines of C code and more assembly... these benchmarks are nonsensical, particularly as the main speed difference between C and C++, give the implementations listed, is probably between cout and printf...
> Well, I don't know what useful features it's missing
I should clarify; didn't really mean features, but library functionality. Try writing an SML GUI for X.
> In fact, most SML compilers will compile a tail-recursive function into a JMP, just like a loop in C.
The most painful inefficiency of recursion is often size. It leads to many more stack frames being kept in memory than necessary, compared to an incremental approach, as data from all calling recursive functions must be kept in memory whether vital to the current calculation or not. The recursive fibonnacci algorithm (I'm still shocked:P) given is a perfectly natural way to program in SML, but strange and hideous to a loop-loving C programmer - it yields an algorithm which grows in memory needed and execution time *as do the Fibonnacci numbers themselves* as opposed to the obvious-to-a-C-programmer O(N) algorithm. That the compiler uses the JMP instruction to implement the hideous recursive algorithm does not mean that it is anywhere near as tidy and efficient as the loop algorithm!
What I meant by "bad to translate into assembly language" was precisely this: the different paradigm tends to lead to inefficient algorithms on computing hardware which works in a C-like manner.
> Well, I think any modern language would be better. Java (natively compiled) would be ok if the programmer needs the
> language to be C-like, but personally I think SML (http://slashdot.org/comments.pl?sid=6343&cid=9296 97
> [slashdot.org]) or O'Caml would be a much better choice. These languages are safe (NO more buffer overflows or
> memory leaks, not even "null pointer exceptions"), powerful, AND fast.
Java as native code is still horridly inefficient in comparison to C, and there is no compelling reason to use it in preference as opposed to good programming practice in C (using safe i/o routines for starters).
SML - what are you smoking? I was lucky enough to be educated at Edinburgh Uni, which is a damn fine university in most respects, but has a horrid blind spot where Standard ML is concerned, and it is universally inflicted on second year CS students. It encourages inefficient programming techniques (such as recursion) and lacks a hell of a lot of important features - not to mention that by implementing a non-procedural programming paradigm it becomes uselessly high-level (bad to translate into assembly) and yes, damn slow. Edinburgh is one of the few places where it has a home, but even here probably the majority of staff (working there now) tacitly acknowledge its general uselessness for most real world tasks. Admittedly, as you point out, speed is less of an issue here than it would be in a lot of other cases, but there's still no excuse for using SML as opposed to coding in C using safe I/O routines. I know this is supposed to be one of the few areas its supporters claim it to be good at... but honestly, speaking as someone who has spent far more of his life working on it than he would have liked, its obscurity is well-deserved.
Um, when you talk about RedHat shipping with remote root holes, are you talking about exploits on ports left open at install time in software which you would expect by default on a Windows (NT) installation?
Well, the last time I recall having seen a comparison of Linux / NT security holes (and this was a couple of years back - hence 'historically') some Wincentric columnist had misread Bugtraq stats. NT had come in with something over 100 exploits for the year, all Linuxes ORed together came in at 80 odd, and Red Hat had about 37 (said columnist had added the ORed value of all Linuxes to Red Hat's bug count... nuff said). Caused a bit of a stink. If I have to I could probably do some research and find out columnist name and exact exploit numbers for the year in question, but I'd prefer to avoid half an hour or so's rooting round if I can help it:P. Windows 2000 may be a vast improvement, I don't know... but NT was a sorry mess security-wise compared to Linux.
Competing with a free product - that's pretty well the bottled water market for you *g*. I'd wager only a tiny proportion of the water drunk worldwide each year comes in branded bottles. It's very hard to compete with a free product which does more or less exactly what yours does, no matter how good your marketing, as long as other people know the free product exists. Cost has been the main factor through the history of operating systems to date, and I can't see even the Microsoft marketing machine managing to brush it aside - unless they made Windows free as well, but this would be dubiously beneficial to them.
> - a microkernel architecture would increase portability, security, reduce the trusted code base, and facilitate code development
The microkernel argument's not a new one; in fact if you read the original Torvalds / Tanenbaum debates it was a major topic of discussion early in Linux history. To put it briefly: microkernels have, for all their advantages, performance and development complexity issues. They've been used in a few places, but have a nasty habit of running like a dog. Mac OS X, which is about the only modern desktop OS I can think of that uses a microkernel, has been badly slated for its performance by a number of people, and I would be surprised if their decision to opt for the Mach kernel was not at least partly to blame. This argument is very much a red herring: microkernels are NOT the panacea some segments of academia tend to present them as.
> - not writing the standard internet services in C would also make a huge difference! (I don't know if you consider these "part of the OS")
What would you want to write the standard internet services in if not in C? As a system-level programming language it has retained its commanding place for good reasons, especially its excellent performance. Please explain what you believe would be better?
> Anyway, it really is true that it is based on a 30 year-old design. Make of that what you will. (I did in my post say that it is a tried-and-true design, which I believe.)
And yup, Unix is a 30 year old design. Don't confuse the user-level similarities with the internal algorithms however, which are markedly different between Linux and the Unix of thirty years ago.
> Now who is spreading FUD? =) I feel much safer about a default install of Win2k than I do about a Redhat install... Security issues exist in spades on both sides, and it is hard to say which
> one is really more "rife"...
There are more problems with Windows security, counting bugtraq issues - but as most of them have to relate to applications such as IIS and Explorer, I'd agree that the basic Win2K setup is probably roughly as safe as a RedHat install. However... that response is similar to the very limp answer of Microsofts when Gartner Group recommended companies abandon IIS: "but all systems have problems". Historically, Microsoft has had a hell of a lot more by the way of "issues" than anyone else.
> OK, then Joe User is my dad. He is a smart guy, he can learn how use something if he cares enough, but he doesn't think that Win2K is that bad, and would never consider investing weeks to
> figure out linux. That is the kind of person I'm talking about. How do you convince him to use it?
Well, the problem is presumably that he is used to Windows, which is fair enough. Had Joe User not been used to either, there'd be little enough to choose between the systems. The most compelling reason to learn Linux for the average user is probably the cheaper cost, I suppose; if you're going to catch Windows users, you have to catch them in upgrading. Win2K is marked to become unsupported by Microsoft in 2004. By then, an open source (free!) solution that meets his desktop needs without the need to pay out the cost of a foreign holiday to incrementally improve his operating system and applications might be tempting. Only it won't work like that... Joe User will go to buy his new machine, and if the cheaper machine has Linux on it and the salesman is savvy enough to explain that it has a vast number of free applications for it, Linux will have a good chance of gaining a significant toehold.
I'd like to make the case for users caring about freedom, caring about civil liberties, caring about corporations screwing them over... but I believe the average person simply doesn't care, and should the country I live in ever complete its progress into an Orwellian nightmare, governmental or corporate, I believe it will be only a small minority who oppose it. Linux will win, not because of having finer ideals, nor because it espouses open standards and public liberty, but because its' cheap.
Folks, your security was lax anyway. Speaking to a colleague who passed through Kennedy Airport only about 2 weeks back (coming from UK), he mentioned that US security was surprisingly lax compared to European airports, with many electronic gadgets he had with him including a laptop remaining unchecked. It's still possible it could happen over here, but there's a lower chance the better the security is. Allowing every man and his dog to carry firearms onto planes is *not* going to help.
I'm a programmer at Xilinx working on an internal tool our IP developers use, and I have to say that that's not how FPGAs work. The boards have flipflops and LUTs (Look Up Tables) in a regular matrix; the LUTs hold 16 values and act essentially as truth tables indexed by 4 inputs. Hence they can imitate any gate with the same number of inputs, be it XOR or NAND or any other gate (or even some combination of 2-input gates which has 4 inputs and a single output). This is, of course, a very simplified explanation, but the principle is the same even with the more advanced FPGAs.
'Gates' figures on FPGAs are thus rough estimates of how many NAND gates would be needed to provide similar functionality.
>Look at UNIX as an example. Quake III under Linux will never have the performance of Quake III under Windows 98. The reason is that, while Linux >is a technically superior platform, Linux has large operational tolerances. It's very resistant to crashes because of the way it's designed. >However, this
fault-tolerant design comes at a price: by separating the 3D libraries from X, by separating X from the kernel, etc., you introduce lots of >hidden latencies.
Actually, the latencies that matter in this situation are caused by the scheduler, can be drastically reduced with a patch now and eventually reduced in the main kernel flow. This yields latencies significantly better than Windows or Mac, taking things down to roughly BeOS levels. The view just propounded above is quite common, but fallacious, I fear.
Linus wrote a kernel, not an OS; and in that that kernel is not quite Unix-standard, though it appears to be from outside, and it employs more modern algorithms than in the original Unix kernel, etc; so yes, the design was new. This is not however the revolutionary bit. By releasing it under the GPL he showed what would be to most computer users at that time a pretty revolutionary outlook. There were others previous to him, like RMS, who equally were revolutionaries in that sense, but that doesn't make Linus less of one, considering that Free Software / Open Source had then a mere fraction of the popularity it enjoys today.
Oi! He wrote fetchmail, among a long and varied hacking career including big emacs contributions, and being one of the main ncurses developers. He may not have done as much as Linus or RMS, but chances are he's contributed much more code to the average Linux distro than you have; I know he's added much more than I have. So, please, show some respect; he's a hacker as well as a journalist, and even if you don't agree with what he says, his experience of hacking gives him some right to be listened to.
This reminded me spookily of some of the sci-fi stories from the 30's or thereabout, in which the idea was propounded that what we see as atoms are in fact solar systems with planets surrounding them on a very much smaller scale, and in turn our solar systems and stars are just atoms in a much larger universe; in effect an infinite number of universes on different scales, all inside one another like Russian dolls. I know the science in these 'science-fiction' stories was bunkum, and that it's only the angle we're seeing this at that makes it look even vaguely like a human face, but I have to confess remembering the idea amused me...
Vim highlights syntax quite nicely thank you. And what are 'the benefits of windows-based applications'? Using the mouse is really bad for touch-typists, and any editor that reduces mouse usage is therefore a Good Thing and a productivity tool for them.
That said, I use Nedit, and like it. But when my touch-typing becomes halfway decent, I shall use it no more.
>I don't why people put up with arcane crap like
>vi. Maybe it makes them feel like 'real'
>programmers.
I like Nedit. Perhaps it would be fairer to say I love Nedit. I use it constantly. But vi, for
a touch-typing developer who's willing to learn the shortcuts is a far far superior editor. I
don't touch-type, and exposure to Windows at an early age has unfortunately allowed Ctrl-X,
Ctrl-C and Ctrl-V to have certain associations in my head with cutting, copying and pasting.
Recently though, I have been learning to touch-type and as a result I've come to understand
why vi and emacs are so loved. Try scrolling up and down, on the keyboard, without moving your
hands away from the main area of the home keys. In vi, Ctrl-U and Ctrl-D page you up and down,
and hjkl are cursors. Want to delete a word and a half - say 8 letters or so - and put
something else in? In vi you type 8, hit s and go. In nedit, you highlight with either the
mouse or the cursors, then hit delete. Again, your hands have moved from the home keys. Vi is
designed for the expert, the touch-typist. Nedit is really just like a Windows text editor -
although it's superior to virtually anything actually native to windows, it is designed for the
non-touch-typing user of Windows shortcuts. Eventually I hope to leave off using Nedit
completely, excellent editor that it is, in favour of vim. Nedit's main advantage over vim is
that it has a decent macro language; if you are using emacs instead of vi (with emacs, most of
the same arguments as with vi apply) you have that already, but given the power of shell
scripts using grep, sed, awk etc I don't really think I need that capability built into my
editor when I can flip back and forwards between my shell and my editor without leaving the
home key area. It is worthwhile learning both vi and shell bindings, for, if you touch-type,
knowing them will make you more productive.
This reminds me rather of the anxiety over the Y2K bug. I think the rather doom-laden scenario being predicted here is frankly overblown.
"Then the lights wink out. Everywhere.
Then it begins to get cold."
Naturally, it leads into a Big Brother state from that point on. The article's a troll; it engages in emotive button-pushing.
Not terribly surprising, but still disappointing. It will be interesting to see how gambling evolves, as casinos take ever more stringent steps to avoid giving out more money to someone than they paid in. Here's an interesting little exhibit from the UK dealing with the rigging of fruit machines.
It would seem to me that the sheer number of moving parts in a kilometre or so of walkway must make the chances of frequent failures pretty high compared to other public transport methods. How fault-tolerant is it? Any French Slashdotters able to answer?
Would be interesting to see some schematics.
Life imitates Neal Stephenson. This reads exactly like something out of Snow Crash.
Probably one of the most famous crimes in Britain last century was the Great Train Robbery in 1963, which formed the factual underpinning for the film and book. Most of the 15 men involved in the heist were caught; one of them, Ronnie Biggs, escaped from jail in a rather daring manner and became something of a celebrity as a result. Last year he returned from Brazil, aged 71, to give himself up. A Google for Biggs and the great train robbery should give you a wealth of information, but here's a link to get started:
p .html
http://www.canoe.ca/CNEWSScienceNews/train_may7-a
Don't know if anyone noticed, but the funding is given as approximately £100,000 (that is, $156,000 or so, American readers). With tiny sums of money like that, you won't have many people working on it nor much money for experimenting with different equipment. British funding for research is pathetically low compared to many neighbouring countries with far poorer economies; the phone company Nokia spends more on research than the whole of Scotland.
It's something of a miracle that any kind of useful research comes out of Britain at all, given governmental reluctance to give academia useful amounts of money.
You could describe the court system almost exactly like that, you know; a panel containing individuals with a known bias. There's a prosecuting lawyer, and a defending lawyer, and a judge and jury. The funny thing is that it works much better than not having prosecuting or defending lawyers at all; the jury knows where the lawyers' bias lies, and relies on the lawyers to sort the wealth of information about the case into arguments for and against convicting the accused.
Given that there will be open source advocates and Microsoft advocates on the panel, there's the same balance as in a court of law. And if we were looking at the scientific evidence supporting the theory of evolution, damn right I'd want creationists on the panel as well as hard-core evolution supporters like yourself. I might or might not find their arguments unconvincing, but I'd be positive that those making them had put in a lot of effort to find the best arguments they could opposing the theory. And personally, I don't find them any more ridiculous than those who treat evolution as an unchallengeable religion in itself. When people stop looking at things scientifically and resort to dogma, whether it be evolution or creation, championing Microsoft or Linux, they pretty well forfeit any chance of my taking them seriously; I like to hope I'm not the only one that feels that way.
Savant
This is a regular straw man attack. The original, informative post didn't claim viruses were living organisms (in fact, it specifically said that viruses were 20-50x less complex than the simplest forms of life), and it called Penrose a physicist. So how is this response relevant in any way?
Savant
Hate to be disagreeable, but Microsoft doesn't pay taxes in Britain to the best of my knowledge, and those of us who do pay taxes in Britain pay them in pounds sterling, rather than dollars.
The university in Cambridge being mentioned is the rather famous British one.. as in "Oxford and Cambridge".
Savant
Imminent Death Of The Net Predicted! prov.
[Usenet] Since Usenet first got off the ground in 1980-81, it has grown exponentially, approximately doubling in size every year. On the other hand, most people feel the signal-to-noise ratio of Usenet has dropped steadily. These trends led, as far back as mid-1983, to predictions of the imminent collapse (or death) of the net. Ten years and numerous doublings later, enough of these gloomy prognostications have been confounded that the phrase "Imminent Death Of The Net Predicted!" has become a running joke, hauled out any time someone grumbles about the S/N ratio or the huge and steadily increasing volume, or the possible loss of a key node or link, or the potential for lawsuits when ignoramuses post copyrighted material, etc., etc., etc.
Savant
Whoa there! You're going to reboot a machine with a 2556 day uptime? Where's your geek uptime pride?
Savant
My question would be whether the take-up of applications such as Outlook Express and Internet Explorer is greatly hindered by their having security holes. I'm sure some people will refuse to use Outlook on security grounds, but I've the suspicion far more people will choose to use it on its features, and it will be the feature set that keeps them with Outlook as an email client. From a marketing perspective, then, there would be no point in directing a high proportion of development effort into ensuring security when it will only affect product adoption minorly. Now given that Microsoft's chief strength is in desktop apps, I'd be tempted to think that they've been applying the same marketing mentality that they have for the debug/add feature work split on desktop apps to server app development.
Savant
The concept here doesn't look like revolutionary thinking; I'm fairly certain I've seen descriptions of similar devices in sci-fi, and the idea of painting input from the other side onto the output from the other is a pretty obvious way to take a stab at "invisibility". I'm hoping that the patent is based on having at least a semi-working prototype rather than being a pure concept patent.
In any case, if you're using it on irregular shapes like clothing, you'll run into interesting texture-mapping/scaling problems trying to map the input to the output; you'll need to be able to work out the exact locations of your receptors on some kind of internal co-ordinate system to make things work. This means that, for clothing, you'd need to work out exact body orientation and movement. For this you'd need to first build a superbly accurate body suit that tracks motion with very low error margins... which we're not all that close to at present. And that's assuming nice tight clothing without those horrid hard-to-calculate folds.
Bottom line: Can't see an invisibility cloak, or any invisibility clothing lines any time soon. Would consider it *possibly* feasible with current technology to build a static regular shell (perhaps hemispherical) which could conceal what's under it.
Savant
> 2. It's an awful lot easier to write software in high level languages, SML being a good example
:P) given is a perfectly natural way to program in SML, but strange and hideous to a loop-loving C programmer - it yields an algorithm which grows in memory needed and execution time *as do the Fibonnacci numbers themselves* as opposed to the obvious-to-a-C-programmer O(N) algorithm. That the compiler uses the JMP instruction to implement the hideous recursive algorithm does not mean that it is anywhere near as tidy and efficient as the loop algorithm!
Not really; you're comparing a totally different programming paradigm, which is admittedly easier for some things, but a hell of a lot harder in others.
> 3. SML is actually very fast. Maybe you used it a long while ago, or were confused by the interactive system (where compilation is part of running your program), but it is fast, I promise.
Um, a few points about these "benchmarks"... take a look at the actual CPU time spent over a few individual benchmarks, rather than the somewhat dubious points system. SML is coming in at something like half the speed of C at best on almost all of them, and in most cases far far worse than that. Admittedly, adopting some of the worse mistakes of C++ can slow you down by similar factors, but as C++ is essentially pretty close to a C superset there's no need to use these "features" in a performance-intensive app.
Additionally, some of the algorithms used to minimise code length in non-C languages (such as the Fibonacci sequence) are frighteningly, horrendously inefficient. Compare the Fibonacci sequence algorithm given with the speed of a straightforward C loop with 3 variables (translating directly into registers). Not to mention the actual time spent in calculation pales into insignificance besides the time spent in printf - slightly over half a dozen assembly instructions are all that is needed to cope with the calculation part in C, but printf runs to thousands of lines of C code and more assembly... these benchmarks are nonsensical, particularly as the main speed difference between C and C++, give the implementations listed, is probably between cout and printf...
> Well, I don't know what useful features it's missing
I should clarify; didn't really mean features, but library functionality. Try writing an SML GUI for X.
> In fact, most SML compilers will compile a tail-recursive function into a JMP, just like a loop in C.
The most painful inefficiency of recursion is often size. It leads to many more stack frames being kept in memory than necessary, compared to an incremental approach, as data from all calling recursive functions must be kept in memory whether vital to the current calculation or not. The recursive fibonnacci algorithm (I'm still shocked
What I meant by "bad to translate into assembly language" was precisely this: the different paradigm tends to lead to inefficient algorithms on computing hardware which works in a C-like manner.
Savant
> Well, I think any modern language would be better. Java (natively compiled) would be ok if the programmer needs the6 97
:P. Windows 2000 may be a vast improvement, I don't know... but NT was a sorry mess security-wise compared to Linux.
> language to be C-like, but personally I think SML (http://slashdot.org/comments.pl?sid=6343&cid=929
> [slashdot.org]) or O'Caml would be a much better choice. These languages are safe (NO more buffer overflows or
> memory leaks, not even "null pointer exceptions"), powerful, AND fast.
Java as native code is still horridly inefficient in comparison to C, and there is no compelling reason to use it in preference as opposed to good programming practice in C (using safe i/o routines for starters).
SML - what are you smoking? I was lucky enough to be educated at Edinburgh Uni, which is a damn fine university in most respects, but has a horrid blind spot where Standard ML is concerned, and it is universally inflicted on second year CS students. It encourages inefficient programming techniques (such as recursion) and lacks a hell of a lot of important features - not to mention that by implementing a non-procedural programming paradigm it becomes uselessly high-level (bad to translate into assembly) and yes, damn slow. Edinburgh is one of the few places where it has a home, but even here probably the majority of staff (working there now) tacitly acknowledge its general uselessness for most real world tasks. Admittedly, as you point out, speed is less of an issue here than it would be in a lot of other cases, but there's still no excuse for using SML as opposed to coding in C using safe I/O routines. I know this is supposed to be one of the few areas its supporters claim it to be good at... but honestly, speaking as someone who has spent far more of his life working on it than he would have liked, its obscurity is well-deserved.
Um, when you talk about RedHat shipping with remote root holes, are you talking about exploits on ports left open at install time in software which you would expect by default on a Windows (NT) installation?
Well, the last time I recall having seen a comparison of Linux / NT security holes (and this was a couple of years back - hence 'historically') some Wincentric columnist had misread Bugtraq stats. NT had come in with something over 100 exploits for the year, all Linuxes ORed together came in at 80 odd, and Red Hat had about 37 (said columnist had added the ORed value of all Linuxes to Red Hat's bug count... nuff said). Caused a bit of a stink. If I have to I could probably do some research and find out columnist name and exact exploit numbers for the year in question, but I'd prefer to avoid half an hour or so's rooting round if I can help it
Competing with a free product - that's pretty well the bottled water market for you *g*. I'd wager only a tiny proportion of the water drunk worldwide each year comes in branded bottles. It's very hard to compete with a free product which does more or less exactly what yours does, no matter how good your marketing, as long as other people know the free product exists. Cost has been the main factor through the history of operating systems to date, and I can't see even the Microsoft marketing machine managing to brush it aside - unless they made Windows free as well, but this would be dubiously beneficial to them.
> - a microkernel architecture would increase portability, security, reduce the trusted code base, and facilitate code development
The microkernel argument's not a new one; in fact if you read the original Torvalds / Tanenbaum debates it was a major topic of discussion early in Linux history. To put it briefly: microkernels have, for all their advantages, performance and development complexity issues. They've been used in a few places, but have a nasty habit of running like a dog. Mac OS X, which is about the only modern desktop OS I can think of that uses a microkernel, has been badly slated for its performance by a number of people, and I would be surprised if their decision to opt for the Mach kernel was not at least partly to blame. This argument is very much a red herring: microkernels are NOT the panacea some segments of academia tend to present them as.
> - not writing the standard internet services in C would also make a huge difference! (I don't know if you consider these "part of the OS")
What would you want to write the standard internet services in if not in C? As a system-level programming language it has retained its commanding place for good reasons, especially its excellent performance. Please explain what you believe would be better?
> Anyway, it really is true that it is based on a 30 year-old design. Make of that what you will. (I did in my post say that it is a tried-and-true design, which I believe.)
And yup, Unix is a 30 year old design. Don't confuse the user-level similarities with the internal algorithms however, which are markedly different between Linux and the Unix of thirty years ago.
> Now who is spreading FUD? =) I feel much safer about a default install of Win2k than I do about a Redhat install... Security issues exist in spades on both sides, and it is hard to say which
> one is really more "rife"...
There are more problems with Windows security, counting bugtraq issues - but as most of them have to relate to applications such as IIS and Explorer, I'd agree that the basic Win2K setup is probably roughly as safe as a RedHat install. However... that response is similar to the very limp answer of Microsofts when Gartner Group recommended companies abandon IIS: "but all systems have problems". Historically, Microsoft has had a hell of a lot more by the way of "issues" than anyone else.
> OK, then Joe User is my dad. He is a smart guy, he can learn how use something if he cares enough, but he doesn't think that Win2K is that bad, and would never consider investing weeks to
> figure out linux. That is the kind of person I'm talking about. How do you convince him to use it?
Well, the problem is presumably that he is used to Windows, which is fair enough. Had Joe User not been used to either, there'd be little enough to choose between the systems. The most compelling reason to learn Linux for the average user is probably the cheaper cost, I suppose; if you're going to catch Windows users, you have to catch them in upgrading. Win2K is marked to become unsupported by Microsoft in 2004. By then, an open source (free!) solution that meets his desktop needs without the need to pay out the cost of a foreign holiday to incrementally improve his operating system and applications might be tempting. Only it won't work like that... Joe User will go to buy his new machine, and if the cheaper machine has Linux on it and the salesman is savvy enough to explain that it has a vast number of free applications for it, Linux will have a good chance of gaining a significant toehold.
I'd like to make the case for users caring about freedom, caring about civil liberties, caring about corporations screwing them over... but I believe the average person simply doesn't care, and should the country I live in ever complete its progress into an Orwellian nightmare, governmental or corporate, I believe it will be only a small minority who oppose it. Linux will win, not because of having finer ideals, nor because it espouses open standards and public liberty, but because its' cheap.
Savant
Folks, your security was lax anyway. Speaking to a colleague who passed through Kennedy Airport only about 2 weeks back (coming from UK), he mentioned that US security was surprisingly lax compared to European airports, with many electronic gadgets he had with him including a laptop remaining unchecked. It's still possible it could happen over here, but there's a lower chance the better the security is. Allowing every man and his dog to carry firearms onto planes is *not* going to help.
I'm a programmer at Xilinx working on an internal tool our IP developers use, and I have to say that that's not how FPGAs work. The boards have flipflops and LUTs (Look Up Tables) in a regular matrix; the LUTs hold 16 values and act essentially as truth tables indexed by 4 inputs. Hence they can imitate any gate with the same number of inputs, be it XOR or NAND or any other gate (or even some combination of 2-input gates which has 4 inputs and a single output). This is, of course, a very simplified explanation, but the principle is the same even with the more advanced FPGAs.
'Gates' figures on FPGAs are thus rough estimates of how many NAND gates would be needed to provide similar functionality.
Savant
>Then you need some kind of grammar algorithm so that it sounds reasonably coherent.
Either that or post it under CmdrTaco's ID....
Savant
>is a technically superior platform, Linux has large operational tolerances. It's very resistant to crashes because of the way it's designed.
>However, this fault-tolerant design comes at a price: by separating the 3D libraries from X, by separating X from the kernel, etc., you introduce lots of
>hidden latencies.
Actually, the latencies that matter in this situation are caused by the scheduler, can be drastically reduced with a patch now and eventually reduced in the main kernel flow. This yields latencies significantly better than Windows or Mac, taking things down to roughly BeOS levels. The view just propounded above is quite common, but fallacious, I fear.
See this link for more detailed information: http://www.oreillynet.com/pub/a/linux/2000/11/17/l ow_latency.html?page=1
Savant
Linus wrote a kernel, not an OS; and in that that kernel is not quite Unix-standard, though it appears to be from outside, and it employs more modern algorithms than in the original Unix kernel, etc; so yes, the design was new. This is not however the revolutionary bit. By releasing it under the GPL he showed what would be to most computer users at that time a pretty revolutionary outlook. There were others previous to him, like RMS, who equally were revolutionaries in that sense, but that doesn't make Linus less of one, considering that Free Software / Open Source had then a mere fraction of the popularity it enjoys today.
Savant
Oi! He wrote fetchmail, among a long and varied hacking career including big emacs contributions, and being one of the main ncurses developers. He may not have done as much as Linus or RMS, but chances are he's contributed much more code to the average Linux distro than you have; I know he's added much more than I have. So, please, show some respect; he's a hacker as well as a journalist, and even if you don't agree with what he says, his experience of hacking gives him some right to be listened to.
Savant
This reminded me spookily of some of the sci-fi stories from the 30's or thereabout, in which the idea was propounded that what we see as atoms are in fact solar systems with planets surrounding them on a very much smaller scale, and in turn our solar systems and stars are just atoms in a much larger universe; in effect an infinite number of universes on different scales, all inside one another like Russian dolls. I know the science in these 'science-fiction' stories was bunkum, and that it's only the angle we're seeing this at that makes it look even vaguely like a human face, but I have to confess remembering the idea amused me...
Savant
Vim highlights syntax quite nicely thank you. And what are 'the benefits of windows-based applications'? Using the mouse is really bad for touch-typists, and any editor that reduces mouse usage is therefore a Good Thing and a productivity tool for them.
That said, I use Nedit, and like it. But when my touch-typing becomes halfway decent, I shall use it no more.
Savant
>I don't why people put up with arcane crap like
>vi. Maybe it makes them feel like 'real'
>programmers.
I like Nedit. Perhaps it would be fairer to say I love Nedit. I use it constantly. But vi, for
a touch-typing developer who's willing to learn the shortcuts is a far far superior editor. I
don't touch-type, and exposure to Windows at an early age has unfortunately allowed Ctrl-X,
Ctrl-C and Ctrl-V to have certain associations in my head with cutting, copying and pasting.
Recently though, I have been learning to touch-type and as a result I've come to understand
why vi and emacs are so loved. Try scrolling up and down, on the keyboard, without moving your
hands away from the main area of the home keys. In vi, Ctrl-U and Ctrl-D page you up and down,
and hjkl are cursors. Want to delete a word and a half - say 8 letters or so - and put
something else in? In vi you type 8, hit s and go. In nedit, you highlight with either the
mouse or the cursors, then hit delete. Again, your hands have moved from the home keys. Vi is
designed for the expert, the touch-typist. Nedit is really just like a Windows text editor -
although it's superior to virtually anything actually native to windows, it is designed for the
non-touch-typing user of Windows shortcuts. Eventually I hope to leave off using Nedit
completely, excellent editor that it is, in favour of vim. Nedit's main advantage over vim is
that it has a decent macro language; if you are using emacs instead of vi (with emacs, most of
the same arguments as with vi apply) you have that already, but given the power of shell
scripts using grep, sed, awk etc I don't really think I need that capability built into my
editor when I can flip back and forwards between my shell and my editor without leaving the
home key area. It is worthwhile learning both vi and shell bindings, for, if you touch-type,
knowing them will make you more productive.
Savant